From jay.krell at cornell.edu Sun Aug 1 00:13:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 31 Jul 2010 22:13:58 +0000 Subject: [M3devel] rmrec problems -- delete while enumerating Message-ID: Aha. http://www.cz.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/readdir.c Strongly hints at problems related to deleting and enumerating at the same time. >From that then, I'll make another speculation -- enumeration ends up missing entries. IF IF IF the directory is viewed like an array, and if readdir maintains a position, moving forwad in chunks, and if delete underneath it shifts everything down, then, I think one can see the problem. I'm not sure which of these statements is true though. Certainly deleting while enumerating is not in general obvious how to deal with. Depending on a few factors. In STL documentation, they always mention what iterators are invalidated by deletion. It varies from collection to collection and perhaps other aspects. As to why my "rewrite" isn't working, I don't know, I can't look at until Monday. It looks simple and correct, I tested it some, and should deal with delete-during-enumerate. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Aug 3 01:08:48 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 02 Aug 2010 18:08:48 -0500 Subject: [M3devel] trac ticket 1147, additional info Message-ID: <4C575000.5000208@lcwb.coop> I couldn't find any place to attach these files directly to a ticket. They are definitely relevant. The file Test.mc, needed to rerun the error, is 906386 bytes. Ask if you want it. Note: The same symptom occurs on LINUXLIBC6. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: failurelog URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: backtrace URL: From wagner at elegosoft.com Tue Aug 3 09:05:17 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 03 Aug 2010 09:05:17 +0200 Subject: [M3devel] Fwd: [CM3] #1147: Runaway recursion in m3cc. Message-ID: <20100803090517.km5chcezw40cskw4@mail.elegosoft.com> FYI ----- Forwarded message from bugs at elego.de ----- Date: Mon, 02 Aug 2010 22:59:36 -0000 From: CM3 Reply-To: CM3 Subject: [CM3] #1147: Runaway recursion in m3cc. To: rodney.m.bates at acm.org, wagner at elego.de #1147: Runaway recursion in m3cc. -------------------------------------+-------------------------------------- Reporter: rodney.m.bates@? | Owner: wagner Type: sw-bug | Status: new Priority: medium | Milestone: CM3 Release 5.9 Component: sys | Version: 5.8-RC3 Severity: serious | Keywords: m3cc, recursion Relnote: | Confidential: no Org: | Estimatedhours: 0 Hours: 0 | Billable: 0 Totalhours: 0 | Internal: 0 -------------------------------------+-------------------------------------- Htr: run command: /usr/local/cm3//bin/cm3cg -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks Test.mc -o Test.ms with file Test.ms present. This file to be supplied. Fix: Env: m3cc from branch cm3-5-8-release, up to date as of 2010-8-1, except for using dbxout.c 1.8, instead of 1.9, which is almost certainly irrelevant -------------------------------------+-------------------------------------- m3cc crashes after runaway recursion in gcc's garbage collector, collecting nodes apparently created in parse.c. There is a linear list of 261924 nodes of kind TS_FIELD_DECL, linked on the 'chain' field. This is rooted in field 'chain' of a TS_FUNCTION_DECL node. These are node types created from parse.c. -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 3 11:36:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Aug 2010 09:36:53 +0000 Subject: [M3devel] rmrec problems Message-ID: There seems to another final problem, or maybe this was the problem all along, or maybe maybe I introduced this with the previous fix (*) stat on a symlink whose target has been deleted, apparently fails. e.g. m3cc/target/gmp/.libs/libgmp.la -> ../libgmp.la *: maybe I introduced it: Well, before it might have been sensitive to directory enumeration order. My change deletes files and then subdirectories, making it no longer sensitive that way. Fix will be to use lstat I believe. And I'll just report symlinks to be regular files. And opening them can fail with file not found... which I'm sure will break something somewhere -- enumerated files no longer necessarily exist... Probably no win. Probably the original interfaces didn't consider symlinks, since they aren't portable. Yet without considering them, and composing rmrec on lower level suppostedly portable interfaces..you can't ignore them. Can't win. ?- Jay From jay.krell at cornell.edu Tue Aug 3 11:50:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Aug 2010 09:50:32 +0000 Subject: [M3devel] m3 mailing lists? Message-ID: Are m3commit or m3devel working? I know there was scheduled maintenance but I figured that'd be under a day. ?- Jay From jay.krell at cornell.edu Wed Aug 4 05:53:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 03:53:47 +0000 Subject: [M3devel] m3override In-Reply-To: <20100730215051.GA23133@topoi.pooq.com> References: , , <20100730215051.GA23133@topoi.pooq.com> Message-ID: > I remember using an override somewhere ... but I don't remember where or > why now. So..it sounds like maybe you don't know what overrides are. That is ok. But you can't then reason about changes to them. Including claiming that all changes are scary or bad. Not that you did, but many people are prone to that way of thinking. > But I'd worry if this change broke something. Sure. You should sorry about anything that breaks anything. But this doesn't break anything. And, if it did, you'd have to apply context-sensitive heuristics. Does it break anything that matters? Matters much? What is the cost of maintaining the code to preserve "everything" "working"? Were the definitions of "working" correct in the first place? Does widespread expectation make something correct? Realize that for nearly any given change, I can tell you something that it breaks. rmrec wasn't working. But I could easily theorize code that depended on it not working. It not working was a way to detect certain characteristics of the filesystem -- presence of symlinks, possible behaviors of readdir+unlink. LONGINT didn't exist, in the base language. But I was using LONGINT as a type already, TYPE LONGINT = ARRAY [0..1] OF INTEGER. (No, I wasn't actually.) Putting it in the language broke such code. Time passing breaks code. Seriously. (Year2000, Year2038). But you can't really stop it. Except by changing the time on your computer to be wrong. In either case, I put the useless warning back and changed our master m3override to ignore it. That is *not* evidence of the utility of the warning, that it made me change code to ignore. There is not actual improvement to the code by avoiding the warning. To understand this stuff, it helps to consider make and make install and chroot. Can I run stuff I haven't run "make install" on? Sometimes. Can I build my own libc.so without chroot? Sometimes. Modula-3 merely reinveints those sorts of things itself. Those things are flawed and Modula-3 fixes some but not all of the flaws. while still leaving major problems present. It is this consistent not fixing all the problems that makes me consider it not worth being so different.. Ultimately chroot is the heavyweight reliable solution. And/or strictly building things -- everything -- from the bottom of the dependency tree and up. In the Modula-3 build system, there is a "package store". e.g. /usr/local/cm3/pkg. That contains packages, e.g. /usr/local/cm3/pkg/m3core. When you say "import(m3core)", it has to find m3core somewhere. The default is package store + package name -- e.g. /usr/local/cm3/pkg/m3core. If you are building package foo, let's say at /usr/src/foo, and you want it to use some custom m3core, which is at /usr/src/m3core then you create /usr/src/foo/src/m3overrides that says override("m3core", "/usr/src") something like that. This is deceptive though. You sort of can't actually do this. Not so easily. You can only really do it if everything in the dependency tree between foo and m3core were also built using the same overrides. You need consistent definitions of types, interfaces, etc. But granted, if you only changed implementation, you can maybe do it. Of course, static linking interferes as well. Are you using stubgen? Should it pickup the new m3core? Then you have to build it too. Which is to say, you can really only use entire alterate package stores. You can't really pick and choice packages from one place or another. Unless you are very careful. And none of our codebases are particularly large anyway. You might as well just make whatever source changes in any package and build it all to alternative package store. Even relying on good albeit buggy incrementality in cm3. Another way to view this, the way we use it in Hudson et. al. is that there are precisely two package stores. /usr/local/cm3/pkg and the "uninstalled" or "unshipped" /usr/cvs/cm3/m3-libs/m3core, /usr/cvs/cm3/m3-sys/m3quake etc. The m3overrides file points into the CVS checkout, which, regrettably, also contains all of our outputs. (see also: "read only source tree", which we sort of have, sort of are/were ahead of everyone else, but not really..) cm3 -x uses the m3overrides files. Cm3 without -x does not. And we use it as I described -- not to pick and chose packages from one place or another. But to pick and chose all packages from one overall tree or another. And then you run into the potential problem that the two directories have a different layout. So stuff like rpath $ORIGIN/../lib doesn't work. Ultimately, often people want binaries to work without running make install. And they often do. Ultimately chroot is how you really build custom stuff. But it seems onerous. I have almost never done it. We can cheat, because we don't build ld.so, libc.so. We only need "chroot" from a certain point and on up. I suggest instead of overrides, instead: 1) have the "intermediate" (not installed) files go into a layout like the current install, not next to the source as currently This is the .a/.so/.exe files, not the .o/.obj/.mo/.io files. .o/.obj/.mo/.io belong somewhere else. 2) "install" is merely deleting one root and copying or renaming the other over it 3) no more notion of overrides If you don't want to build "everything", you can instead copy or hardlink-tree the original. (symlinks won't do, not used with $ORIGIN; though maybe we should abandon $ORIGIN? So many systems don't support it, it turns out). There are tradeoffs either way. In this scheme, rpath $ORIGIN/../lib works without install. You would no longer have executables in the package store, only in cm3root/bin. We could stop statically linking anything. However you do lose "hierarchical naming". Well, maybe. Maybe executables in the package store would use rpath $ORIGIN/../../lib. Heck, maybe the model is everything is in the package store and bin and lib only contain symlinks? (the warning still hasn't been explained, or maybe I'm behind on email) - Jay > Date: Fri, 30 Jul 2010 17:50:51 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > On Fri, Jul 30, 2010 at 01:58:45AM +0000, Jay K wrote: > > > > Randy, Without reading the code, what does it mean? > > > > My first guess was I believe wrong and based on reading the code I think it is even more pointless than I previously thought. > > > > It gets printed *all the time*, when using overrides. Look at any of the Hudson logs. > > > > It wouldn't be printed so much in the older way of doing things, where overrides were applied haphazardly and incompletely. Now that they are used fairly consistently/correctly, it always triggers. I hope to eventually replace the overrides mechanism -- if we just put files into a designated root directory, with the same structure as "the install", then "override" is just setting that directory, optionally prepopulating with an entire copy of the current install -- depending on if you want to build up from scratch or selectively override. You could use hardlinks to speed it up, as long as our copy is delete + copy and not just copy (sometimes a copy will share with the original link(s), sometimes it will unshare, depending on the open flags (I think) or if you first delete). And "install" becomes just moving the install root, if the new one is complete. > > I remember using an override somewhere ... but I don't remember where or > why now. But I'd worry if this change broke something. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Aug 4 08:21:54 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 08:21:54 +0200 Subject: [M3devel] trac ticket 1147, additional info In-Reply-To: <4C575000.5000208@lcwb.coop> References: <4C575000.5000208@lcwb.coop> Message-ID: <20100804082154.isv1z0fvwoow084o@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I couldn't find any place to attach these files directly to a ticket. They > are definitely relevant. The file Test.mc, needed to rerun the error, is > 906386 bytes. Ask if you want it. Are you logged in? Probably trac doesn't allow attachments to anonymous tickets. What about this link: https://projects.elego.de/cm3/attachment/ticket/1147/?action=new ? Hope this helps, 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 Wed Aug 4 08:49:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 08:49:30 +0200 Subject: [M3devel] m3override In-Reply-To: References: , , <20100730215051.GA23133@topoi.pooq.com> Message-ID: <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com> I wouldn't worry much about the warning Jay removed. It only said that an override wasn't used, which is the default behaviour of cm3 (without -x or -override option). One could argue that if one wanted this warning, one should use an option like -warn=overrides or -warn=all (which don't actually exist (yet)). However, I'd still like others to think about the two perspectives one can take here, and what should be the direction we are tweaking our build system. Traditionally, the focus was on the package view, i.e. the view of one developer, and not a whole system. The builder was designed to work well in this setup (more or less). For one notable exception, which others have noticed (who were involved with the original design): linking has never been tried implement portably in a general way. With this focus, overrides are the sole responsibility of the developer, and one could argue that he should know exactly what he does if he uses them. In the CM3 distribution, I used the override feature to allow building the whole set of package in the workspace, which can be seen equivalent to use a completely different package pool. The scripts (which originally were only meant as a tool for the distribution maintainer) distinguish between build(local) and buildglobal (or buildship). In the first case, the global package store isn't involved at all. Jay has suggested to optimize towards building the whole distribution, but I'm not sure yet if that's the correct direction. Obviously, we need to support both perspectives. Much of the charm of the M3 build system for large projects is based on the way the work of the single developers can be split up and isolated. And in large projects there are of course more developers than build or release engineers. But then, there seems to have been no real use of CM3 for this kind of development for many years; most (all?) active users seem to work on their projects alone. So perhaps Jay is right after all? 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 Wed Aug 4 11:21:57 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 11:21:57 +0200 Subject: [M3devel] rmrec problems In-Reply-To: References: Message-ID: <20100804112157.d3anktcy5ck40gso@mail.elegosoft.com> Quoting Jay K : > There seems to another final problem, or maybe this was the problem > all along, or maybe maybe I introduced this with the previous fix (*) > stat on a symlink whose target has been deleted, apparently fails. > e.g. m3cc/target/gmp/.libs/libgmp.la -> ../libgmp.la > > *: maybe I introduced it: Well, before it might have been sensitive > to directory enumeration order. > My change deletes files and then subdirectories, making it no longer > sensitive that way. > > Fix will be to use lstat I believe. > > And I'll just report symlinks to be regular files. Treating symbolic links as files for the simple needs of the FSUtils module sounds OK, but the rm should of course only remove the link. I assume that's what you've done though, as removing the real file would require computing the real path. > And opening them can fail with file not found... which I'm sure will > break something somewhere -- enumerated files no longer necessarily > exist... Sounds OK, too. > Probably no win. > > Probably the original interfaces didn't consider symlinks, since > they aren't portable. > Yet without considering them, and composing rmrec on lower level > suppostedly portable interfaces..you can't ignore them. > Can't win. Yes, the old interface are portable, but not really sufficient for more sophisticated file systems which are more or less standard these days. Perhaps a careful review/redesign of this area would be a good idea, too. 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 Wed Aug 4 12:42:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 10:42:42 +0000 Subject: [M3devel] rmrec problems In-Reply-To: <20100804112157.d3anktcy5ck40gso@mail.elegosoft.com> References: , <20100804112157.d3anktcy5ck40gso@mail.elegosoft.com> Message-ID: > Treating symbolic links as files for the simple needs of the FSUtils > module sounds OK, but the rm should of course only remove the link. Right: my understanding and intent is that just the link, not the link target, is deleted. I can't guarantee at this point, but that was my understanding and intent. There was already *some* existing behavior. If you just delete the link, it'd do something. What didn't work is enumerating/stat'ing a link whose target doesn't exist, en route to deleting the link. (In our actual use, we do delete the target, because what we are enumerating and deleting both of the link and its target.) > for more sophisticated file systems which are more or less standard > these days. Perhaps a careful review/redesign of this area would be > a good idea, too. Even if they aren't "standard" -- even if not every host has them -- certainly many hosts do. I have done so much programming in the absence of symbolic links..I'm very uncertain how to reason about them. They allow for infinite loops in the namespace. Hardlinks too add additional confusion/meaning. Possible problem is that historically a symlink to an existing directory was reported as a directory. Now it is reported as a file. We could, expensively, first try stat, and if it fails for file/path not found, lstat instead. That might work. But I'd rather leave it as is. Maybe add another bit to the file status to indicate it is a symlink. Or possibly return the type as a new type, symlink, but no existing caller would know how to handle that. Probably adding another bit is reasonable, and update the Trestle file open dialogs to use a different icon. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Aug 4 12:56:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 10:56:13 +0000 Subject: [M3devel] m3override In-Reply-To: <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com> References: , , , , <20100730215051.GA23133@topoi.pooq.com>, , <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com> Message-ID: Specifically it is a warning about overriding the package you are building. The thing is, isn't the "bits and pieces overridden" model prone to just not work? Which pieces do you build vs. which do you leave alone? You need "everything" to be "fairly" consistent, for some definition of "everything" and "fairly". There is a larger unsolved problem here -- which parts of a system can you change independently of which parts? There are two extremes: one thing at a time, or everything at a time. The truth is generally in between: some things at a time. Which? "Everything" at a time is more difficult the larger you define "everything". "one" thing at a time, and again "one" possibly varies -- maybe you distribute .o files? "one" thing at at time leads to a combinatorial explosion of combination of "things" that are "supposed" to work. With some (enough?) runtime checking that a valid composition has been made. (Certainly Modula-3 tries much harder here than C.) I kind of espouse a model of "everything at time", but you can "pre-seed" the new package store/install with a copy/link of the original (as long you delete before writing over links). > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. Do you mean like, regarding $ORIGIN? Or something else? I'm too blame for giving us $ORIGIN, and I'm now very ambivalent about it. libtool + relink upon install seems the better approach and is widely used in practise. e.g. OpenBSD. This has a side benefit that uninstalled/unshipped dynamic binaries do work. I do suspect $ORIGIN was an improvement, since we don't relink upon install. There is also a hybrid suggestion of what I have suggested and the current model. You can still "build" into a new empty directory, with a hierarchy matching the install, leaving open either later install in-place or "reroot". I think, really, I have to back down from $ORIGIN, which restores "pick and chose" to work when it can, we can still, as I said, build into an install-like structure, and install by "reroot" or "delete and copy". I think the key is doing relink upon install. Along with, no longer distributing fully built binaries. There is a big task here but I think we have seen enough real problems and discussed enough the theory, to end up at a conclusion -- no $ORIGIN, no binaries, distribute C source, assembly source (or maybe .o files), and do final link on the target. We can distribute some common binaries, like with hardcoded install location. The hudon builds might be tricky, since if we build binaries to install to /usr/local/cm3, we can't then install and test them. Unless maybe chroot is possible as non-root?? Possibly Hudson builds would install to $HOME/... and just the final distribution wouldn't. Probably. I kind of..can't think of the word...really don't like this conclusion. Am nervous. How many people install binaries vs. compile/link? This would be signing up for much additional headache all around? Compile/link would fail for lots of people and we'd have to help them a lot more? Or it's not that bad and we just have to do it? - Jay > Date: Wed, 4 Aug 2010 08:49:30 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3override > > I wouldn't worry much about the warning Jay removed. > It only said that an override wasn't used, which is the default > behaviour of cm3 (without -x or -override option). One could argue > that if one wanted this warning, one should use an option like > -warn=overrides or -warn=all (which don't actually exist (yet)). > > However, I'd still like others to think about the two perspectives > one can take here, and what should be the direction we are tweaking > our build system. > > Traditionally, the focus was on the package view, i.e. the view of > one developer, and not a whole system. The builder was designed to > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. > With this focus, overrides are the sole responsibility of the > developer, and one could argue that he should know exactly what > he does if he uses them. > > In the CM3 distribution, I used the override feature to allow > building the whole set of package in the workspace, which can be > seen equivalent to use a completely different package pool. > The scripts (which originally were only meant as a tool for the > distribution maintainer) distinguish between build(local) and > buildglobal (or buildship). In the first case, the global package > store isn't involved at all. > > Jay has suggested to optimize towards building the whole distribution, > but I'm not sure yet if that's the correct direction. Obviously, > we need to support both perspectives. Much of the charm of the > M3 build system for large projects is based on the way the work > of the single developers can be split up and isolated. And in large > projects there are of course more developers than build or release > engineers. But then, there seems to have been no real use of CM3 for this > kind of development for many years; most (all?) active users seem to > work on their projects alone. So perhaps Jay is right after all? > > 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 Wed Aug 4 13:31:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 11:31:56 +0000 Subject: [M3devel] m3override In-Reply-To: References: , ,,, , , <20100730215051.GA23133@topoi.pooq.com>, , , , <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com>, Message-ID: ps: another suggestion here: Don't use overrides in Hudson or package building. Instead either build from scratch or with a new install that is a copy of the current (ie. of m3core/libm3). I alread automated this in make-dist.py, which is a based on some other *.sh. And then copy/swap at the end, or after some testing. Except, er, um, either this is with $ORIGIN, or with relink upon install -- not just copy/swap. The central sticking point in "all" this, in software configuration in general -- is "run path". And then, delete all the m3overrides files in the tree. And then optionally remove the entire mechanism, or leave it alone, unused, to bitrot. To some extent this is: don't bother implementing a mechanism in cm3, just do it in scripts. > M3 build system for large projects is based on the way the work > of the single developers can be split up and isolated. And in large Imagine a system composed of five pieces: bottom, almost bottom, middle, almost top, top. The developer of "top" has it easy, he uses the "existing" bottom, almost bottom, middle, almost top. What are the developers of any other piece to do? There are at least two factors to consider: run path public interfaces Even if public interfaces are unchanged, developer building a new "almost top", must either put it where "top" expects, or rebuild top to get it from the new location. It has been said that LD_LIBRARY_PATH is for development scenarios. So maybe that is the answer. To whatever extent systems are composed of just bottom and top and nobody changes bottom, which I think is actually pretty common, no problem, and people don't even understand the potential problem (I theorize). But that seems..wrong. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 4 Aug 2010 10:56:13 +0000 Subject: Re: [M3devel] m3override Specifically it is a warning about overriding the package you are building. The thing is, isn't the "bits and pieces overridden" model prone to just not work? Which pieces do you build vs. which do you leave alone? You need "everything" to be "fairly" consistent, for some definition of "everything" and "fairly". There is a larger unsolved problem here -- which parts of a system can you change independently of which parts? There are two extremes: one thing at a time, or everything at a time. The truth is generally in between: some things at a time. Which? "Everything" at a time is more difficult the larger you define "everything". "one" thing at a time, and again "one" possibly varies -- maybe you distribute .o files? "one" thing at at time leads to a combinatorial explosion of combination of "things" that are "supposed" to work. With some (enough?) runtime checking that a valid composition has been made. (Certainly Modula-3 tries much harder here than C.) I kind of espouse a model of "everything at time", but you can "pre-seed" the new package store/install with a copy/link of the original (as long you delete before writing over links). > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. Do you mean like, regarding $ORIGIN? Or something else? I'm too blame for giving us $ORIGIN, and I'm now very ambivalent about it. libtool + relink upon install seems the better approach and is widely used in practise. e.g. OpenBSD. This has a side benefit that uninstalled/unshipped dynamic binaries do work. I do suspect $ORIGIN was an improvement, since we don't relink upon install. There is also a hybrid suggestion of what I have suggested and the current model. You can still "build" into a new empty directory, with a hierarchy matching the install, leaving open either later install in-place or "reroot". I think, really, I have to back down from $ORIGIN, which restores "pick and chose" to work when it can, we can still, as I said, build into an install-like structure, and install by "reroot" or "delete and copy". I think the key is doing relink upon install. Along with, no longer distributing fully built binaries. There is a big task here but I think we have seen enough real problems and discussed enough the theory, to end up at a conclusion -- no $ORIGIN, no binaries, distribute C source, assembly source (or maybe .o files), and do final link on the target. We can distribute some common binaries, like with hardcoded install location. The hudon builds might be tricky, since if we build binaries to install to /usr/local/cm3, we can't then install and test them. Unless maybe chroot is possible as non-root?? Possibly Hudson builds would install to $HOME/... and just the final distribution wouldn't. Probably. I kind of..can't think of the word...really don't like this conclusion. Am nervous. How many people install binaries vs. compile/link? This would be signing up for much additional headache all around? Compile/link would fail for lots of people and we'd have to help them a lot more? Or it's not that bad and we just have to do it? - Jay > Date: Wed, 4 Aug 2010 08:49:30 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3override > > I wouldn't worry much about the warning Jay removed. > It only said that an override wasn't used, which is the default > behaviour of cm3 (without -x or -override option). One could argue > that if one wanted this warning, one should use an option like > -warn=overrides or -warn=all (which don't actually exist (yet)). > > However, I'd still like others to think about the two perspectives > one can take here, and what should be the direction we are tweaking > our build system. > > Traditionally, the focus was on the package view, i.e. the view of > one developer, and not a whole system. The builder was designed to > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. > With this focus, overrides are the sole responsibility of the > developer, and one could argue that he should know exactly what > he does if he uses them. > > In the CM3 distribution, I used the override feature to allow > building the whole set of package in the workspace, which can be > seen equivalent to use a completely different package pool. > The scripts (which originally were only meant as a tool for the > distribution maintainer) distinguish between build(local) and > buildglobal (or buildship). In the first case, the global package > store isn't involved at all. > > Jay has suggested to optimize towards building the whole distribution, > but I'm not sure yet if that's the correct direction. Obviously, > we need to support both perspectives. Much of the charm of the > M3 build system for large projects is based on the way the work > of the single developers can be split up and isolated. And in large > projects there are of course more developers than build or release > engineers. But then, there seems to have been no real use of CM3 for this > kind of development for many years; most (all?) active users seem to > work on their projects alone. So perhaps Jay is right after all? > > 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 wagner at elegosoft.com Wed Aug 4 14:58:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 14:58:30 +0200 Subject: [M3devel] m3override Message-ID: <20100804145830.yz17as1yo04sgc0s@mail.elegosoft.com> Quoting Jay K : > ps: another suggestion here: > Don't use overrides in Hudson or package building. > Instead either build from scratch or with a new install that is a > copy of the current (ie. of m3core/libm3). I alread automated this > in make-dist.py, which is a based on some other *.sh. > And then copy/swap at the end, or after some testing. > Except, er, um, either this is with $ORIGIN, or with relink upon > install -- not just copy/swap. > > The central sticking point in "all" this, in software configuration > in general -- is "run path". > > And then, delete all the m3overrides files in the tree. And then > optionally remove the entire mechanism, or leave it alone, unused, > to bitrot. > > To some extent this is: don't bother implementing a mechanism in > cm3, just do it in scripts. I've got no time for large changes, so we'll see if anybody cares to implement anything. >> M3 build system for large projects is based on the way the work >> of the single developers can be split up and isolated. And in large > > Imagine a system composed of five pieces: bottom, almost bottom, > middle, almost top, top. > The developer of "top" has it easy, he uses the "existing" bottom, > almost bottom, middle, almost top. > What are the developers of any other piece to do? > There are at least two factors to consider: > run path > public interfaces > > Even if public interfaces are unchanged, developer building a new > "almost top", must either put it where "top" expects, or rebuild top > to get it from the new location. > > It has been said that LD_LIBRARY_PATH is for development scenarios. > So maybe that is the answer. > > To whatever extent systems are composed of just bottom and top and > nobody changes bottom, which I think is actually pretty common, no > problem, and people don't even understand the potential problem (I > theorize). But that seems..wrong. Well, you see I've got the view of somebody building very large systems (much larger than the CM3 distribution) for commerical use. I've been working in such projects for the recent years; they're programmed in C/C++ and Java (and make and ClearCase and Perl scripts and ...), and build management and correct dependency tracking and use is always a nightmare. M3 with its powerful abstractions would be a great improvement there, but of course that's completely out of the question. But nonetheless it's still interesting to think about how M3 would actually compete in this domain. From a manager and user point of view, there are business functions which may be attached to some real or virtual machine or to some computing farm. From an architects view there are software layers, components with interfaces and implementations, containers for running processes and threads etc. And of course there are large external systems that are used or with which data must be exchanged. From a build and release engineers point of view, there are hundred thousands of files most of which exist in several hundred versions of which about a dozen or more are part of valid and still supported or actively developed configurations, that must build and play together consistently. And these must be unit tested, integration tested, system tested and performance tested. Everything (more or less) changes continually, starting with the requirements :-) Nobody has a complete overview, but the developers must be isolated and given a usable working configuration and setup to accomplish their tasks. This is where abstraction and information hiding show the biggest benefits. No developer here is able to build the whole system; most are even not allowed to read most of the code (if by accident or on purpose isn't always clear). And of course development teams are distributed to several sites around the world. So I'm not thinking about minor technical issues like $ORIGIN or LD_LIBRARY_PATH or about how we are best able to distribute the cm3 packages, but rather about M3 and its package and other abstraction mechanisms would stand its ground in such a project. And if we should really consider that or just be satisfied with our small CM3 community and use cases. 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 Wed Aug 4 15:37:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 13:37:48 +0000 Subject: [M3devel] m3cc package failures ignored? Message-ID: There's some problem, I've been noticing a while on my machine(s) where failure to build m3cc isn't noticed. e.g.: http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/21/console ??? ... -rw-r--r-- 1 hudson hudson??? 6872 2010-07-28 13:47 xstrerror.o -rw-r--r-- 1 hudson hudson??? 6736 2010-07-28 13:47 xstrndup.o ./libiberty/testsuite: total 4 -rw-r--r-- 1 hudson hudson 2722 2010-07-28 13:44 Makefile Fatal Error: package build failed ?==> m3-sys/m3cc done -- and then it keeps going -- === package m3-libs/m3core === ?+++ cm3 -build -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3' $RARGS? && cm3 -ship $RARGS -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3'? +++ From wagner at elegosoft.com Wed Aug 4 17:26:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 17:26:34 +0200 Subject: [M3devel] m3cc package failures ignored? In-Reply-To: References: Message-ID: <20100804172634.tt8y73lcwk8k40cg@mail.elegosoft.com> Quoting Jay K : > There's some problem, I've been noticing a while on my machine(s) > where failure to build m3cc isn't noticed. > > e.g.: > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/21/console > ... > -rw-r--r-- 1 hudson hudson??? 6872 2010-07-28 13:47 xstrerror.o > -rw-r--r-- 1 hudson hudson??? 6736 2010-07-28 13:47 xstrndup.o > > ./libiberty/testsuite: > total 4 > -rw-r--r-- 1 hudson hudson 2722 2010-07-28 13:44 Makefile > Fatal Error: package build failed > ?==> m3-sys/m3cc done > > -- and then it keeps going -- > > === package m3-libs/m3core === > ?+++ cm3 -build > -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3' $RARGS? && cm3 -ship $RARGS -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3'? > +++ That's probably due to a typo in the pkgmap script: Index: scripts/pkgmap.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/pkgmap.sh,v retrieving revision 1.58 diff -u -u -r1.58 pkgmap.sh --- scripts/pkgmap.sh 23 Jul 2010 16:08:08 -0000 1.58 +++ scripts/pkgmap.sh 4 Aug 2010 15:23:58 -0000 @@ -532,4 +532,4 @@ fi fi -[ -n "${OK}" ] || exit `printf "{$REDPKGS}" | wc | awk '{print $1}'` +[ -n "${OK}" ] || exit `printf "${REDPKGS}" | wc | awk '{print $1}'` Let me know when you see that again, 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 Aug 5 14:43:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 12:43:15 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? Message-ID: Olaf, this looks maybe like over aggressive manual cleanup on your part?? http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console S=/Volumes/maxstore1/home/hudson/workspace/cm3-current-build-PPC_DARWIN LASTREL=5.4.0 INSTROOT_REL=/Users/hudson/work/cm3-inst/apple/rel-5.4.0 INSTROOT_POK=/Users/hudson/work/cm3-inst/apple/prev-ok INSTROOT_LOK=/Users/hudson/work/cm3-inst/apple/last-ok INSTROOT_CUR=/Users/hudson/work/cm3-inst/apple/current CM3_OSTYPE=POSIX CM3_TARGET=PPC_DARWIN BINDISTMIN=/Users/hudson/work/cm3-min-POSIX-PPC_DARWIN-5.4.0.tgz CM3CVSSERVER=birch.elegosoft.com CM3CVSROOT=birch.elegosoft.com:/usr/cvs BINDISTMIN_NAME=cm3-min-POSIX-PPC_DARWIN-5.4.0.tgz BINDISTMIN=/Users/hudson/work/cm3-min-POSIX-PPC_DARWIN-5.4.0.tgz CM3CVSUSER= testing ssh birch.elegosoft.com.. ssh birch.elegosoft.com ok deleting outdated packages cache /Volumes/maxstore1/home/hudson/workspace/cm3-current-build-PPC_DARWIN/cm3/scripts/PKGS cp: /Users/hudson/work/cm3-inst/apple/last-ok: No such file or directory Finished: FAILURE ?- Jay From wagner at elegosoft.com Thu Aug 5 15:06:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 05 Aug 2010 15:06:13 +0200 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: Message-ID: <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com> Quoting Jay K : > Olaf, this looks maybe like over aggressive manual cleanup on your part?? > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console Well, kind of auto-cleanup actually :-) The external disk of that machine failed several days ago. I haven't got round to buy a new one, but tried to set up NFS access to my FreeBSD machine in a hurry this morning. That went well, but all the cm3 data are lost, so I had to install a compiler from release 5.8.6 (succeeded) and then boot the regression testing setup again (failed), see: http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console It's the gcc -m 32 issue again; I don't know yet if it's using the wrong C compiler, or something has changed in the config again, as I haven't direct access now. Maybe this evening. 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 Aug 5 15:54:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 13:54:24 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com> References: , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com> Message-ID: Ah, can you send the output of gcc -gstabs+ -fPIC -m32 -c -x c /dev/null gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null and try the updated Darwin.common? Thanks, ?- Jay ---------------------------------------- > Date: Thu, 5 Aug 2010 15:06:13 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: PPC_DARWIN failure missing last-ok? > > Quoting Jay K : > > > Olaf, this looks maybe like over aggressive manual cleanup on your part?? > > > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > > Well, kind of auto-cleanup actually :-) > > The external disk of that machine failed several days ago. I haven't > got round to buy a new one, but tried to set up NFS access to my FreeBSD > machine in a hurry this morning. That went well, but all the cm3 data > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > and then boot the regression testing setup again (failed), see: > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > C compiler, or something has changed in the config again, as I haven't > direct access now. Maybe this evening. > > 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 Aug 5 15:58:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 13:58:33 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, Message-ID: (and ssh access would help) ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Thu, 5 Aug 2010 13:54:24 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? > > > Ah, can you send the output of > > gcc -gstabs+ -fPIC -m32 -c -x c /dev/null > gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null > > and try the updated Darwin.common? > > Thanks, > - Jay > > ---------------------------------------- > > Date: Thu, 5 Aug 2010 15:06:13 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: PPC_DARWIN failure missing last-ok? > > > > Quoting Jay K : > > > > > Olaf, this looks maybe like over aggressive manual cleanup on your part?? > > > > > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > > > > Well, kind of auto-cleanup actually :-) > > > > The external disk of that machine failed several days ago. I haven't > > got round to buy a new one, but tried to set up NFS access to my FreeBSD > > machine in a hurry this morning. That went well, but all the cm3 data > > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > > and then boot the regression testing setup again (failed), see: > > > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > > > > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > > C compiler, or something has changed in the config again, as I haven't > > direct access now. Maybe this evening. > > > > 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 Thu Aug 5 16:14:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 05 Aug 2010 16:14:15 +0200 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, Message-ID: <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com> Quoting Jay K : > (and ssh access would help) I just added your gcc lines below to the boot job; I also changed the checkout of the release branch to the trunk (maybe it will work now). The job is still running. See http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/4/console You should be able to access the machine as user hudson from birch (if you can su to hudson there) at port 223 at luthien.dyndns.org if I remember correctly. If you cannot su to hudson, I need to place your public ssh key on the machine, but cannot do that before this evening, too. As usual, only HTTP access from here. Olaf > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> Date: Thu, 5 Aug 2010 13:54:24 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? >> >> >> Ah, can you send the output of >> >> gcc -gstabs+ -fPIC -m32 -c -x c /dev/null >> gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null >> >> and try the updated Darwin.common? >> >> Thanks, >> - Jay >> >> ---------------------------------------- >> > Date: Thu, 5 Aug 2010 15:06:13 +0200 >> > From: wagner at elegosoft.com >> > To: jay.krell at cornell.edu >> > CC: m3devel at elegosoft.com >> > Subject: Re: PPC_DARWIN failure missing last-ok? >> > >> > Quoting Jay K : >> > >> > > Olaf, this looks maybe like over aggressive manual cleanup on >> your part?? >> > > >> > > >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console >> > >> > Well, kind of auto-cleanup actually :-) >> > >> > The external disk of that machine failed several days ago. I haven't >> > got round to buy a new one, but tried to set up NFS access to my FreeBSD >> > machine in a hurry this morning. That went well, but all the cm3 data >> > are lost, so I had to install a compiler from release 5.8.6 (succeeded) >> > and then boot the regression testing setup again (failed), see: >> > >> > >> http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console >> > >> > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong >> > C compiler, or something has changed in the config again, as I haven't >> > direct access now. Maybe this evening. >> > >> > 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 >> > >> > -- 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 Aug 5 16:20:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:20:23 +0000 Subject: [M3devel] linuxlibc6 crashing Message-ID: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-LINUXLIBC6/52/console cm3 is /home/hudson/work/cm3-inst/xlin2/last-ok/bin/cm3 *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 *** ./defs.sh: line 728: 14797 Aborted cm3 -version *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 *** >>> test_m3tests error extract: /usr/bin/find: `LINUXLIBC6': No such file or directory >>> OK test_m3tests 2010-08-05-14-07-28 /home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6 === 2010-08-05 14:07:31 cm3 m3tests run done cp: cannot stat `/home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6/cm3/m3-sys/m3tests/m3tests.html': No such file or directory I'm aware, not sure what the problem is, not sure it is widespread. Seems kind of like struct stat overflow..and the recent change from stat to lstat, but really..seems corect as well... Might have to intervene manually..but I don't know what the fix is yet. ?- Jay From jay.krell at cornell.edu Thu Aug 5 16:19:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:19:13 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com> References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, , , <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com> Message-ID: Cool. I think manually updating the config might be required. We'll see. I'm going to have reduced hours here for about 10 days soon.. Thanks, ?- Jay ---------------------------------------- > Date: Thu, 5 Aug 2010 16:14:15 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] PPC_DARWIN failure missing last-ok? > > Quoting Jay K : > > > (and ssh access would help) > > I just added your gcc lines below to the boot job; I also changed > the checkout of the release branch to the trunk (maybe it will work > now). The job is still running. See > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/4/console > > You should be able to access the machine as user hudson from birch > (if you can su to hudson there) at port 223 at luthien.dyndns.org > if I remember correctly. > > If you cannot su to hudson, I need to place your public ssh key on > the machine, but cannot do that before this evening, too. As usual, > only HTTP access from here. > > Olaf > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: wagner at elegosoft.com > >> Date: Thu, 5 Aug 2010 13:54:24 +0000 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? > >> > >> > >> Ah, can you send the output of > >> > >> gcc -gstabs+ -fPIC -m32 -c -x c /dev/null > >> gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null > >> > >> and try the updated Darwin.common? > >> > >> Thanks, > >> - Jay > >> > >> ---------------------------------------- > >> > Date: Thu, 5 Aug 2010 15:06:13 +0200 > >> > From: wagner at elegosoft.com > >> > To: jay.krell at cornell.edu > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: PPC_DARWIN failure missing last-ok? > >> > > >> > Quoting Jay K : > >> > > >> > > Olaf, this looks maybe like over aggressive manual cleanup on > >> your part?? > >> > > > >> > > > >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > >> > > >> > Well, kind of auto-cleanup actually :-) > >> > > >> > The external disk of that machine failed several days ago. I haven't > >> > got round to buy a new one, but tried to set up NFS access to my FreeBSD > >> > machine in a hurry this morning. That went well, but all the cm3 data > >> > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > >> > and then boot the regression testing setup again (failed), see: > >> > > >> > > >> http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > >> > > >> > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > >> > C compiler, or something has changed in the config again, as I haven't > >> > direct access now. Maybe this evening. > >> > > >> > 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 > >> > > >> > > > > > > -- > 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 Aug 5 16:41:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:41:37 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, , , <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com>, Message-ID: ok I manually fixed it up. pwd /Users/hudson/work/cm3-inst/apple/rel-5.8.6/bin/config mv Darwin.common Darwin.common.1 vi Darwin.common diff Darwin.common.1 Darwin.common Something like: released 5.8.6 doesn't work on PPC_DARWIN 10.3, needs slight config edit. Fixed perhaps in head. We'll see. gcc_select 4.0 as root would fix it. Given that -arch is supported, probably no point to -m32/64. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] PPC_DARWIN failure missing last-ok? > Date: Thu, 5 Aug 2010 14:19:13 +0000 > > > Cool. I think manually updating the config might be required. We'll see. > I'm going to have reduced hours here for about 10 days soon.. > > Thanks, > - Jay > > ---------------------------------------- > > Date: Thu, 5 Aug 2010 16:14:15 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] PPC_DARWIN failure missing last-ok? > > > > Quoting Jay K : > > > > > (and ssh access would help) > > > > I just added your gcc lines below to the boot job; I also changed > > the checkout of the release branch to the trunk (maybe it will work > > now). The job is still running. See > > > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/4/console > > > > You should be able to access the machine as user hudson from birch > > (if you can su to hudson there) at port 223 at luthien.dyndns.org > > if I remember correctly. > > > > If you cannot su to hudson, I need to place your public ssh key on > > the machine, but cannot do that before this evening, too. As usual, > > only HTTP access from here. > > > > Olaf > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: wagner at elegosoft.com > > >> Date: Thu, 5 Aug 2010 13:54:24 +0000 > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? > > >> > > >> > > >> Ah, can you send the output of > > >> > > >> gcc -gstabs+ -fPIC -m32 -c -x c /dev/null > > >> gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null > > >> > > >> and try the updated Darwin.common? > > >> > > >> Thanks, > > >> - Jay > > >> > > >> ---------------------------------------- > > >> > Date: Thu, 5 Aug 2010 15:06:13 +0200 > > >> > From: wagner at elegosoft.com > > >> > To: jay.krell at cornell.edu > > >> > CC: m3devel at elegosoft.com > > >> > Subject: Re: PPC_DARWIN failure missing last-ok? > > >> > > > >> > Quoting Jay K : > > >> > > > >> > > Olaf, this looks maybe like over aggressive manual cleanup on > > >> your part?? > > >> > > > > >> > > > > >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > > >> > > > >> > Well, kind of auto-cleanup actually :-) > > >> > > > >> > The external disk of that machine failed several days ago. I haven't > > >> > got round to buy a new one, but tried to set up NFS access to my FreeBSD > > >> > machine in a hurry this morning. That went well, but all the cm3 data > > >> > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > > >> > and then boot the regression testing setup again (failed), see: > > >> > > > >> > > > >> http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > > >> > > > >> > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > > >> > C compiler, or something has changed in the config again, as I haven't > > >> > direct access now. Maybe this evening. > > >> > > > >> > 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 > > >> > > > >> > > > > > > > > > > > -- > > 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 Aug 5 16:48:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:48:08 +0000 Subject: [M3devel] linuxlibc6 crashing In-Reply-To: References: Message-ID: (manual intervention) I cross built cm3 and copied that over the crashing one. We'll see. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Thu, 5 Aug 2010 14:20:23 +0000 > Subject: [M3devel] linuxlibc6 crashing > > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-LINUXLIBC6/52/console > > cm3 is /home/hudson/work/cm3-inst/xlin2/last-ok/bin/cm3 > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > *** > > ./defs.sh: line 728: 14797 Aborted cm3 -version > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > *** > > >>> test_m3tests error extract: > /usr/bin/find: `LINUXLIBC6': No such file or directory > >>> OK test_m3tests 2010-08-05-14-07-28 /home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6 > === 2010-08-05 14:07:31 cm3 m3tests run done > cp: cannot stat `/home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6/cm3/m3-sys/m3tests/m3tests.html': No such file or directory > > > I'm aware, not sure what the problem is, not sure it is widespread. > > Seems kind of like struct stat overflow..and the recent change from stat to lstat, but really..seems corect as well... > Might have to intervene manually..but I don't know what the fix is yet. > > - Jay > > > > > From jay.krell at cornell.edu Fri Aug 6 11:23:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 6 Aug 2010 09:23:16 +0000 Subject: [M3devel] Hudson/PPC_DARWIN Message-ID: http://hudson.modula3.com:8080/job/cm3-current-m3cc-PPC_DARWIN/19/console config.status: linking ../../gcc/gmp/mpn/generic/gmp-mparam.h to gmp-mparam.h make[1]: Entering directory `/Volumes/luthien/home/hudson2/workspace/cm3-m3cc-PPC_DARWIN/cm3/m3-sys/m3cc/PPC_DARWIN/gmp' gcc `test -f 'gen-fac_ui.c' || echo '../../gcc/gmp/'`gen-fac_ui.c -o gen-fac_ui /var/tmp//ccZolN95.s:unknown:FATAL:can't write output file $TMPDIR not placed well? ? - Jay From jay.krell at cornell.edu Fri Aug 6 11:24:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 6 Aug 2010 09:24:36 +0000 Subject: [M3devel] Hudson/NT386 Message-ID: NT386 node offline? Then again, it is in good shape: http://hudson.modula3.com:8080/job/cm3-current-build-NT386/25/console still need to clean this up: P m3-sys/cminstall/src/config-no-install/MIPS64EL_OPENBSD cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' on a few machines. ?- Jay From wagner at elegosoft.com Fri Aug 6 12:04:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 06 Aug 2010 12:04:59 +0200 Subject: [M3devel] Hudson/PPC_DARWIN In-Reply-To: References: Message-ID: <20100806120459.edxuddkg000sksos@mail.elegosoft.com> Quoting Jay K : > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-PPC_DARWIN/19/console > > config.status: linking ../../gcc/gmp/mpn/generic/gmp-mparam.h to gmp-mparam.h > make[1]: Entering directory > `/Volumes/luthien/home/hudson2/workspace/cm3-m3cc-PPC_DARWIN/cm3/m3-sys/m3cc/PPC_DARWIN/gmp' > gcc `test -f 'gen-fac_ui.c' || echo '../../gcc/gmp/'`gen-fac_ui.c -o > gen-fac_ui > /var/tmp//ccZolN95.s:unknown:FATAL:can't write output file > > > $TMPDIR not placed well? No, Hudson had a wrong root path configured, which was now accidentally on the root disk with the external mount missing, so it didn't really use the space on the NFS. I've fixed it now. 1.5 GB are free again on root and should stay so. 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 Aug 6 12:11:01 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 06 Aug 2010 12:11:01 +0200 Subject: [M3devel] Hudson/NT386 In-Reply-To: References: Message-ID: <20100806121101.ikn8jhkxs0cgo088@mail.elegosoft.com> Quoting Jay K : > NT386 node offline? The connection to this machine is still unstable, it goes offline whenever I turn my eyes. I'm afraid Elego won't be able to provide something better here, so other resources for continous integration on Windows would still be welcome. 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 Fri Aug 6 12:20:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 6 Aug 2010 10:20:07 +0000 Subject: [M3devel] hudson nodes Message-ID: most/all of my Hudson nodes will be down August 6 - 15. I'll probably leave just Linux/x86. They will all be back late August 15. - Jay From jay.krell at cornell.edu Sat Aug 7 08:21:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 06:21:44 +0000 Subject: [M3devel] Hudson/CVS/Tag release Message-ID: We should delete these checkouts/workspaces to remove any doubt about targeting head? (just the last two, mainly, but the timestamps being back in July is a bit off) I was looking into the: cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' stuff, which I've been cleaning up just by deleting. % ls -l? */cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21? 7 Aug 08:03 cm3-current-build-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21 18 Jul 22:46 cm3-current-m3cc-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21? 6 Aug 20:40 cm3-current-test-all-pkgs-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21 19 Jul 23:28 cm3-current-test-m3tests-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 19? 8 Jul 17:34 cm3-makedist-FreeBSD4/cm3/CVS/Tag -rw-rw----? 1 hudson? Ghudson? 24? 9 Jul 12:22 cm3-test-all-pkgs-FreeBSD4/cm3/CVS/Tag new.elego.de [~/workspace] hudson % cat */cm3/CVS/Tag D2010.08.07.05.59.47 D2010.07.18.20.45.58 D2010.08.06.18.37.22 D2010.07.19.21.28.10 Nrelease_CM3_5_8_6 Trelease_branch_cm3_5_8 new.elego.de [~/workspace] hudson % hostname new.elego.de new.elego.de [~/workspace] hudson % pwd /pub/users/hudson/workspace new.elego.de [~/workspace] hudson % uname -a FreeBSD new.elego.de 6.4-RELEASE-p5 FreeBSD 6.4-RELEASE-p5 #1: Sun Jun 14 14:03:37 CEST 2009???? root at new.elego.de:/usr/obj/usr/src/sys/GENERIC? i386 new.elego.de [~/workspace] hudson From jay.krell at cornell.edu Sat Aug 7 08:27:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 06:27:07 +0000 Subject: [M3devel] linuxlibc6 crashing In-Reply-To: References: , Message-ID: same thing here: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/15/consoleFull but it went away: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/16/consoleFull ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] linuxlibc6 crashing > Date: Thu, 5 Aug 2010 14:48:08 +0000 > > > (manual intervention) > I cross built cm3 and copied that over the crashing one. We'll see. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Thu, 5 Aug 2010 14:20:23 +0000 > > Subject: [M3devel] linuxlibc6 crashing > > > > > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-LINUXLIBC6/52/console > > > > cm3 is /home/hudson/work/cm3-inst/xlin2/last-ok/bin/cm3 > > > > > > *** > > *** runtime error: > > *** Segmentation violation - possible attempt to dereference NIL > > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > > *** > > > > ./defs.sh: line 728: 14797 Aborted cm3 -version > > > > > > *** > > *** runtime error: > > *** Segmentation violation - possible attempt to dereference NIL > > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > > *** > > > > >>> test_m3tests error extract: > > /usr/bin/find: `LINUXLIBC6': No such file or directory > > >>> OK test_m3tests 2010-08-05-14-07-28 /home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6 > > === 2010-08-05 14:07:31 cm3 m3tests run done > > cp: cannot stat `/home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6/cm3/m3-sys/m3tests/m3tests.html': No such file or directory > > > > > > I'm aware, not sure what the problem is, not sure it is widespread. > > > > Seems kind of like struct stat overflow..and the recent change from stat to lstat, but really..seems corect as well... > > Might have to intervene manually..but I don't know what the fix is yet. > > > > - Jay > > > > > > > > > > > From wagner at elegosoft.com Sat Aug 7 09:05:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 07 Aug 2010 09:05:26 +0200 Subject: [M3devel] Hudson/CVS/Tag release In-Reply-To: References: Message-ID: <20100807090526.9a6odj4lwsowkc8s@mail.elegosoft.com> Quoting Jay K : > We should delete these checkouts/workspaces to remove any doubt > about targeting head? The last 2 were last used to build on the release branch. Those for the trunk all have the -current- in the name. You may remove them if you need space. The last contains some HTML results that might be worth to preserve though. Why is there any doubt which jobs follow head and which don't? Olaf > (just the last two, mainly, but the timestamps being back in July is > a bit off) > I was looking into the: > > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for > `m3-sys/m3cc/gcc/fixincludes' > > stuff, which I've been cleaning up just by deleting. > > % ls -l? */cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21? 7 Aug 08:03 > cm3-current-build-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21 18 Jul 22:46 > cm3-current-m3cc-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21? 6 Aug 20:40 > cm3-current-test-all-pkgs-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21 19 Jul 23:28 > cm3-current-test-m3tests-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 19? 8 Jul 17:34 > cm3-makedist-FreeBSD4/cm3/CVS/Tag > -rw-rw----? 1 hudson? Ghudson? 24? 9 Jul 12:22 > cm3-test-all-pkgs-FreeBSD4/cm3/CVS/Tag > new.elego.de [~/workspace] hudson > % cat */cm3/CVS/Tag > D2010.08.07.05.59.47 > D2010.07.18.20.45.58 > D2010.08.06.18.37.22 > D2010.07.19.21.28.10 > Nrelease_CM3_5_8_6 > Trelease_branch_cm3_5_8 > new.elego.de [~/workspace] hudson > % hostname > new.elego.de > new.elego.de [~/workspace] hudson > % pwd > /pub/users/hudson/workspace > new.elego.de [~/workspace] hudson > % uname -a > FreeBSD new.elego.de 6.4-RELEASE-p5 FreeBSD 6.4-RELEASE-p5 #1: Sun > Jun 14 14:03:37 CEST 2009???? > root at new.elego.de:/usr/obj/usr/src/sys/GENERIC? i386 > new.elego.de [~/workspace] hudson > > -- 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 Sat Aug 7 16:30:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 14:30:19 +0000 Subject: [M3devel] more Hudson nodes? more help in general? Message-ID: Hey, I'm hoping we can get more people helping more. Coding, features, fixing bugs, etc. However one of the easiest things I'd like to see is a few more Hudson nodes. Is anyone out there running e.g. NetBSD on x86 or AMD64? ? They would be the easiest, sort of, to setup. I will help anyone. ? Or Solaris on SPARC (replace mine) or x86? (Yes I know about opencsw, but the network ? topology is seemingly difficult.) Or heck, Linux or OpenBSD on x86? (replace mine) x86/AMD64 in particular has better availability of Java VMs, which we need. Or, Linux now has good across the board Java support. And can setup dynamic DNS or has static IP? We could use NT386 but I know the setup might not be so easy. There are other viable machines, e.g. one of the new or old Linux/mips. Or likely some of the obscure systems like HP-UX, AIX, Irix. If anyone here is actively running one of these, keeps machine on, speak up. (At some point, I'd like to have Hudson wake-on-lan the machines, or have the machines scheduled to wake up daily check for work, and then back to sleep after completing any queued work; the second option doesn't require Hudson support.) The machine can be quite low end. Many of mine are old laptops, or very old either way. Around $200, years ago. Any other projects in the system people are interested in helping out on, with ? time/coding, please speak up if you need help. If you need ideas, or assistance, etc. Thanks, ?- Jay From jay.krell at cornell.edu Sat Aug 7 16:53:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 14:53:12 +0000 Subject: [M3devel] build_platform in archive names In-Reply-To: <20100807105849.2B48724740EC@birch.elegosoft.com> References: <20100807105849.2B48724740EC@birch.elegosoft.com> Message-ID: Thanks! I want something slightly different for NT platforms. NT doesn't have the binary incompatibility and cross-build problem of Unix, at the OS level. ? (and commercial Unix isn't so bad either I think these days) However it does sort of have it at the C runtime level. i.e. There is no need to say e.g. XP/Vista/Win7/NT5.1/6.0/6.1, but there is a need to say e.g. msvc70/71/80/90/100. And there probably is a need for Cygwin-1.5 vs. Cygwin-1.7 (ie. exactly what you have). You can see in pylib.py: def FormInstallRoot(PackageSetName): ??? AltConfig = {"NT386":"x86"}.get(Config, Config) ??? a = os.path.join(GetStage(), "cm3-" + PackageSetName + "-" + AltConfig + "-" + CM3VERSION) ??? if Config == "NT386" or Config == "I386_NT": ??????? a = a + "-VC" + GetVisualCPlusPlusVersion() ??? else: ??????? b = os.popen("uname -sr").read() ??????? b = re.sub("Linux 2.4\..+$", "Linux2.4", b) ??????? b = re.sub("Linux 2.6\..+$", "", b) ??????? b = re.sub("-.+$", "", b) ??????? b = re.sub("SunOS", "Solaris", b) ??????? b = re.sub("[ \r\n]", "", b) ??????? a = a + "-" + b ??? a = a + "-" + time.strftime("%Y%m%d") ??? return a uname -p redundant with $(TARGET), er..the other way around.. config.guess/uname maybe is the preferable way. I guess that's a bigger leap right now, and it isn't entirely true, e.g. on "biarch" systems, e.g. AMD64_{DARWIN,SOLARIS}, SPARC64_SOLARIS, PPC64_DARWIN, etc.. def GetVisualCPlusPlusVersion(): ??? a = os.popen("cl 2>&1 >nul").read().lower() ??? if a.find("9.00") != -1: ??????? return "20" ??? if a.find("10.00") != -1: ??????? return "40" ??? if a.find("10.10") != -1: ??????? return "41" ??? if a.find("10.20") != -1: ??????? return "42" ??? if a.find("11.00") != -1: ??????? return "50" ??? if a.find("12.00") != -1: ??????? return "60" ??? if a.find("13.00") != -1: ??????? return "70" ??? if a.find("13.10") != -1: ??????? return "71" ??? if a.find("14.00") != -1: ??????? return "80" ??? if a.find("15.00") != -1: ??????? return "90" ??? if a.find("16.00") != -1: ??????? return "100" ??? FatalError("unable to detect Visual C++ version, maybe cl is not in %PATH%?") but I'm just talking..need to try to work it in to your *.sh. ?- Jay ---------------------------------------- > Date: Sat, 7 Aug 2010 12:58:48 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 10/08/07 12:58:48 > > Modified files: > cm3/scripts/: make-bin-dist-min.sh make-dist.sh sysinfo.sh > cm3/scripts/regression/: update_snapshot_status.sh > > Log message: > fix snapshot support and add build_platform > From wagner at elegosoft.com Sat Aug 7 16:59:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 07 Aug 2010 16:59:43 +0200 Subject: [M3devel] build_platform in archive names In-Reply-To: References: <20100807105849.2B48724740EC@birch.elegosoft.com> Message-ID: <20100807165943.ygl506lqo80kokok@mail.elegosoft.com> I've left out Windows, because I wasn't sure what exactly was needed there. Feel free to add an appropriate string for all Windows-based target platforms! Olaf Quoting Jay K : > Thanks! > I want something slightly different for NT platforms. > NT doesn't have the binary incompatibility and cross-build problem > of Unix, at the OS level. > ? (and commercial Unix isn't so bad either I think these days) > However it does sort of have it at the C runtime level. > i.e. There is no need to say e.g. XP/Vista/Win7/NT5.1/6.0/6.1, but > there is a need to say e.g. msvc70/71/80/90/100. > And there probably is a need for Cygwin-1.5 vs. Cygwin-1.7 (ie. > exactly what you have). > > You can see in pylib.py: > > def FormInstallRoot(PackageSetName): > ??? AltConfig = {"NT386":"x86"}.get(Config, Config) > ??? a = os.path.join(GetStage(), "cm3-" + PackageSetName + "-" + > AltConfig + "-" + CM3VERSION) > ??? if Config == "NT386" or Config == "I386_NT": > ??????? a = a + "-VC" + GetVisualCPlusPlusVersion() > ??? else: > ??????? b = os.popen("uname -sr").read() > ??????? b = re.sub("Linux 2.4\..+$", "Linux2.4", b) > ??????? b = re.sub("Linux 2.6\..+$", "", b) > ??????? b = re.sub("-.+$", "", b) > ??????? b = re.sub("SunOS", "Solaris", b) > ??????? b = re.sub("[ \r\n]", "", b) > ??????? a = a + "-" + b > ??? a = a + "-" + time.strftime("%Y%m%d") > ??? return a > > > uname -p redundant with $(TARGET), er..the other way around.. > config.guess/uname maybe is the preferable way. > I guess that's a bigger leap right now, and it isn't entirely true, > e.g. on "biarch" systems, e.g. AMD64_{DARWIN,SOLARIS}, > SPARC64_SOLARIS, PPC64_DARWIN, etc.. > > > def GetVisualCPlusPlusVersion(): > ??? a = os.popen("cl 2>&1 >nul").read().lower() > ??? if a.find("9.00") != -1: > ??????? return "20" > ??? if a.find("10.00") != -1: > ??????? return "40" > ??? if a.find("10.10") != -1: > ??????? return "41" > ??? if a.find("10.20") != -1: > ??????? return "42" > ??? if a.find("11.00") != -1: > ??????? return "50" > ??? if a.find("12.00") != -1: > ??????? return "60" > ??? if a.find("13.00") != -1: > ??????? return "70" > ??? if a.find("13.10") != -1: > ??????? return "71" > ??? if a.find("14.00") != -1: > ??????? return "80" > ??? if a.find("15.00") != -1: > ??????? return "90" > ??? if a.find("16.00") != -1: > ??????? return "100" > ??? FatalError("unable to detect Visual C++ version, maybe cl is not > in %PATH%?") > > > but I'm just talking..need to try to work it in to your *.sh. > > > ?- Jay > > ---------------------------------------- >> Date: Sat, 7 Aug 2010 12:58:48 +0000 >> To: m3commit at elegosoft.com >> From: wagner at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: wagner at birch. 10/08/07 12:58:48 >> >> Modified files: >> cm3/scripts/: make-bin-dist-min.sh make-dist.sh sysinfo.sh >> cm3/scripts/regression/: update_snapshot_status.sh >> >> Log message: >> fix snapshot support and add build_platform >> > -- 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 Sat Aug 7 21:51:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 19:51:26 +0000 Subject: [M3devel] elego compact In-Reply-To: <20100807161924.5CA4924740DC@birch.elegosoft.com> References: <20100807161924.5CA4924740DC@birch.elegosoft.com> Message-ID: Cool. Notice the derived files (directory AMD64_FREEBSD) got imported. - Jay ---------------------------------------- > Date: Sat, 7 Aug 2010 18:19:23 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 10/08/07 18:19:23 > > cm3/elego > > Update of /usr/cvs/cm3/elego > In directory birch:/tmp/cvs-serv13035 > > Log Message: > Stripped-down version of Elego ComPact; software developed and used > at Elego years ago. I put it under the same copyright as the other > Modula-3 sources from DEC and Critical Mass. > > Included is package version management based on CVS and build and > version management for sets of packages, called `project management' > in ComPact. > > Not included is the general package manager for C/C++/Java/M3, and the > ComPact GUI. > > It is contributed in the hope that it may be useful in whole or parts > for the CM3 project or any other users. > > The command line interface consists of the programs pkgvm and prjm, > which include complete manuals as well as short usage help: > > pkgvm -help | -man > prjm -help | -man > > The sources have been successfully compiled with a current cm3 (d5.9.0) > by prjm with > > prjm -D ROOT=$HOME/work/cm3 -buildglobal > > The project definition is contained in the file elego/PrjDesc. > > To compile everything with the CM3 srcipts, use > > ~/work/cm3/scripts/do-pkg.sh buildship langutils graphicutils tuple depgraph miniscan fsfind fileinfo filepool pkgversions compact-copyright rsrcservice compact-client compactrc pkg_base pkg_vc m3makefile m3dep m3dir m3err m3msh m3ovr pkgvm prjbase prjm > > Several things may still be wrong and need to be adapted for use with > the current CM3, but the ComPact tools should be quite flexible and > configurable. > > As all free software, this comes without any guarantee that it will > be useful in any way. Use at your own risk. > > Olaf Wagner / Elego Software Solutions GmbH, Berlin, Germany, 2010-08-07 > > > Status: > > Vendor Tag: elego-compact-free-1-0 > Release Tags: rel-compact-free-1-0 > > N cm3/elego/DepGraph > N cm3/elego/quake.elego > N cm3/elego/PrjDesc > N cm3/elego/srcs > N cm3/elego/compact-copyright/PkgTags > N cm3/elego/compact-copyright/PkgErr > N cm3/elego/compact-copyright/src/Copyright.m3 > N cm3/elego/compact-copyright/src/Release.m3 > N cm3/elego/compact-copyright/src/m3overrides > N cm3/elego/compact-copyright/src/ProgramVersion.i3 > N cm3/elego/compact-copyright/src/Version.i3 > N cm3/elego/compact-copyright/src/Release.i3 > N cm3/elego/compact-copyright/src/compact-copyrights.txt > N cm3/elego/compact-copyright/src/m3makefile > N cm3/elego/compact-copyright/src/Copyright.i3 > N cm3/elego/compact-copyright/src/ProgramVersion.m3 > N cm3/elego/compact-copyright/src/get-licences > N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.io > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.io > N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.so.5 > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.i3 > N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.io > N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3SHIP > N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.mo > N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.m3x > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.m3 > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.mo > N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3WEB > N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.mo > N cm3/elego/filepool/PkgTags > N cm3/elego/filepool/PkgErr > N cm3/elego/filepool/src/m3overrides > N cm3/elego/filepool/src/FilePool.m3 > N cm3/elego/filepool/src/m3makefile > N cm3/elego/filepool/src/FilePool.i3 > N cm3/elego/filepool/test/src/Main.m3 > N cm3/elego/filepool/test/src/m3makefile > N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.so.5 > N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.m3x > N cm3/elego/filepool/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/filepool/AMD64_FREEBSD/.M3SHIP > N cm3/elego/filepool/AMD64_FREEBSD/FilePool.io > N cm3/elego/filepool/AMD64_FREEBSD/.M3WEB > N cm3/elego/filepool/AMD64_FREEBSD/FilePool.mo > N cm3/elego/m3err/PkgTags > N cm3/elego/m3err/m3err.gmon > N cm3/elego/m3err/PkgErr > N cm3/elego/m3err/src/m3overrides > N cm3/elego/m3err/src/m3err.m3 > N cm3/elego/m3err/src/m3makefile > N cm3/elego/m3err/AMD64_FREEBSD/m3err > N cm3/elego/m3err/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3err/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3err/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3err/AMD64_FREEBSD/m3err.mo > N cm3/elego/m3err/AMD64_FREEBSD/m3err.mx > N cm3/elego/m3err/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3err/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3err/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3err/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3err/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3err/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3err/AMD64_FREEBSD/Creation.io > N cm3/elego/prjbase/PkgTags > N cm3/elego/prjbase/PkgErr > N cm3/elego/prjbase/snaps/snaps.idx > N cm3/elego/prjbase/src/PrjDesc.i3 > N cm3/elego/prjbase/src/ChangeSet.i3 > N cm3/elego/prjbase/src/Checkpoint.i3 > N cm3/elego/prjbase/src/PrjDesc.m3 > N cm3/elego/prjbase/src/Snapshots.i3 > N cm3/elego/prjbase/src/Snapshots.m3 > N cm3/elego/prjbase/src/ChangeSet.m3 > N cm3/elego/prjbase/src/m3overrides > N cm3/elego/prjbase/src/RCS_Date.i3 > N cm3/elego/prjbase/src/PoolSet.i3 > N cm3/elego/prjbase/src/RCS_Date.m3 > N cm3/elego/prjbase/src/PoolSet.m3 > N cm3/elego/prjbase/src/Checkpoint.m3 > N cm3/elego/prjbase/src/rcsdate.patch > N cm3/elego/prjbase/src/m3makefile > N cm3/elego/prjbase/src/m3browser.html > N cm3/elego/prjbase/test/src/PrjDesc1 > N cm3/elego/prjbase/test/src/PrjDesc2 > N cm3/elego/prjbase/test/src/Main.m3 > N cm3/elego/prjbase/test/src/m3makefile > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.io > N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.mo > N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.io > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.m3x > N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.io > N cm3/elego/prjbase/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/.M3SHIP > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.so.5 > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.io > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/.M3WEB > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.io > N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.i3 > N cm3/elego/tuple/PkgTags > N cm3/elego/tuple/PkgErr > N cm3/elego/tuple/src/TextTuple.m3 > N cm3/elego/tuple/src/TextTuple.i3 > N cm3/elego/tuple/src/Dummy.i3 > N cm3/elego/tuple/src/m3overrides > N cm3/elego/tuple/src/Tuple.mg > N cm3/elego/tuple/src/Tuple.ig > N cm3/elego/tuple/src/m3makefile > N cm3/elego/tuple/src/Dummy.m3 > N cm3/elego/tuple/src/HeteroTuple.mg > N cm3/elego/tuple/src/HeteroTuple.ig > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.i3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.io > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.io > N cm3/elego/tuple/AMD64_FREEBSD/libtuple.so.5 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.i3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.io > N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.mo > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.mo > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.i3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.mo > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.io > N cm3/elego/tuple/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/tuple/AMD64_FREEBSD/.M3SHIP > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.io > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.m3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.m3 > N cm3/elego/tuple/AMD64_FREEBSD/.M3WEB > N cm3/elego/tuple/AMD64_FREEBSD/libtuple.m3x > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.i3 > N cm3/elego/langutils/PkgTags > N cm3/elego/langutils/PkgErr > N cm3/elego/langutils/src/m3overrides > N cm3/elego/langutils/src/SimpleValueEnv.m3 > N cm3/elego/langutils/src/SimpleValueEnv.i3 > N cm3/elego/langutils/src/m3makefile > N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.m3x > N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.mo > N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.so.5 > N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.io > N cm3/elego/langutils/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/langutils/AMD64_FREEBSD/.M3SHIP > N cm3/elego/langutils/AMD64_FREEBSD/.M3WEB > N cm3/elego/prjm/PkgTags > N cm3/elego/prjm/PrjDesc > N cm3/elego/prjm/stat > N cm3/elego/prjm/PkgErr > N cm3/elego/prjm/src/m3overrides > N cm3/elego/prjm/src/Copyright > N cm3/elego/prjm/src/PrjmGUI.fv > N cm3/elego/prjm/src/m3makefile > N cm3/elego/prjm/src/ProjectManager.m3 > N cm3/elego/prjm/src/ShortUsageHelp > N cm3/elego/prjm/src/UsageHelp > N cm3/elego/prjm/src/compactrc > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.io > N cm3/elego/prjm/AMD64_FREEBSD/prjm.mx > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.i3 > N cm3/elego/prjm/AMD64_FREEBSD/_m3main.mc > N cm3/elego/prjm/AMD64_FREEBSD/Creation.i3 > N cm3/elego/prjm/AMD64_FREEBSD/prjm > N cm3/elego/prjm/AMD64_FREEBSD/Creation.m3 > N cm3/elego/prjm/AMD64_FREEBSD/Creation.mo > N cm3/elego/prjm/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/prjm/AMD64_FREEBSD/.M3SHIP > N cm3/elego/prjm/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManager.mo > N cm3/elego/prjm/AMD64_FREEBSD/.M3WEB > N cm3/elego/prjm/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.mo > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.m3 > N cm3/elego/prjm/AMD64_FREEBSD/Creation.io > N cm3/elego/pkg_vc/PkgTags > N cm3/elego/pkg_vc/TODO > N cm3/elego/pkg_vc/PkgDesc > N cm3/elego/pkg_vc/PkgErr > N cm3/elego/pkg_vc/src/PkgVC.i3 > N cm3/elego/pkg_vc/src/CVS.i3 > N cm3/elego/pkg_vc/src/FileRevision.i3 > N cm3/elego/pkg_vc/src/m3overrides > N cm3/elego/pkg_vc/src/FileObj.i3 > N cm3/elego/pkg_vc/src/ProcessPosixOS2.m3 > N cm3/elego/pkg_vc/src/PkgVCUtils.m3 > N cm3/elego/pkg_vc/src/VCIF.i3 > N cm3/elego/pkg_vc/src/OpResultCache.m3 > N cm3/elego/pkg_vc/src/VCUtils.i3 > N cm3/elego/pkg_vc/src/gnats-commit-check.sh > N cm3/elego/pkg_vc/src/Process2.i3 > N cm3/elego/pkg_vc/src/PkgVCUtils.i3 > N cm3/elego/pkg_vc/src/m3makefile > N cm3/elego/pkg_vc/src/FileObj.m3 > N cm3/elego/pkg_vc/src/PkgVC.m3 > N cm3/elego/pkg_vc/src/VCUtils.m3 > N cm3/elego/pkg_vc/src/CVS_st.m3 > N cm3/elego/pkg_vc/src/CVSLockInfo.i3 > N cm3/elego/pkg_vc/src/OpResultCache.i3 > N cm3/elego/pkg_vc/tests/src/m3overrides > N cm3/elego/pkg_vc/tests/src/Main.m3 > N cm3/elego/pkg_vc/tests/src/m3makefile > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.m3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/VCIF.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.m3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS_st.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.so.5 > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfo.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.m3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.m3x > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevision.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS.io > N cm3/elego/m3ovr/PkgTags > N cm3/elego/m3ovr/PkgErr > N cm3/elego/m3ovr/src/m3overrides > N cm3/elego/m3ovr/src/Main.m3 > N cm3/elego/m3ovr/src/m3makefile > N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr.mx > N cm3/elego/m3ovr/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3ovr/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3ovr/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3ovr/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.io > N cm3/elego/m3ovr/AMD64_FREEBSD/Main.mo > N cm3/elego/compact-client/PkgTags > N cm3/elego/compact-client/PkgErr > N cm3/elego/compact-client/src/m3overrides > N cm3/elego/compact-client/src/CompactClient.m3 > N cm3/elego/compact-client/src/m3makefile > N cm3/elego/compact-client/src/CompactClient.i3 > N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.so.5 > N cm3/elego/compact-client/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/compact-client/AMD64_FREEBSD/.M3SHIP > N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.mo > N cm3/elego/compact-client/AMD64_FREEBSD/.M3WEB > N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.m3x > N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.io > N cm3/elego/fileinfo/PkgTags > N cm3/elego/fileinfo/PkgErr > N cm3/elego/fileinfo/src/FileDir.m3 > N cm3/elego/fileinfo/src/FileStatus.i3 > N cm3/elego/fileinfo/src/DirTree.m3 > N cm3/elego/fileinfo/src/Dummy.i3 > N cm3/elego/fileinfo/src/FileStamp.i3 > N cm3/elego/fileinfo/src/m3overrides > N cm3/elego/fileinfo/src/DirTree.i3 > N cm3/elego/fileinfo/src/APN.i3 > N cm3/elego/fileinfo/src/FileDir.i3 > N cm3/elego/fileinfo/src/FileInfo.i3 > N cm3/elego/fileinfo/src/PathnameStatusTable.i3 > N cm3/elego/fileinfo/src/FileStatus.m3 > N cm3/elego/fileinfo/src/m3makefile > N cm3/elego/fileinfo/src/Dummy.m3 > N cm3/elego/fileinfo/src/FileSystem.m3 > N cm3/elego/fileinfo/src/FileSystem.i3 > N cm3/elego/fileinfo/src/PathnameStatusTable.m3 > N cm3/elego/fileinfo/src/FileInfo.m3 > N cm3/elego/fileinfo/src/APN.m3 > N cm3/elego/fileinfo/src/TreeStamp.i3 > N cm3/elego/fileinfo/src/FileStamp.m3 > N cm3/elego/fileinfo/tests/PkgTags > N cm3/elego/fileinfo/tests/src/m3overrides > N cm3/elego/fileinfo/tests/src/Main.m3 > N cm3/elego/fileinfo/tests/src/m3makefile > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.io > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.m3x > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.so.5 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APN.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.io > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/.M3SHIP > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APN.io > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/.M3WEB > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.io > N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.io > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.io > N cm3/elego/pkgvm/PkgTags > N cm3/elego/pkgvm/PkgErr > N cm3/elego/pkgvm/src/m3overrides > N cm3/elego/pkgvm/src/Main.m3 > N cm3/elego/pkgvm/src/pkgvm.desc > N cm3/elego/pkgvm/src/m3makefile > N cm3/elego/pkgvm/src/pkgvm.help > N cm3/elego/pkgvm/src/compactrc > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.i3 > N cm3/elego/pkgvm/AMD64_FREEBSD/_m3main.mc > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.i3 > N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm.mx > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.m3 > N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.io > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.m3 > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.mo > N cm3/elego/pkgvm/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkgvm/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/pkgvm/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.io > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.mo > N cm3/elego/pkgvm/AMD64_FREEBSD/Main.mo > N cm3/elego/graphicutils/PkgTags > N cm3/elego/graphicutils/PkgErr > N cm3/elego/graphicutils/src/RsrcUtils.i3 > N cm3/elego/graphicutils/src/m3overrides > N cm3/elego/graphicutils/src/RsrcUtils.m3 > N cm3/elego/graphicutils/src/RsrcFilter.m3 > N cm3/elego/graphicutils/src/StdFontsX.m3 > N cm3/elego/graphicutils/src/StdFonts.m3 > N cm3/elego/graphicutils/src/m3makefile > N cm3/elego/graphicutils/src/RsrcFilter.i3 > N cm3/elego/graphicutils/src/StdFontsWin32.m3 > N cm3/elego/graphicutils/src/StdFonts.i3 > N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.m3x > N cm3/elego/graphicutils/AMD64_FREEBSD/StdFonts.io > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.mo > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.mo > N cm3/elego/graphicutils/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/graphicutils/AMD64_FREEBSD/StdFontsX.mo > N cm3/elego/graphicutils/AMD64_FREEBSD/.M3SHIP > N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.so.5 > N cm3/elego/graphicutils/AMD64_FREEBSD/.M3WEB > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.io > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.io > N cm3/elego/m3dep/PkgTags > N cm3/elego/m3dep/PkgErr > N cm3/elego/m3dep/src/m3overrides > N cm3/elego/m3dep/src/Main.m3 > N cm3/elego/m3dep/src/m3makefile > N cm3/elego/m3dep/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3dep/AMD64_FREEBSD/m3dep > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3dep/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3dep/AMD64_FREEBSD/m3dep.mx > N cm3/elego/m3dep/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3dep/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.io > N cm3/elego/m3dep/AMD64_FREEBSD/Main.mo > N cm3/elego/pkgversions/PkgTags > N cm3/elego/pkgversions/PkgErr > N cm3/elego/pkgversions/src/TagSort.m3 > N cm3/elego/pkgversions/src/Version.m3 > N cm3/elego/pkgversions/src/m3overrides > N cm3/elego/pkgversions/src/TagSort.i3 > N cm3/elego/pkgversions/src/Version.i3 > N cm3/elego/pkgversions/src/m3makefile > N cm3/elego/pkgversions/src/Tag.m3 > N cm3/elego/pkgversions/src/Tag.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/Version.io > N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.m3 > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.io > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.m3x > N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.so.5 > N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.io > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.io > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.io > N cm3/elego/pkgversions/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkgversions/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.io > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.io > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.m3 > N cm3/elego/pkgversions/AMD64_FREEBSD/Version.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.i3 > N cm3/elego/m3makefile/PkgTags > N cm3/elego/m3makefile/PkgErr > N cm3/elego/m3makefile/src/m3overrides > N cm3/elego/m3makefile/src/QCompiler.i3 > N cm3/elego/m3makefile/src/QCompiler.m3 > N cm3/elego/m3makefile/src/m3makefile > N cm3/elego/m3makefile/src/M3makefile.m3 > N cm3/elego/m3makefile/src/M3makefile.i3 > N cm3/elego/m3makefile/test/src/Main.m3 > N cm3/elego/m3makefile/test/src/m3makefile > N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.m3x > N cm3/elego/m3makefile/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.mo > N cm3/elego/m3makefile/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.so.5 > N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.io > N cm3/elego/m3makefile/AMD64_FREEBSD/.M3WEB > N cm3/elego/rsrcservice/PkgTags > N cm3/elego/rsrcservice/PkgErr > N cm3/elego/rsrcservice/src/RsrcService.i3 > N cm3/elego/rsrcservice/src/m3overrides > N cm3/elego/rsrcservice/src/m3makefile > N cm3/elego/rsrcservice/src/ConfigRsrcService.m3 > N cm3/elego/rsrcservice/src/ConfigRsrcService.i3 > N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.mo > N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.so.5 > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.mo > N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.io > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.io > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3IMPTAB > N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.m3x > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3SHIP > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService.io > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3WEB > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.m3 > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.i3 > N cm3/elego/pkg_base/PkgTags > N cm3/elego/pkg_base/TODO > N cm3/elego/pkg_base/PkgDesc > N cm3/elego/pkg_base/PkgErr > N cm3/elego/pkg_base/src/m3overrides > N cm3/elego/pkg_base/src/PkgKindData.i3 > N cm3/elego/pkg_base/src/PkgBase.DefaultData > N cm3/elego/pkg_base/src/PkgBase.i3 > N cm3/elego/pkg_base/src/m3makefile > N cm3/elego/pkg_base/src/PkgKindData.m3 > N cm3/elego/pkg_base/src/PkgBase.m3 > N cm3/elego/pkg_base/src/PkgError.i3 > N cm3/elego/pkg_base/test0/src/Main.m3 > N cm3/elego/pkg_base/test0/src/kinds > N cm3/elego/pkg_base/test0/src/m3makefile > N cm3/elego/pkg_base/test0/src/dummy/bla > N cm3/elego/pkg_base/test0/src/dummy/dummy-a/hugo > N cm3/elego/pkg_base/test0/src/dummy/dummy-a/susi > N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.m3x > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.i3 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.i3 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgError.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.m3 > N cm3/elego/pkg_base/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkg_base/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.m3 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.so.5 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.io > N cm3/elego/fsfind/PkgTags > N cm3/elego/fsfind/PkgErr > N cm3/elego/fsfind/src/FSFind.i3 > N cm3/elego/fsfind/src/m3overrides > N cm3/elego/fsfind/src/FileClassification.m3 > N cm3/elego/fsfind/src/FindExecRec.m3 > N cm3/elego/fsfind/src/FindExpr.i3 > N cm3/elego/fsfind/src/FSFind.m3 > N cm3/elego/fsfind/src/FindExecRec.i3 > N cm3/elego/fsfind/src/FileClassification.i3 > N cm3/elego/fsfind/src/FindExpr.m3 > N cm3/elego/fsfind/src/FSFindError.i3 > N cm3/elego/fsfind/src/m3makefile > N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.m3 > N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FSFindError.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.i3 > N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.m3x > N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.io > N cm3/elego/fsfind/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/fsfind/AMD64_FREEBSD/.M3SHIP > N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.io > N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.so.5 > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.mo > N cm3/elego/fsfind/AMD64_FREEBSD/.M3WEB > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.i3 > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.io > N cm3/elego/m3msh/PkgTags > N cm3/elego/m3msh/PkgErr > N cm3/elego/m3msh/src/m3overrides > N cm3/elego/m3msh/src/m3msh.desc > N cm3/elego/m3msh/src/m3makefile > N cm3/elego/m3msh/src/m3msh.help > N cm3/elego/m3msh/src/M3MiniShell.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.mo > N cm3/elego/m3msh/AMD64_FREEBSD/m3msh.mx > N cm3/elego/m3msh/AMD64_FREEBSD/M3MiniShell.mo > N cm3/elego/m3msh/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.io > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3msh/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3msh/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/m3msh > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.i3 > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.io > N cm3/elego/m3dir/PkgTags > N cm3/elego/m3dir/PkgErr > N cm3/elego/m3dir/src/m3overrides > N cm3/elego/m3dir/src/M3Dir.m3 > N cm3/elego/m3dir/src/m3makefile > N cm3/elego/m3dir/AMD64_FREEBSD/m3dir.mx > N cm3/elego/m3dir/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3dir/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3dir/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3dir/AMD64_FREEBSD/M3Dir.mo > N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3dir/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.io > N cm3/elego/m3dir/AMD64_FREEBSD/m3dir > N cm3/elego/miniscan/PkgTags > N cm3/elego/miniscan/PkgErr > N cm3/elego/miniscan/src/m3overrides > N cm3/elego/miniscan/src/ScanToken.i3 > N cm3/elego/miniscan/src/m3makefile > N cm3/elego/miniscan/src/SimpleScanner.i3 > N cm3/elego/miniscan/src/SimpleScanner.m3 > N cm3/elego/miniscan/src/ScanToken.m3 > N cm3/elego/miniscan/test/src/m3overrides > N cm3/elego/miniscan/test/src/Main.m3 > N cm3/elego/miniscan/test/src/m3makefile > N cm3/elego/miniscan/test/src/otto > N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.io > N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.mo > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.io > N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.mo > N cm3/elego/miniscan/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/miniscan/AMD64_FREEBSD/.M3SHIP > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.i3 > N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.io > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.io > N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.so.5 > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.i3 > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.m3 > N cm3/elego/miniscan/AMD64_FREEBSD/.M3WEB > N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.m3x > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.mo > N cm3/elego/compactrc/PkgTags > N cm3/elego/compactrc/PkgErr > N cm3/elego/compactrc/src/m3overrides > N cm3/elego/compactrc/src/CompactRC.m3 > N cm3/elego/compactrc/src/CompactRC.i3 > N cm3/elego/compactrc/src/compactrc.README > N cm3/elego/compactrc/src/MiniEnv.i3 > N cm3/elego/compactrc/src/compactrc.default > N cm3/elego/compactrc/src/m3makefile > N cm3/elego/compactrc/src/CompactEnvName.i3 > N cm3/elego/compactrc/src/MiniEnv.m3 > N cm3/elego/compactrc/src/compactrc.cd > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.mo > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.io > N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.io > N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.io > N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.so.5 > N cm3/elego/compactrc/AMD64_FREEBSD/CompactEnvName.io > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.m3 > N cm3/elego/compactrc/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/compactrc/AMD64_FREEBSD/.M3SHIP > N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.m3x > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.i3 > N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.mo > N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.mo > N cm3/elego/compactrc/AMD64_FREEBSD/.M3WEB > N cm3/elego/depgraph/PkgTags > N cm3/elego/depgraph/PkgErr > N cm3/elego/depgraph/src/StdDepGraph.m3 > N cm3/elego/depgraph/src/DependencyGraph.i3 > N cm3/elego/depgraph/src/StdDepGraphNode.m3 > N cm3/elego/depgraph/src/m3overrides > N cm3/elego/depgraph/src/StdDepGraph.i3 > N cm3/elego/depgraph/src/StdDepGraphEdge.i3 > N cm3/elego/depgraph/src/DependencyGraph.m3 > N cm3/elego/depgraph/src/m3makefile > N cm3/elego/depgraph/src/StdDepGraphNode.i3 > N cm3/elego/depgraph/src/StdDepGraphEdge.m3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.mo > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.mo > N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.m3x > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.m3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.mo > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.m3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.i3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.io > N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.so.5 > N cm3/elego/depgraph/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/depgraph/AMD64_FREEBSD/.M3SHIP > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.mo > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.i3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.io > N cm3/elego/depgraph/AMD64_FREEBSD/.M3WEB > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.mo > N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.mo > N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.i3 > > No conflicts created by this import > From wagner at elegosoft.com Sat Aug 7 22:16:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 07 Aug 2010 22:16:39 +0200 Subject: [M3devel] elego compact In-Reply-To: References: <20100807161924.5CA4924740DC@birch.elegosoft.com> Message-ID: <20100807221639.cfa70r5ttwgos040@mail.elegosoft.com> Quoting Jay K : > Cool. Notice the derived files (directory AMD64_FREEBSD) got imported. Yes. But I immediately removed them again on birch. Stupid pilot error :-/ Actually this project was lying around here for about two years now... I thought today would be a good day to finish it :-) It took me most of the day to make everything compile again (several LONGINT changes, M3Config gone etc.). Olaf > - Jay > > ---------------------------------------- >> Date: Sat, 7 Aug 2010 18:19:23 +0000 >> To: m3commit at elegosoft.com >> From: wagner at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: wagner at birch. 10/08/07 18:19:23 >> >> cm3/elego >> >> Update of /usr/cvs/cm3/elego >> In directory birch:/tmp/cvs-serv13035 >> >> Log Message: >> Stripped-down version of Elego ComPact; software developed and used >> at Elego years ago. I put it under the same copyright as the other >> Modula-3 sources from DEC and Critical Mass. >> >> Included is package version management based on CVS and build and >> version management for sets of packages, called `project management' >> in ComPact. >> >> Not included is the general package manager for C/C++/Java/M3, and the >> ComPact GUI. >> >> It is contributed in the hope that it may be useful in whole or parts >> for the CM3 project or any other users. >> >> The command line interface consists of the programs pkgvm and prjm, >> which include complete manuals as well as short usage help: >> >> pkgvm -help | -man >> prjm -help | -man >> >> The sources have been successfully compiled with a current cm3 (d5.9.0) >> by prjm with >> >> prjm -D ROOT=$HOME/work/cm3 -buildglobal >> >> The project definition is contained in the file elego/PrjDesc. >> >> To compile everything with the CM3 srcipts, use >> >> ~/work/cm3/scripts/do-pkg.sh buildship langutils graphicutils tuple >> depgraph miniscan fsfind fileinfo filepool pkgversions >> compact-copyright rsrcservice compact-client compactrc pkg_base >> pkg_vc m3makefile m3dep m3dir m3err m3msh m3ovr pkgvm prjbase prjm >> >> Several things may still be wrong and need to be adapted for use with >> the current CM3, but the ComPact tools should be quite flexible and >> configurable. >> >> As all free software, this comes without any guarantee that it will >> be useful in any way. Use at your own risk. >> >> Olaf Wagner / Elego Software Solutions GmbH, Berlin, Germany, 2010-08-07 >> >> >> Status: >> >> Vendor Tag: elego-compact-free-1-0 >> Release Tags: rel-compact-free-1-0 >> >> N cm3/elego/DepGraph >> N cm3/elego/quake.elego >> N cm3/elego/PrjDesc >> N cm3/elego/srcs >> N cm3/elego/compact-copyright/PkgTags >> N cm3/elego/compact-copyright/PkgErr >> N cm3/elego/compact-copyright/src/Copyright.m3 >> N cm3/elego/compact-copyright/src/Release.m3 >> N cm3/elego/compact-copyright/src/m3overrides >> N cm3/elego/compact-copyright/src/ProgramVersion.i3 >> N cm3/elego/compact-copyright/src/Version.i3 >> N cm3/elego/compact-copyright/src/Release.i3 >> N cm3/elego/compact-copyright/src/compact-copyrights.txt >> N cm3/elego/compact-copyright/src/m3makefile >> N cm3/elego/compact-copyright/src/Copyright.i3 >> N cm3/elego/compact-copyright/src/ProgramVersion.m3 >> N cm3/elego/compact-copyright/src/get-licences >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.io >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.io >> N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.so.5 >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.i3 >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.io >> N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.mo >> N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.m3x >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.m3 >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.mo >> N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3WEB >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.mo >> N cm3/elego/filepool/PkgTags >> N cm3/elego/filepool/PkgErr >> N cm3/elego/filepool/src/m3overrides >> N cm3/elego/filepool/src/FilePool.m3 >> N cm3/elego/filepool/src/m3makefile >> N cm3/elego/filepool/src/FilePool.i3 >> N cm3/elego/filepool/test/src/Main.m3 >> N cm3/elego/filepool/test/src/m3makefile >> N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.so.5 >> N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.m3x >> N cm3/elego/filepool/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/filepool/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/filepool/AMD64_FREEBSD/FilePool.io >> N cm3/elego/filepool/AMD64_FREEBSD/.M3WEB >> N cm3/elego/filepool/AMD64_FREEBSD/FilePool.mo >> N cm3/elego/m3err/PkgTags >> N cm3/elego/m3err/m3err.gmon >> N cm3/elego/m3err/PkgErr >> N cm3/elego/m3err/src/m3overrides >> N cm3/elego/m3err/src/m3err.m3 >> N cm3/elego/m3err/src/m3makefile >> N cm3/elego/m3err/AMD64_FREEBSD/m3err >> N cm3/elego/m3err/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3err/AMD64_FREEBSD/m3err.mo >> N cm3/elego/m3err/AMD64_FREEBSD/m3err.mx >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3err/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3err/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3err/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3err/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3err/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.io >> N cm3/elego/prjbase/PkgTags >> N cm3/elego/prjbase/PkgErr >> N cm3/elego/prjbase/snaps/snaps.idx >> N cm3/elego/prjbase/src/PrjDesc.i3 >> N cm3/elego/prjbase/src/ChangeSet.i3 >> N cm3/elego/prjbase/src/Checkpoint.i3 >> N cm3/elego/prjbase/src/PrjDesc.m3 >> N cm3/elego/prjbase/src/Snapshots.i3 >> N cm3/elego/prjbase/src/Snapshots.m3 >> N cm3/elego/prjbase/src/ChangeSet.m3 >> N cm3/elego/prjbase/src/m3overrides >> N cm3/elego/prjbase/src/RCS_Date.i3 >> N cm3/elego/prjbase/src/PoolSet.i3 >> N cm3/elego/prjbase/src/RCS_Date.m3 >> N cm3/elego/prjbase/src/PoolSet.m3 >> N cm3/elego/prjbase/src/Checkpoint.m3 >> N cm3/elego/prjbase/src/rcsdate.patch >> N cm3/elego/prjbase/src/m3makefile >> N cm3/elego/prjbase/src/m3browser.html >> N cm3/elego/prjbase/test/src/PrjDesc1 >> N cm3/elego/prjbase/test/src/PrjDesc2 >> N cm3/elego/prjbase/test/src/Main.m3 >> N cm3/elego/prjbase/test/src/m3makefile >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.io >> N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.io >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.m3x >> N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.io >> N cm3/elego/prjbase/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.so.5 >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/.M3WEB >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.io >> N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.i3 >> N cm3/elego/tuple/PkgTags >> N cm3/elego/tuple/PkgErr >> N cm3/elego/tuple/src/TextTuple.m3 >> N cm3/elego/tuple/src/TextTuple.i3 >> N cm3/elego/tuple/src/Dummy.i3 >> N cm3/elego/tuple/src/m3overrides >> N cm3/elego/tuple/src/Tuple.mg >> N cm3/elego/tuple/src/Tuple.ig >> N cm3/elego/tuple/src/m3makefile >> N cm3/elego/tuple/src/Dummy.m3 >> N cm3/elego/tuple/src/HeteroTuple.mg >> N cm3/elego/tuple/src/HeteroTuple.ig >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.i3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.io >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.io >> N cm3/elego/tuple/AMD64_FREEBSD/libtuple.so.5 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.i3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.io >> N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.mo >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.mo >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.i3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.mo >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.io >> N cm3/elego/tuple/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/tuple/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.io >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.m3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.m3 >> N cm3/elego/tuple/AMD64_FREEBSD/.M3WEB >> N cm3/elego/tuple/AMD64_FREEBSD/libtuple.m3x >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.i3 >> N cm3/elego/langutils/PkgTags >> N cm3/elego/langutils/PkgErr >> N cm3/elego/langutils/src/m3overrides >> N cm3/elego/langutils/src/SimpleValueEnv.m3 >> N cm3/elego/langutils/src/SimpleValueEnv.i3 >> N cm3/elego/langutils/src/m3makefile >> N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.m3x >> N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.mo >> N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.so.5 >> N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.io >> N cm3/elego/langutils/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/langutils/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/langutils/AMD64_FREEBSD/.M3WEB >> N cm3/elego/prjm/PkgTags >> N cm3/elego/prjm/PrjDesc >> N cm3/elego/prjm/stat >> N cm3/elego/prjm/PkgErr >> N cm3/elego/prjm/src/m3overrides >> N cm3/elego/prjm/src/Copyright >> N cm3/elego/prjm/src/PrjmGUI.fv >> N cm3/elego/prjm/src/m3makefile >> N cm3/elego/prjm/src/ProjectManager.m3 >> N cm3/elego/prjm/src/ShortUsageHelp >> N cm3/elego/prjm/src/UsageHelp >> N cm3/elego/prjm/src/compactrc >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.io >> N cm3/elego/prjm/AMD64_FREEBSD/prjm.mx >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.i3 >> N cm3/elego/prjm/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/prjm/AMD64_FREEBSD/prjm >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.mo >> N cm3/elego/prjm/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/prjm/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/prjm/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManager.mo >> N cm3/elego/prjm/AMD64_FREEBSD/.M3WEB >> N cm3/elego/prjm/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.mo >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.m3 >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.io >> N cm3/elego/pkg_vc/PkgTags >> N cm3/elego/pkg_vc/TODO >> N cm3/elego/pkg_vc/PkgDesc >> N cm3/elego/pkg_vc/PkgErr >> N cm3/elego/pkg_vc/src/PkgVC.i3 >> N cm3/elego/pkg_vc/src/CVS.i3 >> N cm3/elego/pkg_vc/src/FileRevision.i3 >> N cm3/elego/pkg_vc/src/m3overrides >> N cm3/elego/pkg_vc/src/FileObj.i3 >> N cm3/elego/pkg_vc/src/ProcessPosixOS2.m3 >> N cm3/elego/pkg_vc/src/PkgVCUtils.m3 >> N cm3/elego/pkg_vc/src/VCIF.i3 >> N cm3/elego/pkg_vc/src/OpResultCache.m3 >> N cm3/elego/pkg_vc/src/VCUtils.i3 >> N cm3/elego/pkg_vc/src/gnats-commit-check.sh >> N cm3/elego/pkg_vc/src/Process2.i3 >> N cm3/elego/pkg_vc/src/PkgVCUtils.i3 >> N cm3/elego/pkg_vc/src/m3makefile >> N cm3/elego/pkg_vc/src/FileObj.m3 >> N cm3/elego/pkg_vc/src/PkgVC.m3 >> N cm3/elego/pkg_vc/src/VCUtils.m3 >> N cm3/elego/pkg_vc/src/CVS_st.m3 >> N cm3/elego/pkg_vc/src/CVSLockInfo.i3 >> N cm3/elego/pkg_vc/src/OpResultCache.i3 >> N cm3/elego/pkg_vc/tests/src/m3overrides >> N cm3/elego/pkg_vc/tests/src/Main.m3 >> N cm3/elego/pkg_vc/tests/src/m3makefile >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.m3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/VCIF.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.m3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS_st.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.so.5 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfo.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.m3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.m3x >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevision.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS.io >> N cm3/elego/m3ovr/PkgTags >> N cm3/elego/m3ovr/PkgErr >> N cm3/elego/m3ovr/src/m3overrides >> N cm3/elego/m3ovr/src/Main.m3 >> N cm3/elego/m3ovr/src/m3makefile >> N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr.mx >> N cm3/elego/m3ovr/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3ovr/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3ovr/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3ovr/AMD64_FREEBSD/Main.mo >> N cm3/elego/compact-client/PkgTags >> N cm3/elego/compact-client/PkgErr >> N cm3/elego/compact-client/src/m3overrides >> N cm3/elego/compact-client/src/CompactClient.m3 >> N cm3/elego/compact-client/src/m3makefile >> N cm3/elego/compact-client/src/CompactClient.i3 >> N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.so.5 >> N cm3/elego/compact-client/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/compact-client/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.mo >> N cm3/elego/compact-client/AMD64_FREEBSD/.M3WEB >> N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.m3x >> N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.io >> N cm3/elego/fileinfo/PkgTags >> N cm3/elego/fileinfo/PkgErr >> N cm3/elego/fileinfo/src/FileDir.m3 >> N cm3/elego/fileinfo/src/FileStatus.i3 >> N cm3/elego/fileinfo/src/DirTree.m3 >> N cm3/elego/fileinfo/src/Dummy.i3 >> N cm3/elego/fileinfo/src/FileStamp.i3 >> N cm3/elego/fileinfo/src/m3overrides >> N cm3/elego/fileinfo/src/DirTree.i3 >> N cm3/elego/fileinfo/src/APN.i3 >> N cm3/elego/fileinfo/src/FileDir.i3 >> N cm3/elego/fileinfo/src/FileInfo.i3 >> N cm3/elego/fileinfo/src/PathnameStatusTable.i3 >> N cm3/elego/fileinfo/src/FileStatus.m3 >> N cm3/elego/fileinfo/src/m3makefile >> N cm3/elego/fileinfo/src/Dummy.m3 >> N cm3/elego/fileinfo/src/FileSystem.m3 >> N cm3/elego/fileinfo/src/FileSystem.i3 >> N cm3/elego/fileinfo/src/PathnameStatusTable.m3 >> N cm3/elego/fileinfo/src/FileInfo.m3 >> N cm3/elego/fileinfo/src/APN.m3 >> N cm3/elego/fileinfo/src/TreeStamp.i3 >> N cm3/elego/fileinfo/src/FileStamp.m3 >> N cm3/elego/fileinfo/tests/PkgTags >> N cm3/elego/fileinfo/tests/src/m3overrides >> N cm3/elego/fileinfo/tests/src/Main.m3 >> N cm3/elego/fileinfo/tests/src/m3makefile >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.m3x >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.so.5 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APN.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APN.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/.M3WEB >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.io >> N cm3/elego/pkgvm/PkgTags >> N cm3/elego/pkgvm/PkgErr >> N cm3/elego/pkgvm/src/m3overrides >> N cm3/elego/pkgvm/src/Main.m3 >> N cm3/elego/pkgvm/src/pkgvm.desc >> N cm3/elego/pkgvm/src/m3makefile >> N cm3/elego/pkgvm/src/pkgvm.help >> N cm3/elego/pkgvm/src/compactrc >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.i3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm.mx >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.io >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.m3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.mo >> N cm3/elego/pkgvm/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkgvm/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.io >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.mo >> N cm3/elego/pkgvm/AMD64_FREEBSD/Main.mo >> N cm3/elego/graphicutils/PkgTags >> N cm3/elego/graphicutils/PkgErr >> N cm3/elego/graphicutils/src/RsrcUtils.i3 >> N cm3/elego/graphicutils/src/m3overrides >> N cm3/elego/graphicutils/src/RsrcUtils.m3 >> N cm3/elego/graphicutils/src/RsrcFilter.m3 >> N cm3/elego/graphicutils/src/StdFontsX.m3 >> N cm3/elego/graphicutils/src/StdFonts.m3 >> N cm3/elego/graphicutils/src/m3makefile >> N cm3/elego/graphicutils/src/RsrcFilter.i3 >> N cm3/elego/graphicutils/src/StdFontsWin32.m3 >> N cm3/elego/graphicutils/src/StdFonts.i3 >> N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.m3x >> N cm3/elego/graphicutils/AMD64_FREEBSD/StdFonts.io >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.mo >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.mo >> N cm3/elego/graphicutils/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/graphicutils/AMD64_FREEBSD/StdFontsX.mo >> N cm3/elego/graphicutils/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.so.5 >> N cm3/elego/graphicutils/AMD64_FREEBSD/.M3WEB >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.io >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.io >> N cm3/elego/m3dep/PkgTags >> N cm3/elego/m3dep/PkgErr >> N cm3/elego/m3dep/src/m3overrides >> N cm3/elego/m3dep/src/Main.m3 >> N cm3/elego/m3dep/src/m3makefile >> N cm3/elego/m3dep/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3dep/AMD64_FREEBSD/m3dep >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3dep/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3dep/AMD64_FREEBSD/m3dep.mx >> N cm3/elego/m3dep/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3dep/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3dep/AMD64_FREEBSD/Main.mo >> N cm3/elego/pkgversions/PkgTags >> N cm3/elego/pkgversions/PkgErr >> N cm3/elego/pkgversions/src/TagSort.m3 >> N cm3/elego/pkgversions/src/Version.m3 >> N cm3/elego/pkgversions/src/m3overrides >> N cm3/elego/pkgversions/src/TagSort.i3 >> N cm3/elego/pkgversions/src/Version.i3 >> N cm3/elego/pkgversions/src/m3makefile >> N cm3/elego/pkgversions/src/Tag.m3 >> N cm3/elego/pkgversions/src/Tag.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/Version.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.m3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.m3x >> N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.so.5 >> N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkgversions/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.m3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/Version.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.i3 >> N cm3/elego/m3makefile/PkgTags >> N cm3/elego/m3makefile/PkgErr >> N cm3/elego/m3makefile/src/m3overrides >> N cm3/elego/m3makefile/src/QCompiler.i3 >> N cm3/elego/m3makefile/src/QCompiler.m3 >> N cm3/elego/m3makefile/src/m3makefile >> N cm3/elego/m3makefile/src/M3makefile.m3 >> N cm3/elego/m3makefile/src/M3makefile.i3 >> N cm3/elego/m3makefile/test/src/Main.m3 >> N cm3/elego/m3makefile/test/src/m3makefile >> N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.m3x >> N cm3/elego/m3makefile/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.mo >> N cm3/elego/m3makefile/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.so.5 >> N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.io >> N cm3/elego/m3makefile/AMD64_FREEBSD/.M3WEB >> N cm3/elego/rsrcservice/PkgTags >> N cm3/elego/rsrcservice/PkgErr >> N cm3/elego/rsrcservice/src/RsrcService.i3 >> N cm3/elego/rsrcservice/src/m3overrides >> N cm3/elego/rsrcservice/src/m3makefile >> N cm3/elego/rsrcservice/src/ConfigRsrcService.m3 >> N cm3/elego/rsrcservice/src/ConfigRsrcService.i3 >> N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.mo >> N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.so.5 >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.mo >> N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.io >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.io >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3IMPTAB >> N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.m3x >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService.io >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3WEB >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.m3 >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.i3 >> N cm3/elego/pkg_base/PkgTags >> N cm3/elego/pkg_base/TODO >> N cm3/elego/pkg_base/PkgDesc >> N cm3/elego/pkg_base/PkgErr >> N cm3/elego/pkg_base/src/m3overrides >> N cm3/elego/pkg_base/src/PkgKindData.i3 >> N cm3/elego/pkg_base/src/PkgBase.DefaultData >> N cm3/elego/pkg_base/src/PkgBase.i3 >> N cm3/elego/pkg_base/src/m3makefile >> N cm3/elego/pkg_base/src/PkgKindData.m3 >> N cm3/elego/pkg_base/src/PkgBase.m3 >> N cm3/elego/pkg_base/src/PkgError.i3 >> N cm3/elego/pkg_base/test0/src/Main.m3 >> N cm3/elego/pkg_base/test0/src/kinds >> N cm3/elego/pkg_base/test0/src/m3makefile >> N cm3/elego/pkg_base/test0/src/dummy/bla >> N cm3/elego/pkg_base/test0/src/dummy/dummy-a/hugo >> N cm3/elego/pkg_base/test0/src/dummy/dummy-a/susi >> N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.m3x >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.i3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.i3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgError.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.m3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkg_base/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.m3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.so.5 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.io >> N cm3/elego/fsfind/PkgTags >> N cm3/elego/fsfind/PkgErr >> N cm3/elego/fsfind/src/FSFind.i3 >> N cm3/elego/fsfind/src/m3overrides >> N cm3/elego/fsfind/src/FileClassification.m3 >> N cm3/elego/fsfind/src/FindExecRec.m3 >> N cm3/elego/fsfind/src/FindExpr.i3 >> N cm3/elego/fsfind/src/FSFind.m3 >> N cm3/elego/fsfind/src/FindExecRec.i3 >> N cm3/elego/fsfind/src/FileClassification.i3 >> N cm3/elego/fsfind/src/FindExpr.m3 >> N cm3/elego/fsfind/src/FSFindError.i3 >> N cm3/elego/fsfind/src/m3makefile >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.m3 >> N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FSFindError.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.i3 >> N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.m3x >> N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.io >> N cm3/elego/fsfind/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/fsfind/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.io >> N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.so.5 >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/.M3WEB >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.i3 >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.io >> N cm3/elego/m3msh/PkgTags >> N cm3/elego/m3msh/PkgErr >> N cm3/elego/m3msh/src/m3overrides >> N cm3/elego/m3msh/src/m3msh.desc >> N cm3/elego/m3msh/src/m3makefile >> N cm3/elego/m3msh/src/m3msh.help >> N cm3/elego/m3msh/src/M3MiniShell.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.mo >> N cm3/elego/m3msh/AMD64_FREEBSD/m3msh.mx >> N cm3/elego/m3msh/AMD64_FREEBSD/M3MiniShell.mo >> N cm3/elego/m3msh/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.io >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3msh/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3msh/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/m3msh >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.i3 >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3dir/PkgTags >> N cm3/elego/m3dir/PkgErr >> N cm3/elego/m3dir/src/m3overrides >> N cm3/elego/m3dir/src/M3Dir.m3 >> N cm3/elego/m3dir/src/m3makefile >> N cm3/elego/m3dir/AMD64_FREEBSD/m3dir.mx >> N cm3/elego/m3dir/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3dir/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3dir/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3dir/AMD64_FREEBSD/M3Dir.mo >> N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3dir/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3dir/AMD64_FREEBSD/m3dir >> N cm3/elego/miniscan/PkgTags >> N cm3/elego/miniscan/PkgErr >> N cm3/elego/miniscan/src/m3overrides >> N cm3/elego/miniscan/src/ScanToken.i3 >> N cm3/elego/miniscan/src/m3makefile >> N cm3/elego/miniscan/src/SimpleScanner.i3 >> N cm3/elego/miniscan/src/SimpleScanner.m3 >> N cm3/elego/miniscan/src/ScanToken.m3 >> N cm3/elego/miniscan/test/src/m3overrides >> N cm3/elego/miniscan/test/src/Main.m3 >> N cm3/elego/miniscan/test/src/m3makefile >> N cm3/elego/miniscan/test/src/otto >> N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.io >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.mo >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.io >> N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.mo >> N cm3/elego/miniscan/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/miniscan/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.i3 >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.io >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.io >> N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.so.5 >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.i3 >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.m3 >> N cm3/elego/miniscan/AMD64_FREEBSD/.M3WEB >> N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.m3x >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.mo >> N cm3/elego/compactrc/PkgTags >> N cm3/elego/compactrc/PkgErr >> N cm3/elego/compactrc/src/m3overrides >> N cm3/elego/compactrc/src/CompactRC.m3 >> N cm3/elego/compactrc/src/CompactRC.i3 >> N cm3/elego/compactrc/src/compactrc.README >> N cm3/elego/compactrc/src/MiniEnv.i3 >> N cm3/elego/compactrc/src/compactrc.default >> N cm3/elego/compactrc/src/m3makefile >> N cm3/elego/compactrc/src/CompactEnvName.i3 >> N cm3/elego/compactrc/src/MiniEnv.m3 >> N cm3/elego/compactrc/src/compactrc.cd >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.mo >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.io >> N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.io >> N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.io >> N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.so.5 >> N cm3/elego/compactrc/AMD64_FREEBSD/CompactEnvName.io >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.m3 >> N cm3/elego/compactrc/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/compactrc/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.m3x >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.i3 >> N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.mo >> N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.mo >> N cm3/elego/compactrc/AMD64_FREEBSD/.M3WEB >> N cm3/elego/depgraph/PkgTags >> N cm3/elego/depgraph/PkgErr >> N cm3/elego/depgraph/src/StdDepGraph.m3 >> N cm3/elego/depgraph/src/DependencyGraph.i3 >> N cm3/elego/depgraph/src/StdDepGraphNode.m3 >> N cm3/elego/depgraph/src/m3overrides >> N cm3/elego/depgraph/src/StdDepGraph.i3 >> N cm3/elego/depgraph/src/StdDepGraphEdge.i3 >> N cm3/elego/depgraph/src/DependencyGraph.m3 >> N cm3/elego/depgraph/src/m3makefile >> N cm3/elego/depgraph/src/StdDepGraphNode.i3 >> N cm3/elego/depgraph/src/StdDepGraphEdge.m3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.m3x >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.m3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.m3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.i3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.io >> N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.so.5 >> N cm3/elego/depgraph/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/depgraph/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.i3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.io >> N cm3/elego/depgraph/AMD64_FREEBSD/.M3WEB >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.i3 >> >> No conflicts created by this import >> > -- 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 mika at async.async.caltech.edu Sun Aug 8 00:32:16 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 07 Aug 2010 15:32:16 -0700 Subject: [M3devel] more problems upgrading Message-ID: <20100807223216.78F951A20AD@async.async.caltech.edu> Hello m3devel, I'm running into problems again. Now I'm trying to upgrade CM3 on a FreeBSD 5 machine (248)rover:~/cm3/scripts>uname -a FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #0: Sat May 24 10:13:58 PDT 2008 root at rover:/usr/src/sys/i386/compile/ROVERSMP i386 (250)rover:~/cm3/scripts>cm3 -version Critical Mass Modula-3 version d5.8.1 last updated: 2009-05-16 compiled: 2009-06-16 20:34:18 configuration: /usr/local/cm3/bin/cm3.cfg target: FreeBSD4 upgrade.sh runs for a while then dies at: === package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3 === +++ cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' +++ --- building in FreeBSD4 --- ignoring ../src/m3overrides Fatal Error: duplicate link info: M3Path.i3 *** execution of cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' failed *** The reason I'm doing this, by the way, is that I'm having trouble sharing pickles between an amd64 and i386 system and wanted to ensure I have recent CM3 distributions on both systems before starting to debug the problem. It appears I can write pickles on i386 and read them on amd64 without trouble, but not the other way around (and I am not using any out-of-range values, I don't think). Mika From mika at async.async.caltech.edu Sun Aug 8 01:01:11 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 07 Aug 2010 16:01:11 -0700 Subject: [M3devel] more problems upgrading In-Reply-To: <20100807223216.78F951A20AD@async.async.caltech.edu> References: <20100807223216.78F951A20AD@async.async.caltech.edu> Message-ID: <20100807230111.66FC31A20AF@async.async.caltech.edu> Sorry to spam the list, this was user error. Mika Nystrom writes: >Hello m3devel, > >I'm running into problems again. Now I'm trying to upgrade CM3 on >a FreeBSD 5 machine > >(248)rover:~/cm3/scripts>uname -a >FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #0: Sat May 24 10:13:58 PDT 2008 > root at rover:/usr/src/sys/i386/compile/ROVERSMP i386 >(250)rover:~/cm3/scripts>cm3 -version >Critical Mass Modula-3 version d5.8.1 > last updated: 2009-05-16 > compiled: 2009-06-16 20:34:18 > configuration: /usr/local/cm3/bin/cm3.cfg > target: FreeBSD4 > >upgrade.sh runs for a while then dies at: > >=== package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3 === > +++ cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $R >ARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' +++ >--- building in FreeBSD4 --- > >ignoring ../src/m3overrides > > >Fatal Error: duplicate link info: M3Path.i3 > > *** execution of cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && > cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' failed *** > > >The reason I'm doing this, by the way, is that I'm having trouble >sharing pickles between an amd64 and i386 system and wanted to ensure I >have recent CM3 distributions on both systems before starting to debug >the problem. > >It appears I can write pickles on i386 and read them on amd64 without >trouble, but not the other way around (and I am not using any out-of-range >values, I don't think). > > Mika From jay.krell at cornell.edu Sun Aug 8 01:30:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 23:30:17 +0000 Subject: [M3devel] more problems upgrading In-Reply-To: <20100807230111.66FC31A20AF@async.async.caltech.edu> References: <20100807223216.78F951A20AD@async.async.caltech.edu>, <20100807230111.66FC31A20AF@async.async.caltech.edu> Message-ID: I believe I moved M3Path.*, like from cm3 to m3quake. There is a bug; this requires clean. I don't know if upgrade.sh gets any use these days. I use upgrade.py often. Note that upgrade.py does not rebuild entire system, just compiler. E.g. . /upgrade.py skipgcc && ./do-cm3-all.py skipgcc realclean && ./do-cm3-all.py skipgcc buildship - Jay/phone > To: m3devel at elegosoft.com > Date: Sat, 7 Aug 2010 16:01:11 -0700 > From: mika at async.async.caltech.edu > Subject: Re: [M3devel] more problems upgrading > > Sorry to spam the list, this was user error. > > Mika Nystrom writes: > >Hello m3devel, > > > >I'm running into problems again. Now I'm trying to upgrade CM3 on > >a FreeBSD 5 machine > > > >(248)rover:~/cm3/scripts>uname -a > >FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #0: Sat May 24 10:13:58 PDT 2008 > > root at rover:/usr/src/sys/i386/compile/ROVERSMP i386 > >(250)rover:~/cm3/scripts>cm3 -version > >Critical Mass Modula-3 version d5.8.1 > > last updated: 2009-05-16 > > compiled: 2009-06-16 20:34:18 > > configuration: /usr/local/cm3/bin/cm3.cfg > > target: FreeBSD4 > > > >upgrade.sh runs for a while then dies at: > > > >=== package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3 === > > +++ cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $R > >ARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' +++ > >--- building in FreeBSD4 --- > > > >ignoring ../src/m3overrides > > > > > >Fatal Error: duplicate link info: M3Path.i3 > > > > *** execution of cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && > > cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' failed *** > > > > > >The reason I'm doing this, by the way, is that I'm having trouble > >sharing pickles between an amd64 and i386 system and wanted to ensure I > >have recent CM3 distributions on both systems before starting to debug > >the problem. > > > >It appears I can write pickles on i386 and read them on amd64 without > >trouble, but not the other way around (and I am not using any out-of-range > >values, I don't think). > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 8 01:44:57 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 7 Aug 2010 19:44:57 -0400 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: References: Message-ID: <15EA2A2D-8D4F-4749-9FA1-0C58BC2690FE@cs.purdue.edu> I can add a few Hudson nodes sometime. Both AMD64 Linux and Solaris Sparc. 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 7 Aug 2010, at 10:30, Jay K wrote: > > Hey, I'm hoping we can get more people helping more. > > Coding, features, fixing bugs, etc. > > > However one of the easiest things I'd like to see is a few more Hudson nodes. > > > Is anyone out there running e.g. NetBSD on x86 or AMD64? > They would be the easiest, sort of, to setup. I will help anyone. > Or Solaris on SPARC (replace mine) or x86? (Yes I know about opencsw, but the network > topology is seemingly difficult.) > > > Or heck, Linux or OpenBSD on x86? (replace mine) > > > x86/AMD64 in particular has better availability of Java VMs, which we need. > Or, Linux now has good across the board Java support. > > > And can setup dynamic DNS or has static IP? > > > We could use NT386 but I know the setup might not be so easy. > > > There are other viable machines, e.g. one of the new or old Linux/mips. > Or likely some of the obscure systems like HP-UX, AIX, Irix. > If anyone here is actively running one of these, keeps machine on, speak up. > (At some point, I'd like to have Hudson wake-on-lan the machines, > or have the machines scheduled to wake up daily check for work, and then > back to sleep after completing any queued work; the second option > doesn't require Hudson support.) > > > The machine can be quite low end. > Many of mine are old laptops, or very old either way. > Around $200, years ago. > > > Any other projects in the system people are interested in helping out on, with > time/coding, please speak up if you need help. If you need ideas, or assistance, etc. > > > Thanks, > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Aug 8 04:51:30 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 07 Aug 2010 19:51:30 -0700 Subject: [M3devel] CM3 problems Message-ID: <20100808025130.354B71A20BC@async.async.caltech.edu> With what I found in CVS today, I see the following for a program of mine I'm trying to compile: new source -> compiling Main.m3 "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr 3 warnings encountered ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:225: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:225: error: this is the insn: (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ (set (reg:SI 112) (const_int 0 [0x0])) (set (reg:SI 110) (plus:SI (ashift:SI (reg:SI 112) (const_int 2 [0x2])) (reg:SI 110))) (set (reg:SI 111) (plus:SI (ashift:SI (reg:SI 112) (const_int 2 [0x2])) (reg:SI 111))) (set (mem/s/c:BLK (reg:SI 110) [0 M3_A91vEE_trade+0 S24 A64]) (mem/s/c:BLK (reg:SI 111) [0 M3_A91vEE_trade+0 S24 A32])) (use (reg:SI 112)) ]) 586 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 112) (expr_list:REG_UNUSED (reg:SI 111) (expr_list:REG_UNUSED (reg:SI 110) (nil))))) ../src/Main.m3:225: confused by earlier errors, bailing out m3_backend => 4 m3cc (aka cm3cg) failed compiling: Main.mc compilation failed => not building program "ximport" Fatal Error: package build failed Any hints as to how to deal with this? I have optimization turned off. Mika From jay.krell at cornell.edu Sun Aug 8 05:09:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 8 Aug 2010 03:09:07 +0000 Subject: [M3devel] CM3 problems In-Reply-To: <20100808025130.354B71A20BC@async.async.caltech.edu> References: <20100808025130.354B71A20BC@async.async.caltech.edu> Message-ID: Not very useful of me, but standard questions: Is this your code? Can we see it? Is cm3cg current? Can you try with optimization? ?-O1, -O2, -O3 cheating perhaps to use optimization? ?? They should all generally work..though you should also generally never see such errors.. Tony might ask to see the IR via ? rm -rf FreeBSD4? ? cm3 -keep ? ordinarily the *.mc files are deleted? ? cm3cg -y FreeBSD4/Main.mc?? (it goes to stderr not stdout)? ?or more accurately (at least for other purposes)? ? rm -rf FreeBSD4? ? cm3 -keep -commands? ? find the cm3cg command? ? cd FreBSD4 ? rerun cm3cg command but with -y added? though I probably won't be able to glean anything from it. Is cm3cg 4.3.0 or 4.3.5? I'm curious. I upgraded is recently to 4.3.5. ? I don't know of any problems it fixed or caused. cm3cg -v will tell you. This is FreeBSD5/x86, right? Can you try on any other machines? e.g. your Alpha? eh. that's probably changing too much. x86 is by far the register-poorest. Search the web for this error? Maybe it occurs using C as well with "similar" code? ?- Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Sat, 7 Aug 2010 19:51:30 -0700 > From: mika at async.async.caltech.edu > Subject: [M3devel] CM3 problems > > With what I found in CVS today, I see the following for a program > of mine I'm trying to compile: > > > new source -> compiling Main.m3 > "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr > 3 warnings encountered > ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': > ../src/Main.m3:225: error: unable to find a register to spill in class 'CREG' > ../src/Main.m3:225: error: this is the insn: > (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ > (set (reg:SI 112) > (const_int 0 [0x0])) > (set (reg:SI 110) > (plus:SI (ashift:SI (reg:SI 112) > (const_int 2 [0x2])) > (reg:SI 110))) > (set (reg:SI 111) > (plus:SI (ashift:SI (reg:SI 112) > (const_int 2 [0x2])) > (reg:SI 111))) > (set (mem/s/c:BLK (reg:SI 110) [0 M3_A91vEE_trade+0 S24 A64]) > (mem/s/c:BLK (reg:SI 111) [0 M3_A91vEE_trade+0 S24 A32])) > (use (reg:SI 112)) > ]) 586 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 112) > (expr_list:REG_UNUSED (reg:SI 111) > (expr_list:REG_UNUSED (reg:SI 110) > (nil))))) > ../src/Main.m3:225: confused by earlier errors, bailing out > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: Main.mc > compilation failed => not building program "ximport" > Fatal Error: package build failed > > Any hints as to how to deal with this? I have optimization turned off. > > Mika > > From mika at async.async.caltech.edu Sun Aug 8 16:58:57 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 08 Aug 2010 07:58:57 -0700 Subject: [M3devel] CM3 problems In-Reply-To: References: <20100808025130.354B71A20BC@async.async.caltech.edu> Message-ID: <20100808145857.3D7D41A20AF@async.async.caltech.edu> I ran upgrade.sh before compiling, so everything should be up to date. I'd be happy to give you the code (yes it's mine) but I'm not sure how many libraries it depends on. Same thing happens with optimization (-O2). (133)rover:~/u/calarm/regress/ximport/FreeBSD4>/usr/local/cm3//bin/cm3cg -march=i586 -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m32 -O3 -Wuninitialized -gstabs+ Main.mc -o Main.ms ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:225: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:225: error: this is the insn: (insn:HI 5 4 6 2 ../src/Main.m3:204 (parallel [ (set (reg:SI 0 ax [69]) (const_int 0 [0x0])) (set (reg:SI 5 di [67]) (plus:SI (ashift:SI (reg:SI 0 ax [69]) (const_int 2 [0x2])) (reg:SI 5 di [67]))) (set (reg/f:SI 4 si [68]) (plus:SI (ashift:SI (reg:SI 0 ax [69]) (const_int 2 [0x2])) (reg/f:SI 16 argp))) (set (mem/s/c:BLK (reg:SI 5 di [67]) [0 M3_A91vEE_trade+0 S24 A64]) (mem/s/c:BLK (reg/f:SI 16 argp) [0 M3_A91vEE_trade+0 S24 A32])) (use (reg:SI 0 ax [69])) ]) 586 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [69]) (expr_list:REG_UNUSED (reg/f:SI 4 si [68]) (expr_list:REG_UNUSED (reg:SI 5 di [67]) (nil))))) ../src/Main.m3:225: confused by earlier errors, bailing out I copied the derived directory (after running cm3 -x -keep) to http://rover.gcapltd.com/~mika/ximport-bug-FreeBSD4/ in case anyone wants to peek at it. I also put Main.m3 in there so you can see what's going on. Nested procedures... but nothing that looks too weird to me. Mika Jay K writes: > >Not very useful of me=2C but standard questions: > > >Is this your code? >Can we see it? >Is cm3cg current? >Can you try with optimization? >=A0-O1=2C -O2=2C -O3 cheating perhaps to use optimization=A0=20 >=A0=A0 They should all generally work..though you should also generally nev= >er see such errors.. >Tony might ask to see the IR via=20 >=A0 rm -rf FreeBSD4=A0=20 >=A0 cm3 -keep =A0 ordinarily the *.mc files are deleted=A0=20 >=A0 cm3cg -y FreeBSD4/Main.mc=A0=A0 (it goes to stderr not stdout)=A0=20 >=A0or more accurately (at least for other purposes)=A0=20 >=A0 rm -rf FreeBSD4=A0=20 > >=A0 cm3 -keep -commands=A0=20 >=A0 find the cm3cg command=A0=20 >=A0 cd FreBSD4=20 >=A0 rerun cm3cg command but with -y added=A0=20 From wagner at elegosoft.com Mon Aug 9 10:21:36 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 10:21:36 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Message-ID: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> After several weeks (months?) of little activity I was able to setup some more build and regression test jobs on the opencsw.org machines. There are now sets of jobs for SOLsun built on Solaris 10 (works) run on current10s.opencsw.org SOLsun built on Solaris 9 (seems now to work, too) run on current9s I386_SOLARIS built on Solaris 10 (still several problems) run on current10x For the instruction and exhilaration of those willing to read on I'll give some details. One of the problems was entirely my own fault. In the regression defs.sh script, about a dozen error messages were written to 1>2 instead of 1>&2. The second correct form redirects stdout to stderr, while the first just writes the contents to a file named 2 :-/ It's not that I haven't got enough experience with writing shell scripts (in fact I've done that hundreds of times), but I must have made a typo in one place in the original file version and copied that to many other locations. It is interesting that I didn't notice that for years, though I've looked at it all the time. I was getting desparate about unexplained stops in the scripts tonight when finally a veil seems to have been removed from my eyes. Currently I know of two other problems running our builds and tests on the opencsw machines. 1. cvs update does not work on current10x (Solaris on x86) when run from Hudson. It does work on current10s and current9s. It does work if I disable compression (but can do that only for all jobs, which would be a bad pessimization). It does work if I run it from the command line. cvs co in Hudson works OK, too. All attempts to update workspaces by Hudson fail with [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 8:59:46 PM UTC" ... cvs [update aborted]: end of file from server (consult above messages if any) FATAL: CVS failed. exit code=1 Obviously, there are no above messages to consult. If anybody has any ideas what could be causing this, I'd like to hear it. Without update, all the jobs will run rather long on that machine. All machines run exactly the same version of CVS. 2. Copying any archive files out again via ssh and scp has not worked yet. I still need to investigate this, but have hope that I can make this work. Builds for more target platforms should be setup on those machines, but it's tedious work. If anybody wants to take a try, that will be appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 9 11:36:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 9 Aug 2010 09:36:39 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: Very nice. Copying & cvs could be separate tasks, run on login? ("login" being a machine, not a "time"). In fact these all share one filesystem & could share workspaces, albeit with serialization? The problem isn't sharing without serialization? The other interesting platforms are AMD64_SOLARIS and SPARC64_SOLARIS. Should consider SPARC32_SOLARIS & drop SOLgnu & SOLsun. It is already implemented. Thanks, - Jay/phone > Date: Mon, 9 Aug 2010 10:21:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > After several weeks (months?) of little activity I was able to setup > some more build and regression test jobs on the opencsw.org machines. > > There are now sets of jobs for > > SOLsun built on Solaris 10 (works) run on current10s.opencsw.org > SOLsun built on Solaris 9 (seems now to work, too) run on current9s > I386_SOLARIS built on Solaris 10 (still several problems) run on current10x > > For the instruction and exhilaration of those willing to read on I'll > give some details. > > One of the problems was entirely my own fault. In the regression defs.sh > script, about a dozen error messages were written to 1>2 instead of 1>&2. > The second correct form redirects stdout to stderr, while the first just > writes the contents to a file named 2 :-/ It's not that I haven't got > enough experience with writing shell scripts (in fact I've done that > hundreds of times), but I must have made a typo in one place in the > original file version and copied that to many other locations. It is > interesting that I didn't notice that for years, though I've looked > at it all the time. I was getting desparate about unexplained stops > in the scripts tonight when finally a veil seems to have been removed > from my eyes. > > Currently I know of two other problems running our builds and tests > on the opencsw machines. > > 1. cvs update does not work on current10x (Solaris on x86) when run from > Hudson. > It does work on current10s and current9s. > It does work if I disable compression (but can do that only for all jobs, > which would be a bad pessimization). > It does work if I run it from the command line. > cvs co in Hudson works OK, too. > > All attempts to update workspaces by Hudson fail with > > [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 8:59:46 PM UTC" > ... > cvs [update aborted]: end of file from server (consult above > messages if any) > FATAL: CVS failed. exit code=1 > > Obviously, there are no above messages to consult. > If anybody has any ideas what could be causing this, I'd like to > hear it. Without update, all the jobs will run rather long on that > machine. > All machines run exactly the same version of CVS. > > 2. Copying any archive files out again via ssh and scp has not worked > yet. I still need to investigate this, but have hope that I can make > this work. > > Builds for more target platforms should be setup on those machines, > but it's tedious work. If anybody wants to take a try, that will be > appreciated. > > 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 wagner at elegosoft.com Mon Aug 9 12:28:56 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 12:28:56 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: <20100809122856.m94sq8ulss4scwgo@mail.elegosoft.com> Quoting Jay K : > Very nice. > > Copying & cvs could be separate tasks, run on login? ("login" being > a machine, not a "time"). Copying out will probably be no problem, but CVS is tightly integrated into Hudson and needs to be (for impact tracking). I already considered running cvs on login.opencsw.org, but don't know how to configure that. > In fact these all share one filesystem & could share workspaces, > albeit with serialization? The problem isn't sharing without > serialization? No, the workspaces are different (hostname in paths). That would be an imaginable setup, too. But Hudson likes to keep jobs separate and isolated, so it would be even more work I think. > The other interesting platforms are AMD64_SOLARIS and > SPARC64_SOLARIS. Should consider SPARC32_SOLARIS & drop SOLgnu & > SOLsun. It is already implemented. Yes, I should have used SPARC32_SOLARIS instead of SOLsun; will change that at the next opportunity. Do I just need to set the TARGET to compile for those platforms (including AMD64/SPARC64) on those machines? Olaf >> Date: Mon, 9 Aug 2010 10:21:36 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] Short status of CM3 Hudson regression testing >> on opencsw.org machines >> >> After several weeks (months?) of little activity I was able to setup >> some more build and regression test jobs on the opencsw.org machines. >> >> There are now sets of jobs for >> >> SOLsun built on Solaris 10 (works) run on current10s.opencsw.org >> SOLsun built on Solaris 9 (seems now to work, too) run on current9s >> I386_SOLARIS built on Solaris 10 (still several problems) run on >> current10x >> >> For the instruction and exhilaration of those willing to read on I'll >> give some details. >> >> One of the problems was entirely my own fault. In the regression defs.sh >> script, about a dozen error messages were written to 1>2 instead of 1>&2. >> The second correct form redirects stdout to stderr, while the first just >> writes the contents to a file named 2 :-/ It's not that I haven't got >> enough experience with writing shell scripts (in fact I've done that >> hundreds of times), but I must have made a typo in one place in the >> original file version and copied that to many other locations. It is >> interesting that I didn't notice that for years, though I've looked >> at it all the time. I was getting desparate about unexplained stops >> in the scripts tonight when finally a veil seems to have been removed >> from my eyes. >> >> Currently I know of two other problems running our builds and tests >> on the opencsw machines. >> >> 1. cvs update does not work on current10x (Solaris on x86) when run from >> Hudson. >> It does work on current10s and current9s. >> It does work if I disable compression (but can do that only for >> all jobs, >> which would be a bad pessimization). >> It does work if I run it from the command line. >> cvs co in Hudson works OK, too. >> >> All attempts to update workspaces by Hudson fail with >> >> [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 >> 8:59:46 PM UTC" >> ... >> cvs [update aborted]: end of file from server (consult above >> messages if any) >> FATAL: CVS failed. exit code=1 >> >> Obviously, there are no above messages to consult. >> If anybody has any ideas what could be causing this, I'd like to >> hear it. Without update, all the jobs will run rather long on that >> machine. >> All machines run exactly the same version of CVS. >> >> 2. Copying any archive files out again via ssh and scp has not worked >> yet. I still need to investigate this, but have hope that I can make >> this work. >> >> Builds for more target platforms should be setup on those machines, >> but it's tedious work. If anybody wants to take a try, that will be >> appreciated. >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 9 12:48:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 9 Aug 2010 10:48:31 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809122856.m94sq8ulss4scwgo@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com>, , <20100809122856.m94sq8ulss4scwgo@mail.elegosoft.com> Message-ID: Do I just need to set the TARGET to compile for those platforms (including AMD64/SPARC64) on those machines? Um, yes, should just work? (famous lie..). Should even be able to use the same cm3cg. - Jay > Date: Mon, 9 Aug 2010 12:28:56 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting Jay K : > > > Very nice. > > > > Copying & cvs could be separate tasks, run on login? ("login" being > > a machine, not a "time"). > Copying out will probably be no problem, but CVS is tightly integrated > into Hudson and needs to be (for impact tracking). I already considered > running cvs on login.opencsw.org, but don't know how to configure that. > > > In fact these all share one filesystem & could share workspaces, > > albeit with serialization? The problem isn't sharing without > > serialization? > > No, the workspaces are different (hostname in paths). > > That would be an imaginable setup, too. But Hudson likes to keep > jobs separate and isolated, so it would be even more work I think. > > > The other interesting platforms are AMD64_SOLARIS and > > SPARC64_SOLARIS. Should consider SPARC32_SOLARIS & drop SOLgnu & > > SOLsun. It is already implemented. > > Yes, I should have used SPARC32_SOLARIS instead of SOLsun; will change > that at the next opportunity. > > Do I just need to set the TARGET to compile for those platforms (including > AMD64/SPARC64) on those machines? > > Olaf > > >> Date: Mon, 9 Aug 2010 10:21:36 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> > >> After several weeks (months?) of little activity I was able to setup > >> some more build and regression test jobs on the opencsw.org machines. > >> > >> There are now sets of jobs for > >> > >> SOLsun built on Solaris 10 (works) run on current10s.opencsw.org > >> SOLsun built on Solaris 9 (seems now to work, too) run on current9s > >> I386_SOLARIS built on Solaris 10 (still several problems) run on > >> current10x > >> > >> For the instruction and exhilaration of those willing to read on I'll > >> give some details. > >> > >> One of the problems was entirely my own fault. In the regression defs.sh > >> script, about a dozen error messages were written to 1>2 instead of 1>&2. > >> The second correct form redirects stdout to stderr, while the first just > >> writes the contents to a file named 2 :-/ It's not that I haven't got > >> enough experience with writing shell scripts (in fact I've done that > >> hundreds of times), but I must have made a typo in one place in the > >> original file version and copied that to many other locations. It is > >> interesting that I didn't notice that for years, though I've looked > >> at it all the time. I was getting desparate about unexplained stops > >> in the scripts tonight when finally a veil seems to have been removed > >> from my eyes. > >> > >> Currently I know of two other problems running our builds and tests > >> on the opencsw machines. > >> > >> 1. cvs update does not work on current10x (Solaris on x86) when run from > >> Hudson. > >> It does work on current10s and current9s. > >> It does work if I disable compression (but can do that only for > >> all jobs, > >> which would be a bad pessimization). > >> It does work if I run it from the command line. > >> cvs co in Hudson works OK, too. > >> > >> All attempts to update workspaces by Hudson fail with > >> > >> [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 > >> 8:59:46 PM UTC" > >> ... > >> cvs [update aborted]: end of file from server (consult above > >> messages if any) > >> FATAL: CVS failed. exit code=1 > >> > >> Obviously, there are no above messages to consult. > >> If anybody has any ideas what could be causing this, I'd like to > >> hear it. Without update, all the jobs will run rather long on that > >> machine. > >> All machines run exactly the same version of CVS. > >> > >> 2. Copying any archive files out again via ssh and scp has not worked > >> yet. I still need to investigate this, but have hope that I can make > >> this work. > >> > >> Builds for more target platforms should be setup on those machines, > >> but it's tedious work. If anybody wants to take a try, that will be > >> appreciated. > >> > >> 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 dam at opencsw.org Mon Aug 9 13:47:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Aug 2010 13:47:12 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: Hi Olaf, Am 09.08.2010 um 10:21 schrieb Olaf Wagner: > Currently I know of two other problems running our builds and tests > on the opencsw machines. > > 1. cvs update does not work on current10x (Solaris on x86) when run > from > Hudson. > It does work on current10s and current9s. Interesting. current*s are all running on the same physical machine as zones, whereas current*x are located on a vSphere farm. Do you have a specific command sequence which I can try to reproduce the problem? Are you using cvs stable (1.11.23) or feature (1.12.13)? > It does work if I disable compression (but can do that only for > all jobs, > which would be a bad pessimization). > It does work if I run it from the command line. > cvs co in Hudson works OK, too. This sounds like a strange and subtle bug... Best regards -- Dago From rcolebur at SCIRES.COM Mon Aug 9 16:27:24 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 9 Aug 2010 10:27:24 -0400 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: References: Message-ID: Windows is my current platform for Modula-3. I can make available machines for various flavors of Windows. I don't understand much about the current Hudson automation, but I am willing to learn and to do some customization for support on Windows. I also have some old Apple iBook notebooks that I could enlist, if these would help. I also have a very old HP-UX machine that would need some work to get running again. I also have a Sun workstation that hasn't been booted up in a few years. I think it has Solaris 9 on it, but I am pretty sure we could replace the OS with Solaris 10 or something else. Let me know if any of these are needed. Regards, Randy -----Original Message----- From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Saturday, August 07, 2010 10:30 AM To: m3devel Subject: [M3devel] more Hudson nodes? more help in general? Hey, I'm hoping we can get more people helping more. Coding, features, fixing bugs, etc. However one of the easiest things I'd like to see is a few more Hudson nodes. Is anyone out there running e.g. NetBSD on x86 or AMD64? ? They would be the easiest, sort of, to setup. I will help anyone. ? Or Solaris on SPARC (replace mine) or x86? (Yes I know about opencsw, but the network ? topology is seemingly difficult.) Or heck, Linux or OpenBSD on x86? (replace mine) x86/AMD64 in particular has better availability of Java VMs, which we need. Or, Linux now has good across the board Java support. And can setup dynamic DNS or has static IP? We could use NT386 but I know the setup might not be so easy. There are other viable machines, e.g. one of the new or old Linux/mips. Or likely some of the obscure systems like HP-UX, AIX, Irix. If anyone here is actively running one of these, keeps machine on, speak up. (At some point, I'd like to have Hudson wake-on-lan the machines, or have the machines scheduled to wake up daily check for work, and then back to sleep after completing any queued work; the second option doesn't require Hudson support.) The machine can be quite low end. Many of mine are old laptops, or very old either way. Around $200, years ago. Any other projects in the system people are interested in helping out on, with ? time/coding, please speak up if you need help. If you need ideas, or assistance, etc. Thanks, ?- Jay From wagner at elegosoft.com Mon Aug 9 17:01:24 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 17:01:24 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> Quoting Dagobert Michelsen : > Hi Olaf, > > Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >> Currently I know of two other problems running our builds and tests >> on the opencsw machines. >> >> 1. cvs update does not work on current10x (Solaris on x86) when run from >> Hudson. >> It does work on current10s and current9s. > > Interesting. current*s are all running on the same physical machine as zones, > whereas current*x are located on a vSphere farm. Do you have a specific > command sequence which I can try to reproduce the problem? I'm not yet able to reproduce it manually; I only see it in the Hudson jobs (failing right away when computing the changelog). If you want, I can setup a job for test purposes and you can get Hudson access. > Are you using cvs stable (1.11.23) or feature (1.12.13)? Stable. I'll try with 1.12.13, too (haven't seen that around). Is it installed anywhere?? >> It does work if I disable compression (but can do that only for all jobs, >> which would be a bad pessimization). >> It does work if I run it from the command line. >> cvs co in Hudson works OK, too. > > This sounds like a strange and subtle bug... Yep. 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 Mon Aug 9 17:13:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 17:13:30 +0200 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: References: Message-ID: <20100809171330.fe3pc7nwgwosg4wg@mail.elegosoft.com> Quoting "Coleburn, Randy" : > Windows is my current platform for Modula-3. I can make available > machines for various flavors of Windows. > > I don't understand much about the current Hudson automation, but I > am willing to learn and to do some customization for support on > Windows. > > I also have some old Apple iBook notebooks that I could enlist, if > these would help. I also have a very old HP-UX machine that would > need some work to get running again. > > I also have a Sun workstation that hasn't been booted up in a few > years. I think it has Solaris 9 on it, but I am pretty sure we > could replace the OS with Solaris 10 or something else. > > Let me know if any of these are needed. Another (more reliable) Windows client would be great, but be forwarned that it won't be easy to get it running in combination with the existing scripts. We had to get another commercial ssh daemon IIRC, and me and Jay have hunted down failures for weeks. The Apple iBook may also be of interest (if it is not too slow). What version of MacOS is it running? My own old Powerbook (400 MHz) is currently running the PPC_DARWIN tests. Sun should be fairly well covered, if we succeed with all the opencsw.org machines, and Antony Hosking has also a machine currently running the tinderbox tests, IIRC. IMO we could probably do without Tinderbox soon. I'm not sure if anybody is really interested in HPUX. For me this seems to have mostly hostorical value :-) I may be wrong there of course... Olaf > Regards, > Randy > > > -----Original Message----- > From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K > Sent: Saturday, August 07, 2010 10:30 AM > To: m3devel > Subject: [M3devel] more Hudson nodes? more help in general? > > > Hey, I'm hoping we can get more people helping more. > > Coding, features, fixing bugs, etc. > > > However one of the easiest things I'd like to see is a few more Hudson nodes. > > > Is anyone out there running e.g. NetBSD on x86 or AMD64? > ? They would be the easiest, sort of, to setup. I will help anyone. > ? Or Solaris on SPARC (replace mine) or x86? (Yes I know about > opencsw, but the network > ? topology is seemingly difficult.) > > > Or heck, Linux or OpenBSD on x86? (replace mine) > > > x86/AMD64 in particular has better availability of Java VMs, which we need. > Or, Linux now has good across the board Java support. > > > And can setup dynamic DNS or has static IP? > > > We could use NT386 but I know the setup might not be so easy. > > > There are other viable machines, e.g. one of the new or old Linux/mips. > Or likely some of the obscure systems like HP-UX, AIX, Irix. > If anyone here is actively running one of these, keeps machine on, speak up. > (At some point, I'd like to have Hudson wake-on-lan the machines, > or have the machines scheduled to wake up daily check for work, and then > back to sleep after completing any queued work; the second option > doesn't require Hudson support.) > > > The machine can be quite low end. > Many of mine are old laptops, or very old either way. > Around $200, years ago. > > > Any other projects in the system people are interested in helping > out on, with > ? time/coding, please speak up if you need help. If you need ideas, > or assistance, etc. > > > Thanks, > ?- 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 m3 at sol42.com Mon Aug 9 22:17:35 2010 From: m3 at sol42.com (m3 at sol42.com) Date: Mon, 9 Aug 2010 22:17:35 +0200 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: <20100809171330.fe3pc7nwgwosg4wg@mail.elegosoft.com> References: <20100809171330.fe3pc7nwgwosg4wg@mail.elegosoft.com> Message-ID: Hello. I know we are talking about machines that would be running 24/7, but maybe is there a way for a machine to automatically join a Hudson server and do some work when it is booted say twice a week (which I concede is the opposite of continuous integration)? I have some machines that might be of help, but I don't do much with them nowadays and cannot afford to keep them up all the time: - mostly silent: a Mac mini G4, 1,5GHz, 1GB RAM, Mac OS X 10.5.8; - somewhat noisy: a Sun Ultra 60, 2*450 MHz, 2GB RAM, Solaris 10 from some time before Oracle changed Solaris terms (meaning it won't be upgraded, but I keep the JDK current); - like having an airport inside the room: an IRIX machine Hudson will not run on due to lack of a 1.5 JRE :( but if I keep it on in winter then I can turn off heating. Regards. -Daniel From dabenavidesd at yahoo.es Tue Aug 10 01:00:49 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 9 Aug 2010 23:00:49 +0000 (GMT) Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: Message-ID: <573133.51461.qm@web29705.mail.ird.yahoo.com> Hi all: well in that case it would be probably less efficient to have running over and over probably if you are brave enough to virtualize it might be possible to load a good server with some virtual machines which later you can teleport like Vbox over a net and run for testing of the concept like you say twice a week. Tere is one in aprticular probably useful for the Irix the SimOS, which run natevely in the IRIX and others now, also other platforms like DEC Alpha and power PC. I have downloaded an article from computer world library so you can check for details in the efficient virtualization affairs, it requires sign up to grab it (see http://www.vision6.com.au/ch/21104/2d34n3v/1289505/1b836s789.html ) so you can have it from here (just accept secure certificate and agree to add an exception): https://168.176.86.16/~danielb/Virtualization_APC.pdf As for the JVM you can have Loongson JVM for free ( http://debian.printk.org/software-loongson/jvm/jdk15_mips_080103.tar.gz ) in those machines to do the JVM part of the job, though not sure if hat works for your needs and available resources and system implementation. Thanks in advance --- El lun, 9/8/10, m3 at sol42.com escribi?: > De: m3 at sol42.com > Asunto: Re: [M3devel] more Hudson nodes? more help in general? > Para: "m3devel" > Fecha: lunes, 9 de agosto, 2010 15:17 > Hello. I know we are talking > about machines that would be running 24/7, but maybe is > there a way for a machine to automatically join a Hudson > server and do some work when it is booted say twice a week > (which I concede is the opposite of continuous > integration)? > I have some machines that might be of help, but I don't do > much with them nowadays and cannot afford to keep them up > all the time: > - mostly silent: a Mac mini G4, 1,5GHz, 1GB RAM, Mac OS X > 10.5.8; > - somewhat noisy: a Sun Ultra 60, 2*450 MHz, 2GB RAM, > Solaris 10 from some time before Oracle changed Solaris > terms (meaning it won't be upgraded, but I keep the JDK > current); > - like having an airport inside the room: an IRIX machine > Hudson will not run on due to lack of a 1.5 JRE :( but if I > keep it on in winter then I can turn off heating. > Regards. > -Daniel From jay.krell at cornell.edu Tue Aug 10 02:29:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 10 Aug 2010 00:29:20 +0000 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: <573133.51461.qm@web29705.mail.ird.yahoo.com> References: , <573133.51461.qm@web29705.mail.ird.yahoo.com> Message-ID: Virtualization works great for x86, AMD64. Less so for others. There is "gxemul" but it is less widely used, probably harder to use, I haven't tried it yet. It might work for MIPS esp. There was a project to remove the assembly code from Sun's Java. As a result, Java is well available on any architecture on Linux. e.g. we have Linux/powerpc, Linux/sparc, and I expect we'll soon have Linux/mips, in Hudson. But so far it is Linux-only where this work can be used, as far as I know. I was thinking we could move the Elego NT386 VM. Probably should run sysprep /generalize on it first. Sparc, PowerPC do have some sorts of virtualization, but it is kind of more esoteric and I suspect harder to use. e.g. on Solaris, on AIX. I hadn't heard of SimOS and maybe others. More research to do.. Thanks, - Jay > Date: Mon, 9 Aug 2010 23:00:49 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; m3 at sol42.com > Subject: Re: [M3devel] more Hudson nodes? more help in general? > > Hi all: > well in that case it would be probably less efficient to have running over and over probably if you are brave enough to virtualize it might be possible to load a good server with some virtual machines which later you can teleport like Vbox over a net and run for testing of the concept like you say twice a week. Tere is one in aprticular probably useful for the Irix the SimOS, which run natevely in the IRIX and others now, also other platforms like DEC Alpha and power PC. > I have downloaded an article from computer world library so you can check for details in the efficient virtualization affairs, it requires sign up to grab it (see http://www.vision6.com.au/ch/21104/2d34n3v/1289505/1b836s789.html ) so you can have it from here (just accept secure certificate and agree to add an exception): > https://168.176.86.16/~danielb/Virtualization_APC.pdf > As for the JVM you can have Loongson JVM for free ( http://debian.printk.org/software-loongson/jvm/jdk15_mips_080103.tar.gz ) in those machines to do the JVM part of the job, though not sure if hat works for your needs and available resources and system implementation. > > Thanks in advance > > > --- El lun, 9/8/10, m3 at sol42.com escribi?: > > > De: m3 at sol42.com > > Asunto: Re: [M3devel] more Hudson nodes? more help in general? > > Para: "m3devel" > > Fecha: lunes, 9 de agosto, 2010 15:17 > > Hello. I know we are talking > > about machines that would be running 24/7, but maybe is > > there a way for a machine to automatically join a Hudson > > server and do some work when it is booted say twice a week > > (which I concede is the opposite of continuous > > integration)? > > I have some machines that might be of help, but I don't do > > much with them nowadays and cannot afford to keep them up > > all the time: > > - mostly silent: a Mac mini G4, 1,5GHz, 1GB RAM, Mac OS X > > 10.5.8; > > - somewhat noisy: a Sun Ultra 60, 2*450 MHz, 2GB RAM, > > Solaris 10 from some time before Oracle changed Solaris > > terms (meaning it won't be upgraded, but I keep the JDK > > current); > > - like having an airport inside the room: an IRIX machine > > Hudson will not run on due to lack of a 1.5 JRE :( but if I > > keep it on in winter then I can turn off heating. > > Regards. > > -Daniel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Aug 10 07:54:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 10 Aug 2010 07:54:30 +0200 Subject: [M3devel] assembler problems on Solaris 9 Message-ID: <20100810075430.u41viro3q8ksckcw@mail.elegosoft.com> example: assembler failed assembling: RTHeapMap.ms /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: unknown opcode ".hidden" /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: statement syntax assemble => 1 see http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/20/console 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 dam at opencsw.org Tue Aug 10 09:34:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 10 Aug 2010 09:34:23 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> Message-ID: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Hi Olaf, Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > Quoting Dagobert Michelsen : >> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>> Currently I know of two other problems running our builds and tests >>> on the opencsw machines. >>> >>> 1. cvs update does not work on current10x (Solaris on x86) when >>> run from >>> Hudson. >>> It does work on current10s and current9s. >> >> Interesting. current*s are all running on the same physical machine >> as zones, >> whereas current*x are located on a vSphere farm. Do you have a >> specific >> command sequence which I can try to reproduce the problem? > > I'm not yet able to reproduce it manually; I only see it in the > Hudson jobs (failing right away when computing the changelog). > > If you want, I can setup a job for test purposes and you can get > Hudson access. I can't promise I can fix this but if you set something up I may look in the next few days. >> Are you using cvs stable (1.11.23) or feature (1.12.13)? > > Stable. I'll try with 1.12.13, too (haven't seen that around). > Is it installed anywhere?? That is here: /opt/csw/cvs-feature/bin/cvs Best regards -- Dago From wagner at elegosoft.com Tue Aug 10 13:43:49 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 10 Aug 2010 13:43:49 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Message-ID: <20100810134349.5votgjcz48408sow@mail.elegosoft.com> Quoting Dagobert Michelsen : > Hi Olaf, > > Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> Quoting Dagobert Michelsen : >>> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>>> Currently I know of two other problems running our builds and tests >>>> on the opencsw machines. >>>> >>>> 1. cvs update does not work on current10x (Solaris on x86) when run from >>>> Hudson. >>>> It does work on current10s and current9s. >>> >>> Interesting. current*s are all running on the same physical >>> machine as zones, >>> whereas current*x are located on a vSphere farm. Do you have a specific >>> command sequence which I can try to reproduce the problem? >> >> I'm not yet able to reproduce it manually; I only see it in the >> Hudson jobs (failing right away when computing the changelog). >> >> If you want, I can setup a job for test purposes and you can get >> Hudson access. > > I can't promise I can fix this but if you set something up I may look > in the next few days. I finally managed to reproduce the problem in the build step of a Hudson job, and got this after enabling tracing: -> rename(CVS/Entries.Backup,CVS/Entries) -> unlink_file(CVS/Entries.Log) cvs update: inflate: unknown compression method cvs [update aborted]: reading from server: I/O error -> Lock_Cleanup() Finished: FAILURE Is there a different/an older gzip library on current10x? see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >>> Are you using cvs stable (1.11.23) or feature (1.12.13)? >> >> Stable. I'll try with 1.12.13, too (haven't seen that around). >> Is it installed anywhere?? > > That is here: > /opt/csw/cvs-feature/bin/cvs Will it help if I try that, or does it use the same gzip lib? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 10 15:33:04 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 10 Aug 2010 15:33:04 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100810134349.5votgjcz48408sow@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> <20100810134349.5votgjcz48408sow@mail.elegosoft.com> Message-ID: <20100810153304.06vsgq848wcow0ok@mail.elegosoft.com> Quoting Olaf Wagner : > Quoting Dagobert Michelsen : > >> Hi Olaf, >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >>> Quoting Dagobert Michelsen : >>>> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>>>> Currently I know of two other problems running our builds and tests >>>>> on the opencsw machines. >>>>> >>>>> 1. cvs update does not work on current10x (Solaris on x86) when run from >>>>> Hudson. >>>>> It does work on current10s and current9s. >>>> >>>> Interesting. current*s are all running on the same physical >>>> machine as zones, >>>> whereas current*x are located on a vSphere farm. Do you have a specific >>>> command sequence which I can try to reproduce the problem? >>> >>> I'm not yet able to reproduce it manually; I only see it in the >>> Hudson jobs (failing right away when computing the changelog). >>> >>> If you want, I can setup a job for test purposes and you can get >>> Hudson access. >> >> I can't promise I can fix this but if you set something up I may look >> in the next few days. > > I finally managed to reproduce the problem in the build step of > a Hudson job, and got this after enabling tracing: > > -> rename(CVS/Entries.Backup,CVS/Entries) > -> unlink_file(CVS/Entries.Log) > cvs update: inflate: unknown compression method > cvs [update aborted]: reading from server: I/O error > -> Lock_Cleanup() > Finished: FAILURE > > Is there a different/an older gzip library on current10x? > > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >>>> Are you using cvs stable (1.11.23) or feature (1.12.13)? >>> >>> Stable. I'll try with 1.12.13, too (haven't seen that around). >>> Is it installed anywhere?? >> >> That is here: >> /opt/csw/cvs-feature/bin/cvs 1.12.13 says cvs update: inflate: invalid distance too far back cvs [update aborted]: reading from server: I/O error Finished: FAILURE Any ideas? 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 dabenavidesd at yahoo.es Tue Aug 10 23:04:39 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 10 Aug 2010 21:04:39 +0000 (GMT) Subject: [M3devel] assembler problems on Solaris 9 In-Reply-To: <20100810075430.u41viro3q8ksckcw@mail.elegosoft.com> Message-ID: <755920.39660.qm@web29709.mail.ird.yahoo.com> Hi all: not sure what the message meant but it seems like the code generator is broken putting labels in assembly code body. What is the assembler's version number, if it is natively generated (self-hosted not cross-assembled even from a previous other m3cg cross-assembler), assuming so, where are supposed to be placed labels to match system's assembly? Probably useful to print m3-sys/m3cgcat comparing with repository working correspondent and/or m3-tools/hexdump. Though compiler is enabled to do such a cross assembly process I wonder how that might be the result of compiling it with a different m3cg if that fails too, it might be a problem in the assembly emitting, what do you think? Thanks in advance --- El mar, 10/8/10, Olaf Wagner escribi?: > De: Olaf Wagner > Asunto: [M3devel] assembler problems on Solaris 9 > Para: m3devel at elegosoft.com > Fecha: martes, 10 de agosto, 2010 00:54 > example: > > assembler failed assembling: RTHeapMap.ms > /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: unknown > opcode ".hidden" > /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: > statement syntax > assemble => 1 > > see http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/20/console > > 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 dabenavidesd at yahoo.es Tue Aug 10 23:54:47 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 10 Aug 2010 21:54:47 +0000 (GMT) Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100810153304.06vsgq848wcow0ok@mail.elegosoft.com> Message-ID: <542991.69565.qm@web29701.mail.ird.yahoo.com> Hi all: I was rethinking but it seems you caught a bug either inside opencsw.org or elego system (incompatible versions). Probably will be a lot easier with some special techniques like this ones I assume you're not able to do that but just in case you do sshfs: http://www.linux-mag.com/id/7820 How critical is this process for it? see suggestions for it see pages 34 and 42 about centralizing control over files in contrast of distributed and the efficiency in I/O transmission and suggestions for improving it in a white "paper" book of "The Shortcut guide to Eliminating Insecure and Unreliable File Transfer Methods" if that might help (again just accept the security domain error and add the security exception) https://168.176.86.16/~danielb/SGEIU-complete.pdf downloaded from http://nexus.realtimepublishers.com/sgeiu.php you will need an account and take a survey on the topic if you might In such a case where you are allowed sshfs might be an interesting option it requires user space file system but if the performance is not critical perhaps we can think about it, can we, might be interesting for a windows setting, etc? Thanks in advance, hope it helps --- El mar, 10/8/10, Olaf Wagner escribi?: > De: Olaf Wagner > Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > Para: m3devel at elegosoft.com > Fecha: martes, 10 de agosto, 2010 08:33 > Quoting Olaf Wagner : > > > Quoting Dagobert Michelsen : > > > >> Hi Olaf, > >> > >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >>> Quoting Dagobert Michelsen : > >>>> Am 09.08.2010 um 10:21 schrieb Olaf > Wagner: > >>>>> Currently I know of two other problems > running our builds and tests > >>>>> on the opencsw machines. > >>>>> > >>>>> 1. cvs update does not work on > current10x (Solaris on x86) when run from > >>>>> Hudson. > >>>>> It does work on current10s and > current9s. > >>>> > >>>> Interesting. current*s are all running on > the same physical > >>>> machine as zones, > >>>> whereas current*x are located on a vSphere > farm. Do you have a specific > >>>> command sequence which I can try to > reproduce the problem? > >>> > >>> I'm not yet able to reproduce it manually; I > only see it in the > >>> Hudson jobs (failing right away when computing > the changelog). > >>> > >>> If you want, I can setup a job for test > purposes and you can get > >>> Hudson access. > >> > >> I can't promise I can fix this but if you set > something up I may look > >> in the next few days. > > > > I finally managed to reproduce the problem in the > build step of > > a Hudson job, and got this after enabling tracing: > > > > -> rename(CVS/Entries.Backup,CVS/Entries) > > -> unlink_file(CVS/Entries.Log) > > cvs update: inflate: unknown compression method > > cvs [update aborted]: reading from server: I/O error > > -> Lock_Cleanup() > > Finished: FAILURE > > > > Is there a different/an older gzip library on > current10x? > > > > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > > > >>>> Are you using cvs stable (1.11.23) or > feature (1.12.13)? > >>> > >>> Stable. I'll try with 1.12.13, too (haven't > seen that around). > >>> Is it installed anywhere?? > >> > >> That is here: > >> /opt/csw/cvs-feature/bin/cvs > > 1.12.13 says > > cvs update: inflate: invalid distance too far back cvs > [update > aborted]: reading from server: I/O error > Finished: FAILURE > > Any ideas? > > 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 Wed Aug 11 09:18:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 11 Aug 2010 09:18:38 +0200 Subject: [M3devel] assembler problems on Solaris 9 In-Reply-To: <755920.39660.qm@web29709.mail.ird.yahoo.com> References: <755920.39660.qm@web29709.mail.ird.yahoo.com> Message-ID: <20100811091838.u9g8wp7oso404cso@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > not sure what the message meant but it seems like the code generator > is broken putting labels in assembly code body. What is the > assembler's version number, if it is natively generated (self-hosted > not cross-assembled even from a previous other m3cg > cross-assembler), assuming so, where are supposed to be placed > labels to match system's assembly? Probably useful to print > m3-sys/m3cgcat comparing with repository working correspondent > and/or m3-tools/hexdump. Though compiler is enabled to do such a > cross assembly process I wonder how that might be the result of > compiling it with a different m3cg if that fails too, it might be a > problem in the assembly emitting, what do you think? It seems to be an incompatibility with the Solaris 9 assembler. The Solaris 10 assembler works fine. We haven't built the system on Solaris 9 for a long time I think. Or have we? Perhaps this is gcc 4.5 related? No, it's using 4.3, but in two different setups: WI=/home/m3hudson/current9s/work/cm3-inst/current9s/solsun + /home/m3hudson/current9s/work/cm3-inst/current9s/solsun/current/bin/cm3cg --version Modula-3 backend (GCC) version 4.3.5 (sparc-sun-solaris2.10) compiled by GNU C version 4.2.0 (gccfss), GMP version 4.2.1, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 + /home/m3hudson/current9s/work/cm3-inst/current9s/solsun/last-ok/bin/cm3cg --version Modula-3 backend (GCC) version 4.3.0 (sparc-sun-solaris2) compiled by GNU C version 3.4.3 (csl-sol210-3_4-branch+sol_rpath), GMP version 4.2.1, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 I guess our current configuration in m3cc/src/m3makefile is wrong for Solaris 9, or that gcc target was broken in the upgrade from 4.3.0 to 4.3.5. Olaf > Thanks in advance > > --- El mar, 10/8/10, Olaf Wagner escribi?: > >> De: Olaf Wagner >> Asunto: [M3devel] assembler problems on Solaris 9 >> Para: m3devel at elegosoft.com >> Fecha: martes, 10 de agosto, 2010 00:54 >> example: >> >> assembler failed assembling: RTHeapMap.ms >> /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: unknown >> opcode ".hidden" >> /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: >> statement syntax >> assemble => 1 >> >> see >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/20/console >> >> 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 >> >> > > > > -- 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 Wed Aug 11 09:26:35 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 11 Aug 2010 09:26:35 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <542991.69565.qm@web29701.mail.ird.yahoo.com> References: <542991.69565.qm@web29701.mail.ird.yahoo.com> Message-ID: <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > I was rethinking but it seems you caught a bug either inside > opencsw.org or elego system (incompatible versions). There are no incompatible CVS versions. Birch is running 1.12.13, and current9s.opencsw.org is running both that and 1.11.23. Should all work fine theoretically. It may be a problem with the proxy we need to use to get out from opencsw.org, too. Olaf PS: I don't think cool user space file systems from Linux will help us on Solaris systems, nor will opencsw.org change their general setup and policies for us. > Probably will be a lot easier with some special techniques like this ones > I assume you're not able to do that but just in case you do sshfs: > http://www.linux-mag.com/id/7820 > How critical is this process for it? see suggestions for it see > pages 34 and 42 about centralizing control over files in contrast of > distributed and the efficiency in I/O transmission and suggestions > for improving it in a white "paper" book of "The Shortcut guide to > Eliminating Insecure > and Unreliable File Transfer Methods" if that might help (again just > accept the security domain error and add the security exception) > https://168.176.86.16/~danielb/SGEIU-complete.pdf > downloaded from > http://nexus.realtimepublishers.com/sgeiu.php > you will need an account and take a survey on the topic if you might > In such a case where you are allowed sshfs might be an interesting > option it requires user space file system but if the performance is > not critical perhaps we can think about it, can we, might be > interesting for a windows setting, etc? > > Thanks in advance, hope it helps > > --- El mar, 10/8/10, Olaf Wagner escribi?: > >> De: Olaf Wagner >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing >> on opencsw.org machines >> Para: m3devel at elegosoft.com >> Fecha: martes, 10 de agosto, 2010 08:33 >> Quoting Olaf Wagner : >> >> > Quoting Dagobert Michelsen : >> > >> >> Hi Olaf, >> >> >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> >>> Quoting Dagobert Michelsen : >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf >> Wagner: >> >>>>> Currently I know of two other problems >> running our builds and tests >> >>>>> on the opencsw machines. >> >>>>> >> >>>>> 1. cvs update does not work on >> current10x (Solaris on x86) when run from >> >>>>> Hudson. >> >>>>> It does work on current10s and >> current9s. >> >>>> >> >>>> Interesting. current*s are all running on >> the same physical >> >>>> machine as zones, >> >>>> whereas current*x are located on a vSphere >> farm. Do you have a specific >> >>>> command sequence which I can try to >> reproduce the problem? >> >>> >> >>> I'm not yet able to reproduce it manually; I >> only see it in the >> >>> Hudson jobs (failing right away when computing >> the changelog). >> >>> >> >>> If you want, I can setup a job for test >> purposes and you can get >> >>> Hudson access. >> >> >> >> I can't promise I can fix this but if you set >> something up I may look >> >> in the next few days. >> > >> > I finally managed to reproduce the problem in the >> build step of >> > a Hudson job, and got this after enabling tracing: >> > >> > -> rename(CVS/Entries.Backup,CVS/Entries) >> > -> unlink_file(CVS/Entries.Log) >> > cvs update: inflate: unknown compression method >> > cvs [update aborted]: reading from server: I/O error >> > -> Lock_Cleanup() >> > Finished: FAILURE >> > >> > Is there a different/an older gzip library on >> current10x? >> > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >> > >> >>>> Are you using cvs stable (1.11.23) or >> feature (1.12.13)? >> >>> >> >>> Stable. I'll try with 1.12.13, too (haven't >> seen that around). >> >>> Is it installed anywhere?? >> >> >> >> That is here: >> >> /opt/csw/cvs-feature/bin/cvs >> >> 1.12.13 says >> >> cvs update: inflate: invalid distance too far back cvs >> [update >> aborted]: reading from server: I/O error >> Finished: FAILURE >> >> Any ideas? >> >> 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 >> >> > > > > -- 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 Wed Aug 11 18:10:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 11 Aug 2010 16:10:24 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> Message-ID: Olaf I think we should do a bit more research here, but I also think we have a few easy options. - build our own cvs, put it in $HOME/bin. - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. - Jay > Date: Wed, 11 Aug 2010 09:26:35 +0200 > From: wagner at elegosoft.com > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting "Daniel Alejandro Benavides D." : > > > Hi all: > > I was rethinking but it seems you caught a bug either inside > > opencsw.org or elego system (incompatible versions). > > There are no incompatible CVS versions. Birch is running 1.12.13, > and current9s.opencsw.org is running both that and 1.11.23. Should > all work fine theoretically. > > It may be a problem with the proxy we need to use to get out from > opencsw.org, too. > > Olaf > > PS: I don't think cool user space file systems from Linux will help > us on Solaris systems, nor will opencsw.org change their general > setup and policies for us. > > > Probably will be a lot easier with some special techniques like this ones > > I assume you're not able to do that but just in case you do sshfs: > > http://www.linux-mag.com/id/7820 > > How critical is this process for it? see suggestions for it see > > pages 34 and 42 about centralizing control over files in contrast of > > distributed and the efficiency in I/O transmission and suggestions > > for improving it in a white "paper" book of "The Shortcut guide to > > Eliminating Insecure > > and Unreliable File Transfer Methods" if that might help (again just > > accept the security domain error and add the security exception) > > https://168.176.86.16/~danielb/SGEIU-complete.pdf > > downloaded from > > http://nexus.realtimepublishers.com/sgeiu.php > > you will need an account and take a survey on the topic if you might > > In such a case where you are allowed sshfs might be an interesting > > option it requires user space file system but if the performance is > > not critical perhaps we can think about it, can we, might be > > interesting for a windows setting, etc? > > > > Thanks in advance, hope it helps > > > > --- El mar, 10/8/10, Olaf Wagner escribi?: > > > >> De: Olaf Wagner > >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> Para: m3devel at elegosoft.com > >> Fecha: martes, 10 de agosto, 2010 08:33 > >> Quoting Olaf Wagner : > >> > >> > Quoting Dagobert Michelsen : > >> > > >> >> Hi Olaf, > >> >> > >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >> >>> Quoting Dagobert Michelsen : > >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf > >> Wagner: > >> >>>>> Currently I know of two other problems > >> running our builds and tests > >> >>>>> on the opencsw machines. > >> >>>>> > >> >>>>> 1. cvs update does not work on > >> current10x (Solaris on x86) when run from > >> >>>>> Hudson. > >> >>>>> It does work on current10s and > >> current9s. > >> >>>> > >> >>>> Interesting. current*s are all running on > >> the same physical > >> >>>> machine as zones, > >> >>>> whereas current*x are located on a vSphere > >> farm. Do you have a specific > >> >>>> command sequence which I can try to > >> reproduce the problem? > >> >>> > >> >>> I'm not yet able to reproduce it manually; I > >> only see it in the > >> >>> Hudson jobs (failing right away when computing > >> the changelog). > >> >>> > >> >>> If you want, I can setup a job for test > >> purposes and you can get > >> >>> Hudson access. > >> >> > >> >> I can't promise I can fix this but if you set > >> something up I may look > >> >> in the next few days. > >> > > >> > I finally managed to reproduce the problem in the > >> build step of > >> > a Hudson job, and got this after enabling tracing: > >> > > >> > -> rename(CVS/Entries.Backup,CVS/Entries) > >> > -> unlink_file(CVS/Entries.Log) > >> > cvs update: inflate: unknown compression method > >> > cvs [update aborted]: reading from server: I/O error > >> > -> Lock_Cleanup() > >> > Finished: FAILURE > >> > > >> > Is there a different/an older gzip library on > >> current10x? > >> > > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >> > > >> >>>> Are you using cvs stable (1.11.23) or > >> feature (1.12.13)? > >> >>> > >> >>> Stable. I'll try with 1.12.13, too (haven't > >> seen that around). > >> >>> Is it installed anywhere?? > >> >> > >> >> That is here: > >> >> /opt/csw/cvs-feature/bin/cvs > >> > >> 1.12.13 says > >> > >> cvs update: inflate: invalid distance too far back cvs > >> [update > >> aborted]: reading from server: I/O error > >> Finished: FAILURE > >> > >> Any ideas? > >> > >> 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 > >> > >> > > > > > > > > > > > > -- > 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 Thu Aug 12 01:42:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 11 Aug 2010 23:42:39 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, , <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com>, Message-ID: Hm, that this means by the way, I think, is the compressed data is not recognized as valid. e.g. it isn't -z3 being rejected, but the data from the server. Maybe the network is flaky and corrupting the data? That aside, I wonder if we could try -z1, -z2, -z4, -z5, etc. ay at xlin2:~/src/cvs-1.12.13/cvs-1.12.13$ grep "unknown compre" */* zlib/inflate.c: strm->msg = (char *)"unknown compression method"; zlib/inflate.c: strm->msg = (char *)"unknown compression method"; if (BITS(4) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } ... #ifdef GUNZIP case FLAGS: NEEDBITS(16); state->flags = (int)(hold); if ((state->flags & 0xff) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dabenavidesd at yahoo.es Date: Wed, 11 Aug 2010 16:10:24 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Olaf I think we should do a bit more research here, but I also think we have a few easy options. - build our own cvs, put it in $HOME/bin. - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. - Jay > Date: Wed, 11 Aug 2010 09:26:35 +0200 > From: wagner at elegosoft.com > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting "Daniel Alejandro Benavides D." : > > > Hi all: > > I was rethinking but it seems you caught a bug either inside > > opencsw.org or elego system (incompatible versions). > > There are no incompatible CVS versions. Birch is running 1.12.13, > and current9s.opencsw.org is running both that and 1.11.23. Should > all work fine theoretically. > > It may be a problem with the proxy we need to use to get out from > opencsw.org, too. > > Olaf > > PS: I don't think cool user space file systems from Linux will help > us on Solaris systems, nor will opencsw.org change their general > setup and policies for us. > > > Probably will be a lot easier with some special techniques like this ones > > I assume you're not able to do that but just in case you do sshfs: > > http://www.linux-mag.com/id/7820 > > How critical is this process for it? see suggestions for it see > > pages 34 and 42 about centralizing control over files in contrast of > > distributed and the efficiency in I/O transmission and suggestions > > for improving it in a white "paper" book of "The Shortcut guide to > > Eliminating Insecure > > and Unreliable File Transfer Methods" if that might help (again just > > accept the security domain error and add the security exception) > > https://168.176.86.16/~danielb/SGEIU-complete.pdf > > downloaded from > > http://nexus.realtimepublishers.com/sgeiu.php > > you will need an account and take a survey on the topic if you might > > In such a case where you are allowed sshfs might be an interesting > > option it requires user space file system but if the performance is > > not critical perhaps we can think about it, can we, might be > > interesting for a windows setting, etc? > > > > Thanks in advance, hope it helps > > > > --- El mar, 10/8/10, Olaf Wagner escribi?: > > > >> De: Olaf Wagner > >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> Para: m3devel at elegosoft.com > >> Fecha: martes, 10 de agosto, 2010 08:33 > >> Quoting Olaf Wagner : > >> > >> > Quoting Dagobert Michelsen : > >> > > >> >> Hi Olaf, > >> >> > >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >> >>> Quoting Dagobert Michelsen : > >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf > >> Wagner: > >> >>>>> Currently I know of two other problems > >> running our builds and tests > >> >>>>> on the opencsw machines. > >> >>>>> > >> >>>>> 1. cvs update does not work on > >> current10x (Solaris on x86) when run from > >> >>>>> Hudson. > >> >>>>> It does work on current10s and > >> current9s. > >> >>>> > >> >>>> Interesting. current*s are all running on > >> the same physical > >> >>>> machine as zones, > >> >>>> whereas current*x are located on a vSphere > >> farm. Do you have a specific > >> >>>> command sequence which I can try to > >> reproduce the problem? > >> >>> > >> >>> I'm not yet able to reproduce it manually; I > >> only see it in the > >> >>> Hudson jobs (failing right away when computing > >> the changelog). > >> >>> > >> >>> If you want, I can setup a job for test > >> purposes and you can get > >> >>> Hudson access. > >> >> > >> >> I can't promise I can fix this but if you set > >> something up I may look > >> >> in the next few days. > >> > > >> > I finally managed to reproduce the problem in the > >> build step of > >> > a Hudson job, and got this after enabling tracing: > >> > > >> > -> rename(CVS/Entries.Backup,CVS/Entries) > >> > -> unlink_file(CVS/Entries.Log) > >> > cvs update: inflate: unknown compression method > >> > cvs [update aborted]: reading from server: I/O error > >> > -> Lock_Cleanup() > >> > Finished: FAILURE > >> > > >> > Is there a different/an older gzip library on > >> current10x? > >> > > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >> > > >> >>>> Are you using cvs stable (1.11.23) or > >> feature (1.12.13)? > >> >>> > >> >>> Stable. I'll try with 1.12.13, too (haven't > >> seen that around). > >> >>> Is it installed anywhere?? > >> >> > >> >> That is here: > >> >> /opt/csw/cvs-feature/bin/cvs > >> > >> 1.12.13 says > >> > >> cvs update: inflate: invalid distance too far back cvs > >> [update > >> aborted]: reading from server: I/O error > >> Finished: FAILURE > >> > >> Any ideas? > >> > >> 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 > >> > >> > > > > > > > > > > > > -- > 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 Thu Aug 12 05:27:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 12 Aug 2010 03:27:14 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, , , <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com>, , , Message-ID: I propose this is the next thing to try: - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. thereby removing -z3 from any jobs on this node, leaving all the rest unchanged. I realize $HOME/bin might not be it, but like $HOME/$(uname -n)/bin or such. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dabenavidesd at yahoo.es Date: Wed, 11 Aug 2010 23:42:39 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Hm, that this means by the way, I think, is the compressed data is not recognized as valid. e.g. it isn't -z3 being rejected, but the data from the server. Maybe the network is flaky and corrupting the data? That aside, I wonder if we could try -z1, -z2, -z4, -z5, etc. ay at xlin2:~/src/cvs-1.12.13/cvs-1.12.13$ grep "unknown compre" */* zlib/inflate.c: strm->msg = (char *)"unknown compression method"; zlib/inflate.c: strm->msg = (char *)"unknown compression method"; if (BITS(4) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } ... #ifdef GUNZIP case FLAGS: NEEDBITS(16); state->flags = (int)(hold); if ((state->flags & 0xff) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dabenavidesd at yahoo.es Date: Wed, 11 Aug 2010 16:10:24 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Olaf I think we should do a bit more research here, but I also think we have a few easy options. - build our own cvs, put it in $HOME/bin. - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. - Jay > Date: Wed, 11 Aug 2010 09:26:35 +0200 > From: wagner at elegosoft.com > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting "Daniel Alejandro Benavides D." : > > > Hi all: > > I was rethinking but it seems you caught a bug either inside > > opencsw.org or elego system (incompatible versions). > > There are no incompatible CVS versions. Birch is running 1.12.13, > and current9s.opencsw.org is running both that and 1.11.23. Should > all work fine theoretically. > > It may be a problem with the proxy we need to use to get out from > opencsw.org, too. > > Olaf > > PS: I don't think cool user space file systems from Linux will help > us on Solaris systems, nor will opencsw.org change their general > setup and policies for us. > > > Probably will be a lot easier with some special techniques like this ones > > I assume you're not able to do that but just in case you do sshfs: > > http://www.linux-mag.com/id/7820 > > How critical is this process for it? see suggestions for it see > > pages 34 and 42 about centralizing control over files in contrast of > > distributed and the efficiency in I/O transmission and suggestions > > for improving it in a white "paper" book of "The Shortcut guide to > > Eliminating Insecure > > and Unreliable File Transfer Methods" if that might help (again just > > accept the security domain error and add the security exception) > > https://168.176.86.16/~danielb/SGEIU-complete.pdf > > downloaded from > > http://nexus.realtimepublishers.com/sgeiu.php > > you will need an account and take a survey on the topic if you might > > In such a case where you are allowed sshfs might be an interesting > > option it requires user space file system but if the performance is > > not critical perhaps we can think about it, can we, might be > > interesting for a windows setting, etc? > > > > Thanks in advance, hope it helps > > > > --- El mar, 10/8/10, Olaf Wagner escribi?: > > > >> De: Olaf Wagner > >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> Para: m3devel at elegosoft.com > >> Fecha: martes, 10 de agosto, 2010 08:33 > >> Quoting Olaf Wagner : > >> > >> > Quoting Dagobert Michelsen : > >> > > >> >> Hi Olaf, > >> >> > >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >> >>> Quoting Dagobert Michelsen : > >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf > >> Wagner: > >> >>>>> Currently I know of two other problems > >> running our builds and tests > >> >>>>> on the opencsw machines. > >> >>>>> > >> >>>>> 1. cvs update does not work on > >> current10x (Solaris on x86) when run from > >> >>>>> Hudson. > >> >>>>> It does work on current10s and > >> current9s. > >> >>>> > >> >>>> Interesting. current*s are all running on > >> the same physical > >> >>>> machine as zones, > >> >>>> whereas current*x are located on a vSphere > >> farm. Do you have a specific > >> >>>> command sequence which I can try to > >> reproduce the problem? > >> >>> > >> >>> I'm not yet able to reproduce it manually; I > >> only see it in the > >> >>> Hudson jobs (failing right away when computing > >> the changelog). > >> >>> > >> >>> If you want, I can setup a job for test > >> purposes and you can get > >> >>> Hudson access. > >> >> > >> >> I can't promise I can fix this but if you set > >> something up I may look > >> >> in the next few days. > >> > > >> > I finally managed to reproduce the problem in the > >> build step of > >> > a Hudson job, and got this after enabling tracing: > >> > > >> > -> rename(CVS/Entries.Backup,CVS/Entries) > >> > -> unlink_file(CVS/Entries.Log) > >> > cvs update: inflate: unknown compression method > >> > cvs [update aborted]: reading from server: I/O error > >> > -> Lock_Cleanup() > >> > Finished: FAILURE > >> > > >> > Is there a different/an older gzip library on > >> current10x? > >> > > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >> > > >> >>>> Are you using cvs stable (1.11.23) or > >> feature (1.12.13)? > >> >>> > >> >>> Stable. I'll try with 1.12.13, too (haven't > >> seen that around). > >> >>> Is it installed anywhere?? > >> >> > >> >> That is here: > >> >> /opt/csw/cvs-feature/bin/cvs > >> > >> 1.12.13 says > >> > >> cvs update: inflate: invalid distance too far back cvs > >> [update > >> aborted]: reading from server: I/O error > >> Finished: FAILURE > >> > >> Any ideas? > >> > >> 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 > >> > >> > > > > > > > > > > > > -- > 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 wagner at elegosoft.com Thu Aug 12 09:12:07 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 09:12:07 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> Message-ID: <20100812091207.piy2cdcsiswoowg4@mail.elegosoft.com> Quoting Jay K : > Olaf I think we should do a bit more research here, but I also think > we have a few easy options. > > - build our own cvs, put it in $HOME/bin. > - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin > - drop in a stub cvs in $HOME/bin that remove the -z option and > then execs the "real" cvs, like how > we convince Hudson that our java -version is ok. These are not really easy, as we need to make Hudson running in the Winstone container started by ssh pick up the correct CVS. We don't want to start it explicitly in our jobs. But of course it can be done, I just haven't found the time to try. BTW, it is not evident that our self-built CVS would work better, especially, if the problem is really in the compressen library. I won't have time to do much until the weekend. Olaf > - Jay > >> Date: Wed, 11 Aug 2010 09:26:35 +0200 >> From: wagner at elegosoft.com >> To: dabenavidesd at yahoo.es >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Short status of CM3 Hudson regression >> testing on opencsw.org machines >> >> Quoting "Daniel Alejandro Benavides D." : >> >> > Hi all: >> > I was rethinking but it seems you caught a bug either inside >> > opencsw.org or elego system (incompatible versions). >> >> There are no incompatible CVS versions. Birch is running 1.12.13, >> and current9s.opencsw.org is running both that and 1.11.23. Should >> all work fine theoretically. >> >> It may be a problem with the proxy we need to use to get out from >> opencsw.org, too. >> >> Olaf >> >> PS: I don't think cool user space file systems from Linux will help >> us on Solaris systems, nor will opencsw.org change their general >> setup and policies for us. >> >> > Probably will be a lot easier with some special techniques like this ones >> > I assume you're not able to do that but just in case you do sshfs: >> > http://www.linux-mag.com/id/7820 >> > How critical is this process for it? see suggestions for it see >> > pages 34 and 42 about centralizing control over files in contrast of >> > distributed and the efficiency in I/O transmission and suggestions >> > for improving it in a white "paper" book of "The Shortcut guide to >> > Eliminating Insecure >> > and Unreliable File Transfer Methods" if that might help (again just >> > accept the security domain error and add the security exception) >> > https://168.176.86.16/~danielb/SGEIU-complete.pdf >> > downloaded from >> > http://nexus.realtimepublishers.com/sgeiu.php >> > you will need an account and take a survey on the topic if you might >> > In such a case where you are allowed sshfs might be an interesting >> > option it requires user space file system but if the performance is >> > not critical perhaps we can think about it, can we, might be >> > interesting for a windows setting, etc? >> > >> > Thanks in advance, hope it helps >> > >> > --- El mar, 10/8/10, Olaf Wagner escribi?: >> > >> >> De: Olaf Wagner >> >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing >> >> on opencsw.org machines >> >> Para: m3devel at elegosoft.com >> >> Fecha: martes, 10 de agosto, 2010 08:33 >> >> Quoting Olaf Wagner : >> >> >> >> > Quoting Dagobert Michelsen : >> >> > >> >> >> Hi Olaf, >> >> >> >> >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> >> >>> Quoting Dagobert Michelsen : >> >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf >> >> Wagner: >> >> >>>>> Currently I know of two other problems >> >> running our builds and tests >> >> >>>>> on the opencsw machines. >> >> >>>>> >> >> >>>>> 1. cvs update does not work on >> >> current10x (Solaris on x86) when run from >> >> >>>>> Hudson. >> >> >>>>> It does work on current10s and >> >> current9s. >> >> >>>> >> >> >>>> Interesting. current*s are all running on >> >> the same physical >> >> >>>> machine as zones, >> >> >>>> whereas current*x are located on a vSphere >> >> farm. Do you have a specific >> >> >>>> command sequence which I can try to >> >> reproduce the problem? >> >> >>> >> >> >>> I'm not yet able to reproduce it manually; I >> >> only see it in the >> >> >>> Hudson jobs (failing right away when computing >> >> the changelog). >> >> >>> >> >> >>> If you want, I can setup a job for test >> >> purposes and you can get >> >> >>> Hudson access. >> >> >> >> >> >> I can't promise I can fix this but if you set >> >> something up I may look >> >> >> in the next few days. >> >> > >> >> > I finally managed to reproduce the problem in the >> >> build step of >> >> > a Hudson job, and got this after enabling tracing: >> >> > >> >> > -> rename(CVS/Entries.Backup,CVS/Entries) >> >> > -> unlink_file(CVS/Entries.Log) >> >> > cvs update: inflate: unknown compression method >> >> > cvs [update aborted]: reading from server: I/O error >> >> > -> Lock_Cleanup() >> >> > Finished: FAILURE >> >> > >> >> > Is there a different/an older gzip library on >> >> current10x? >> >> > >> >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console >> >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >> >> > >> >> >>>> Are you using cvs stable (1.11.23) or >> >> feature (1.12.13)? >> >> >>> >> >> >>> Stable. I'll try with 1.12.13, too (haven't >> >> seen that around). >> >> >>> Is it installed anywhere?? >> >> >> >> >> >> That is here: >> >> >> /opt/csw/cvs-feature/bin/cvs >> >> >> >> 1.12.13 says >> >> >> >> cvs update: inflate: invalid distance too far back cvs >> >> [update >> >> aborted]: reading from server: I/O error >> >> Finished: FAILURE >> >> >> >> Any ideas? >> >> >> >> 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 >> >> >> >> >> > >> > >> > >> > >> >> >> >> -- >> 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 >> > -- 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 Thu Aug 12 09:14:19 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 09:14:19 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, , <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com>, Message-ID: <20100812091419.etw0y1yngo0ccosg@mail.elegosoft.com> We can try anything from the command line or via a build step in a Hudson job, but the configuration options for CVS in Hudson are rather limited. At least at this level... Olaf Quoting Jay K : > Hm, that this means by the way, I think, is the compressed data is > not recognized as valid. e.g. it isn't -z3 being rejected, but the > data from the server. > Maybe the network is flaky and corrupting the data? > > That aside, I wonder if we could try -z1, -z2, -z4, -z5, etc. > > ay at xlin2:~/src/cvs-1.12.13/cvs-1.12.13$ grep "unknown compre" */* > zlib/inflate.c: strm->msg = (char *)"unknown > compression method"; > zlib/inflate.c: strm->msg = (char *)"unknown > compression method"; > > > if (BITS(4) != Z_DEFLATED) { > strm->msg = (char *)"unknown compression method"; > state->mode = BAD; > break; > } > ... > #ifdef GUNZIP > case FLAGS: > NEEDBITS(16); > state->flags = (int)(hold); > if ((state->flags & 0xff) != Z_DEFLATED) { > strm->msg = (char *)"unknown compression method"; > state->mode = BAD; > break; > } > > > > - Jay > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; dabenavidesd at yahoo.es > Date: Wed, 11 Aug 2010 16:10:24 +0000 > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing > on opencsw.org machines > > > > > > > > > Olaf I think we should do a bit more research here, but I also think > we have a few easy options. > > - build our own cvs, put it in $HOME/bin. > - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin > - drop in a stub cvs in $HOME/bin that remove the -z option and > then execs the "real" cvs, like how > we convince Hudson that our java -version is ok. > > - Jay > >> Date: Wed, 11 Aug 2010 09:26:35 +0200 >> From: wagner at elegosoft.com >> To: dabenavidesd at yahoo.es >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Short status of CM3 Hudson regression >> testing on opencsw.org machines >> >> Quoting "Daniel Alejandro Benavides D." : >> >> > Hi all: >> > I was rethinking but it seems you caught a bug either inside >> > opencsw.org or elego system (incompatible versions). >> >> There are no incompatible CVS versions. Birch is running 1.12.13, >> and current9s.opencsw.org is running both that and 1.11.23. Should >> all work fine theoretically. >> >> It may be a problem with the proxy we need to use to get out from >> opencsw.org, too. >> >> Olaf >> >> PS: I don't think cool user space file systems from Linux will help >> us on Solaris systems, nor will opencsw.org change their general >> setup and policies for us. >> >> > Probably will be a lot easier with some special techniques like this ones >> > I assume you're not able to do that but just in case you do sshfs: >> > http://www.linux-mag.com/id/7820 >> > How critical is this process for it? see suggestions for it see >> > pages 34 and 42 about centralizing control over files in contrast of >> > distributed and the efficiency in I/O transmission and suggestions >> > for improving it in a white "paper" book of "The Shortcut guide to >> > Eliminating Insecure >> > and Unreliable File Transfer Methods" if that might help (again just >> > accept the security domain error and add the security exception) >> > https://168.176.86.16/~danielb/SGEIU-complete.pdf >> > downloaded from >> > http://nexus.realtimepublishers.com/sgeiu.php >> > you will need an account and take a survey on the topic if you might >> > In such a case where you are allowed sshfs might be an interesting >> > option it requires user space file system but if the performance is >> > not critical perhaps we can think about it, can we, might be >> > interesting for a windows setting, etc? >> > >> > Thanks in advance, hope it helps >> > >> > --- El mar, 10/8/10, Olaf Wagner escribi?: >> > >> >> De: Olaf Wagner >> >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing >> >> on opencsw.org machines >> >> Para: m3devel at elegosoft.com >> >> Fecha: martes, 10 de agosto, 2010 08:33 >> >> Quoting Olaf Wagner : >> >> >> >> > Quoting Dagobert Michelsen : >> >> > >> >> >> Hi Olaf, >> >> >> >> >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> >> >>> Quoting Dagobert Michelsen : >> >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf >> >> Wagner: >> >> >>>>> Currently I know of two other problems >> >> running our builds and tests >> >> >>>>> on the opencsw machines. >> >> >>>>> >> >> >>>>> 1. cvs update does not work on >> >> current10x (Solaris on x86) when run from >> >> >>>>> Hudson. >> >> >>>>> It does work on current10s and >> >> current9s. >> >> >>>> >> >> >>>> Interesting. current*s are all running on >> >> the same physical >> >> >>>> machine as zones, >> >> >>>> whereas current*x are located on a vSphere >> >> farm. Do you have a specific >> >> >>>> command sequence which I can try to >> >> reproduce the problem? >> >> >>> >> >> >>> I'm not yet able to reproduce it manually; I >> >> only see it in the >> >> >>> Hudson jobs (failing right away when computing >> >> the changelog). >> >> >>> >> >> >>> If you want, I can setup a job for test >> >> purposes and you can get >> >> >>> Hudson access. >> >> >> >> >> >> I can't promise I can fix this but if you set >> >> something up I may look >> >> >> in the next few days. >> >> > >> >> > I finally managed to reproduce the problem in the >> >> build step of >> >> > a Hudson job, and got this after enabling tracing: >> >> > >> >> > -> rename(CVS/Entries.Backup,CVS/Entries) >> >> > -> unlink_file(CVS/Entries.Log) >> >> > cvs update: inflate: unknown compression method >> >> > cvs [update aborted]: reading from server: I/O error >> >> > -> Lock_Cleanup() >> >> > Finished: FAILURE >> >> > >> >> > Is there a different/an older gzip library on >> >> current10x? >> >> > >> >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console >> >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >> >> > >> >> >>>> Are you using cvs stable (1.11.23) or >> >> feature (1.12.13)? >> >> >>> >> >> >>> Stable. I'll try with 1.12.13, too (haven't >> >> seen that around). >> >> >>> Is it installed anywhere?? >> >> >> >> >> >> That is here: >> >> >> /opt/csw/cvs-feature/bin/cvs >> >> >> >> 1.12.13 says >> >> >> >> cvs update: inflate: invalid distance too far back cvs >> >> [update >> >> aborted]: reading from server: I/O error >> >> Finished: FAILURE >> >> >> >> Any ideas? >> >> >> >> 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 >> >> >> >> >> > >> > >> > >> > >> >> >> >> -- >> 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 >> > -- 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 Thu Aug 12 10:18:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 10:18:15 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <4DBBF376-84FE-4A02-81C8-347275B2BD62@baltic-online.de> References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> <4DBBF376-84FE-4A02-81C8-347275B2BD62@baltic-online.de> Message-ID: <20100812101815.s0tusa6ji8wwokw0@mail.elegosoft.com> Quoting Dagobert Michelsen : > Hi Jay, > > Am 11.08.2010 um 18:10 schrieb Jay K: >> Olaf I think we should do a bit more research here, but I also >> think we have a few easy options. >> >> - build our own cvs, put it in $HOME/bin. > > I doubt that it would make a difference as the installed OpenCSW package is > build pretty much standard: > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/cvs/trunk/Makefile > >> - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin > > They should be bit-identical as it is the same package installed on > all machines of the same arch. > >> - drop in a stub cvs in $HOME/bin that remove the -z option and >> then execs the "real" cvs, like how >> we convince Hudson that our java -version is ok. > > Have you tried cvs-feature? In contrast to the /opt/csw/bin/cvs it is > linked against > libz explicitly: > > current10x% ldd /opt/csw/bin/cvs > libgss.so.1 => /usr/lib/libgss.so.1 > libkrb5.so.3 => /opt/csw/lib/i386/libkrb5.so.3 > libgen.so.1 => /lib/libgen.so.1 > libk5crypto.so.3 => /opt/csw/lib/i386/libk5crypto.so.3 > libcrypto.so.0.9.8 => /opt/csw/lib/pentium_pro/ libcrypto.so.0.9.8 > libcom_err.so.3 => /opt/csw/lib/i386/libcom_err.so.3 > libxnet.so.1 => /lib/libxnet.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libc.so.1 => /lib/libc.so.1 > libcmd.so.1 => /lib/libcmd.so.1 > libresolv.so.2 => /lib/libresolv.so.2 > libsocket.so.1 => /lib/libsocket.so.1 > libkrb5support.so.0 => /opt/csw/lib/libkrb5support.so.0 > libdl.so.1 => /lib/libdl.so.1 > libmp.so.2 => /lib/libmp.so.2 > libmd.so.1 => /lib/libmd.so.1 > libscf.so.1 => /lib/libscf.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libm.so.2 => /lib/libm.so.2 > > current10x% ldd /opt/csw/cvs-feature/bin/cvs > librt.so.1 => /lib/librt.so.1 > libintl.so.3 => /opt/csw/lib/i386/libintl.so.3 > libiconv.so.2 => /opt/csw/lib/i386/libiconv.so.2 > libc.so.1 => /lib/libc.so.1 > libgssapi_krb5.so.2 => /opt/csw/lib/i386/libgssapi_krb5.so.2 > libkrb5.so.3 => /opt/csw/lib/i386/libkrb5.so.3 > libgen.so.1 => /lib/libgen.so.1 > libk5crypto.so.3 => /opt/csw/lib/i386/libk5crypto.so.3 > libcrypto.so.0.9.8 => /opt/csw/lib/pentium_pro/ libcrypto.so.0.9.8 > libcom_err.so.3 => /opt/csw/lib/i386/libcom_err.so.3 > libnsl.so.1 => /lib/libnsl.so.1 > libsocket.so.1 => /lib/libsocket.so.1 > libz.so => /opt/csw/lib/pentium_pro+mmx/libz.so > libpam.so.1 => /lib/libpam.so.1 > libaio.so.1 => /lib/libaio.so.1 > libmd.so.1 => /lib/libmd.so.1 > libkrb5support.so.0 => /opt/csw/lib/libkrb5support.so.0 > libresolv.so.2 => /lib/libresolv.so.2 > libdl.so.1 => /lib/libdl.so.1 > libmp.so.2 => /lib/libmp.so.2 > libscf.so.1 => /lib/libscf.so.1 > libcmd.so.1 => /lib/libcmd.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libm.so.2 => /lib/libm.so.2 Neither 1.11.23 nor the feature version 1.12.13 work, see http://hudson.modula3.com:8080/view/zzz/job/opencsw10x-test/28/console If there are any more executables to try, we can easily do that via that Hudson job. I'd tend to support the idea of making Hudson use a CVS wrapper which eliminates the -z flag for update for the time being, until we have a better solution. After all, updates should only be small compared to initial checkouts, which work even with compression. All very strange. 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 Thu Aug 12 12:32:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 12:32:23 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Message-ID: <20100812123223.gu47te0g0488gk4c@mail.elegosoft.com> FYI With this change from Jay http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/22/changes we got the first snapshot archive built on Solaris 2.9: http://www.modula3.com/cm3/snaps/cm3-bin-core-SOLsun-d5.9.0-sparc-sun-solaris2.9-2010-08-12-09-40-37.tgz Olaf PS: Tinderbox regression is completely broken currently though, but that must be related to the change of the development line from release branch to trunk as default again. Quoting Dagobert Michelsen : > Hi Olaf, > > Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> Quoting Dagobert Michelsen : >>> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>>> Currently I know of two other problems running our builds and tests >>>> on the opencsw machines. >>>> >>>> 1. cvs update does not work on current10x (Solaris on x86) when run from >>>> Hudson. >>>> It does work on current10s and current9s. >>> >>> Interesting. current*s are all running on the same physical >>> machine as zones, >>> whereas current*x are located on a vSphere farm. Do you have a specific >>> command sequence which I can try to reproduce the problem? >> >> I'm not yet able to reproduce it manually; I only see it in the >> Hudson jobs (failing right away when computing the changelog). >> >> If you want, I can setup a job for test purposes and you can get >> Hudson access. > > I can't promise I can fix this but if you set something up I may look > in the next few days. > >>> Are you using cvs stable (1.11.23) or feature (1.12.13)? >> >> Stable. I'll try with 1.12.13, too (haven't seen that around). >> Is it installed anywhere?? > > That is here: > /opt/csw/cvs-feature/bin/cvs > > > Best regards > > -- Dago -- 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 Thu Aug 12 15:36:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 15:36:42 +0200 Subject: [M3devel] Thread hangs on Solaris 2.9 Message-ID: <20100812153642.vpiofd7vvyssgks4@mail.elegosoft.com> There seems to be a rather extended LongPause in m3tests on Solaris 2.9: [...] --- p037 --- tests Time.LongPause cd ../src/p0/p037 && cm3 -silent -DM3TESTS >SOLsun/stdout.build.raw 2>SOLsun/stderr.build.raw [endless rotation icon here :-)] see http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-SOLsun-opencsw-current9s/8/console 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 Thu Aug 12 20:42:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 20:42:42 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Message-ID: <20100812204242.tk9wlc7f480skw8c@mail.elegosoft.com> I have done that now which seems to work: -bash-4.1$ cat ~/bin/cvs #!/bin/sh CVSEXE=/opt/csw/cvs-feature/bin/cvs if [ ! -x $CVSEXE ]; then CVSEXE=/opt/csw/bin/cvs fi if [ ! -x $CVSEXE ]; then echo "$CVSEXE not executable" 1>&2 exit 1 fi if [ `uname -n` = "current10x" ]; then args=`echo "$@" | sed -e 's/-z3 update/update/'` echo "$CVSEXE $args" exec $CVSEXE $args else echo "$CVSEXE $@" exec $CVSEXE $@ fi 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 Aug 12 23:32:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 12 Aug 2010 21:32:37 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100812204242.tk9wlc7f480skw8c@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com>, , <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com>, <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org>, <20100812204242.tk9wlc7f480skw8c@mail.elegosoft.com> Message-ID: Please check it in where I put the python/java wrapper, thanks. - Jay > Date: Thu, 12 Aug 2010 20:42:42 +0200 > From: wagner at elegosoft.com > To: dam at opencsw.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > I have done that now which seems to work: > > -bash-4.1$ cat ~/bin/cvs > #!/bin/sh > > CVSEXE=/opt/csw/cvs-feature/bin/cvs > > if [ ! -x $CVSEXE ]; then > CVSEXE=/opt/csw/bin/cvs > fi > if [ ! -x $CVSEXE ]; then > echo "$CVSEXE not executable" 1>&2 > exit 1 > fi > if [ `uname -n` = "current10x" ]; then > args=`echo "$@" | sed -e 's/-z3 update/update/'` > echo "$CVSEXE $args" > exec $CVSEXE $args > else > echo "$CVSEXE $@" > exec $CVSEXE $@ > fi > > 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 Sat Aug 14 00:59:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 13 Aug 2010 22:59:02 +0000 Subject: [M3devel] fs_rmrec In-Reply-To: <20100813220727.EAD51CC88D@birch.elegosoft.com> References: <20100813220727.EAD51CC88D@birch.elegosoft.com> Message-ID: Olaf, to be sure/clear -- fs_rmrec works now, right? The original and long-term problem was that deleting, or even, enumerating, stale symlinks would fail. There *may* have been a problem around keeping multiple DIRs open at a time and/or deleting while enumerating. My addressing the later concerns, and using fs_rmrec in m3-sys/m3cc, both exacerbated the problem due to the ordering of enumeration and deletion and the layout of m3-sys/m3cc. In either case, I believe it works now, right? Understood that old cm3 remains broken, and intermediate cm3 remains sort of worse. What I mean by all these "sort ofs" is that we used to enumerate and delete "at the same time". Which made it somewhat indeterminate if the symlink or its target was deleted first. I changed the code to delete files, and then directories. Given a symlink like "bar/foo => ../foo", ./foo would be guaranteeably deleted ahead of the symlink pointing to it. - Jay > Date: Sat, 14 Aug 2010 00:07:27 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 10/08/14 00:07:27 > > Modified files: > cm3/m3-sys/m3tests/src/: m3makefile > > Log message: > wrong again, another attempt: fix rmrec for NT386 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 14 13:10:07 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 14 Aug 2010 13:10:07 +0200 Subject: [M3devel] fs_rmrec In-Reply-To: References: <20100813220727.EAD51CC88D@birch.elegosoft.com> Message-ID: <20100814131007.520xyqx42ok0oo48@mail.elegosoft.com> Quoting Jay K : > Olaf, to be sure/clear -- fs_rmrec works now, right? I thought so, too, but... > The original and long-term problem was that deleting, or even, > enumerating, stale symlinks > would fail. There *may* have been a problem around keeping multiple > DIRs open at a time > and/or deleting while enumerating. My addressing the later concerns, > and using fs_rmrec > in m3-sys/m3cc, both exacerbated the problem due to the ordering of > enumeration and deletion > and the layout of m3-sys/m3cc. > > In either case, I believe it works now, right? I observed several failures in tests. Let's see if I can find some: Here is one: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-I386_SOLARIS-opencsw-current10x/11/console Perhaps the cm3 used there was still too old? I'm sure there were more, but I cannot find them right now. If you're sure it's fixed, we can try it again, no problem. What about the hanging test p037 on Solaris 2.9 though? See http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-SOLsun-opencsw-current9s/8/console Any ideas? Olaf > Understood that old cm3 remains broken, and intermediate cm3 remains > sort of worse. > > > What I mean by all these "sort ofs" is that we used to enumerate and > delete "at the same time". > Which made it somewhat indeterminate if the symlink or its target > was deleted first. > I changed the code to delete files, and then directories. > Given a symlink like "bar/foo => ../foo", ./foo would be > guaranteeably deleted ahead > of the symlink pointing to it. > > - 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 jay.krell at cornell.edu Sat Aug 14 20:51:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 14 Aug 2010 18:51:20 +0000 Subject: [M3devel] fs_rmrec In-Reply-To: <20100814131007.520xyqx42ok0oo48@mail.elegosoft.com> References: <20100813220727.EAD51CC88D@birch.elegosoft.com>, , <20100814131007.520xyqx42ok0oo48@mail.elegosoft.com> Message-ID: > What about the hanging test p037 on Solaris 2.9 though? Oops, right. Perhaps we don't use -lpthread and perhaps we need to. Or perhaps 2.9 uses M:N user:kernel threads and perhaps our code doesn't work with that. Needs some investigation. Tony do you know by chance if the semaphore "parking in signal handler" pthreads code has been used on pre-2.10 Solaris? - Jay > Date: Sat, 14 Aug 2010 13:10:07 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] fs_rmrec > > Quoting Jay K : > > > Olaf, to be sure/clear -- fs_rmrec works now, right? > > I thought so, too, but... > > > The original and long-term problem was that deleting, or even, > > enumerating, stale symlinks > > would fail. There *may* have been a problem around keeping multiple > > DIRs open at a time > > and/or deleting while enumerating. My addressing the later concerns, > > and using fs_rmrec > > in m3-sys/m3cc, both exacerbated the problem due to the ordering of > > enumeration and deletion > > and the layout of m3-sys/m3cc. > > > > In either case, I believe it works now, right? > > I observed several failures in tests. > Let's see if I can find some: > > Here is one: > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-I386_SOLARIS-opencsw-current10x/11/console > > Perhaps the cm3 used there was still too old? > I'm sure there were more, but I cannot find them right now. > > If you're sure it's fixed, we can try it again, no problem. > > What about the hanging test p037 on Solaris 2.9 though? > See > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-SOLsun-opencsw-current9s/8/console > > Any ideas? > > Olaf > > > Understood that old cm3 remains broken, and intermediate cm3 remains > > sort of worse. > > > > > > What I mean by all these "sort ofs" is that we used to enumerate and > > delete "at the same time". > > Which made it somewhat indeterminate if the symlink or its target > > was deleted first. > > I changed the code to delete files, and then directories. > > Given a symlink like "bar/foo => ../foo", ./foo would be > > guaranteeably deleted ahead > > of the symlink pointing to it. > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 15 08:53:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 15 Aug 2010 06:53:25 +0000 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: <7D2B9349-BCBA-46DE-8465-F50EEBB70F22@cs.purdue.edu> References: , <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu>, , <7D2B9349-BCBA-46DE-8465-F50EEBB70F22@cs.purdue.edu> Message-ID: [old, was going through mail for another reason] btw, treelang is gone in later gcc releases, e.g. 4.5. I think I read they didn't want to maintain it any longer. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 29 Jun 2009 12:01:16 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pruning m3cc/gcc? > > Please leave treelang. It is a good model for building gcc IR trees > as done by cm3cg. > > On 29 Jun 2009, at 10:42, Jay wrote: > > > > > Ok, presumably then ok to prune it just partly, like intl, libssp, > > libmudflap, libgomp, treelang, beyond that (fixincludes, libgcc) > > would require some checking/testing. Might even be worthwhile to > > "simplify" the m3makefile and reach a compromise that works only by > > some deletion. > > Really I wish somehow gmp/mpfr built more quickly. I often delete > > their source locally but can't commit that. > > > > - Jay > > > > ________________________________ > >> From: hosking at cs.purdue.edu > >> To: jay.krell at cornell.edu > >> Date: Mon, 29 Jun 2009 09:41:09 -0400 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] pruning m3cc/gcc? > >> > >> I personally like having the ability to build C from the same > >> source tree. It's useful for debugging the backend sometimes > >> (looking at the equivalent code generated from C). > >> > >> On 28 Jun 2009, at 23:38, Jay wrote: > >> > >> > >> I keep thinking of deleting > >> > >> m3-sys/m3cc/gcc/intl > >> m3-sys/m3cc/gcc/libgomp > >> m3-sys/m3cc/gcc/libmudflap > >> m3-sys/m3cc/gcc/libssp > >> m3-sys/m3cc/gcc/fixincludes > >> m3-sys/m3cc/gcc/libgcc > >> > >> > >> We don't use any of it. > >> Some of these deletions would shorten our build command lines. > >> Though some (esp. fixincludes and maybe libgcc) might break the > >> shortest configure + make that the "real" cm3 doesn't use but can > >> be useful. > >> > >> > >> I didn't include them in gcc-interix and gcc-apple. > >> > >> > >> But there are two possible contradictory goals: > >> > >> > >> - just have what we use/change > >> - have a complete merged gcc tree from which you > >> could build gcc/cc1 and not just cm3cg > >> Except we don't have C++, Java, Ada, Fortran, > >> so we don't really have this, but C probably counts for something. > >> > >> > >> If the second is the goal, don't delete. > >> If the first is the goal, delete. > >> > >> > >> There is also "having it all there in case it is needed > >> or somesuch", but that's easy enough to get elsewhere. > >> > >> > >> - Jay > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 15 05:31:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 15 Aug 2010 03:31:19 +0000 Subject: [M3devel] quake and/or "short circuit" Message-ID: It would have been nice for and/or to short circuit in quake like they do in C. Code like: if not defined("TARGET") readonly TARGET = "I386_FREEBSD" else if not equal(TARGET, "FreeBSD4") readonly TARGET = "I386_FREEBSD" end end is better written as: if not defined("TARGET") or not equal(TARGET, "FreeBSD4") readonly TARGET = "I386_FREEBSD" end but that isn't allowed because equal() will complain that TARGET isn't defined. It probably can't fixed though, due to e.g.: if TRUE or DoSomething() ... end would be broken. perhaps OR and AND or short_circuit_and or and_shorted or and_short_circuit or and_early_out or and_early or "&&" or something... Or I should just rewrite so much quake in Modula-3... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 16 09:55:04 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 16 Aug 2010 09:55:04 +0200 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: References: Message-ID: <20100816095504.29pg9d3dsgkwc00o@mail.elegosoft.com> You talk about `conditional and' and `conditional or'... I thought we had that in quake like in M3, but I might be mistaken. It should not be difficult to implement that though. Using it will be difficult until we've had a release which contains it... Olaf Quoting Jay K : > It would have been nice for and/or to short circuit in quake like > they do in C. > > > Code like: > > if not defined("TARGET") > readonly TARGET = "I386_FREEBSD" > else > if not equal(TARGET, "FreeBSD4") > readonly TARGET = "I386_FREEBSD" > end > end > > > is better written as: > if not defined("TARGET") or not equal(TARGET, "FreeBSD4") > readonly TARGET = "I386_FREEBSD" > end > > but that isn't allowed because equal() will complain that TARGET > isn't defined. > > It probably can't fixed though, due to e.g.: > > if TRUE or DoSomething() > ... > end > > > would be broken. > > > perhaps > OR and AND > or short_circuit_and > or and_shorted > or and_short_circuit > or and_early_out > or and_early > or "&&" > or something... > > > Or I should just rewrite so much quake in Modula-3... > > > - 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 jay.krell at cornell.edu Tue Aug 17 21:02:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 19:02:06 +0000 Subject: [M3devel] coverage of -O1, -O2, -O3, etc.? Message-ID: Anyone have ideas on getting coverage of various switches? Lately I use -O3 -Wuninitialized always. But that isn't exhaustive and doesn't get coverage in Hudson. And it isn't cheap for me. The "old" way was that I never used any optimization. I'm very likely paying more time to run the optimizer than that the optimizer saves. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 17 22:44:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 20:44:19 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: ,,, , , ,,, , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu>, , , , , Message-ID: I forgot about this. I never resolved it. Things seem to work though. ? - Jay > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 06:38:05 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > > I don't know. There is so much unknown here. It is frustrating and difficult. > We could use an extensive set of test cases. > Or know more about the test cases we do have. > And it'd be nice to see if anything varies in the 4.3 path if we put the labels on that list or not. > > tangent: > > I'd like automation that compiles the whole system, multiple architectures, and puts all the *s files in one flat > directory per architecture. I guess it's just a matter of a little code. > It should just skip the few errors that are cross problems, which I should fix anyway. > That particular problem makes me a little nervous, but I suppose I can code it to use both INTEGER and Target.Int > if doing a native build, and assert that the results match. > I hit a snag yesterday, can't build any tests (just to assembly) without first shipping m3core/libm3. > Can't ship m3core/libm3 for cross building. > I guess, and I forgot this, I should have used -x for override. Duh. > That's why I tried I386_DARWIN for some current 4.5 problems vs. SOLgnu, to escape cross building. Oops. > > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Mon, 12 Jul 2010 09:43:01 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] barrier labels? > > > > Perhaps we just need FORCED_LABEL for these: > > > > /* In a LABEL_DECL, nonzero means this label had its address taken > > and therefore can never be deleted and is a jump target for > > computed gotos. */ > > > > > > On 11 Jul 2010, at 23:03, Jay K wrote: > > > > > > > > I still don't see it, in the C++ frontend. > > > > > > There is: > > > > > > void > > > expand_label (tree label) > > > { > > > ... > > > if (DECL_NONLOCAL (label)) > > > { > > > ... nonlocal_goto_handler_labels > > > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > > > nonlocal_goto_handler_labels); > > > } > > > > > > but I don't think this works until later. > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sun, 11 Jul 2010 20:52:25 -0400 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] barrier labels? > > >> > > >> No, that code came from 4.x... > > >> > > >> > > >> > > >> > > >> On 11 Jul 2010, at 19:41, Jay K wrote: > > >> > > >>> > > >>> Tony, thanks for the pointer..though I haven't been able to find it yet. > > >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > > >>> > > >>> - Jay > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 > > >>>> To: jay.krell at cornell.edu > > >>>> CC: m3devel at elegosoft.com > > >>>> Subject: Re: [M3devel] barrier labels? > > >>>> > > >>>> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > > >>>> > > >>>> On 11 Jul 2010, at 07:46, Jay K wrote: > > >>>> > > >>>>> > > >>>>> Tony, six years ago you introduce what is now: > > >>>>> > > >>>>> > > >>>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > >>>>> > > >>>>> > > >>>>> static void > > >>>>> m3cg_set_label (void) > > >>>>> { > > >>>>> ... > > >>>>> if (barrier) > > >>>>> { > > >>>>> ... > > >>>>> { > > >>>>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > > >>>>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > > >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > > >>>>> } > > >>>>> ... > > >>>>> > > >>>>> > > >>>>> I'm not sure what to do here for gcc 4.5. > > >>>>> The data has moved around and isn't available this early. I suppose we could hang some information on and > > >>>>> deal with it later in compilation. > > >>>>> > > >>>>> > > >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > > >>>>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > > >>>>> > > >>>>> > > >>>>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > > >>>>> And Juno/mentor/tetris work without optimization, I'll test optimized later. > > >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. > > >>>>> > > >>>>> > > >>>>> Do we have good exception handling tests? > > >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > > >>>>> > > >>>>> > > >>>>> I'll poke around more.. > > >>>>> > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>> > > >>> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 17 22:47:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 20:47:36 +0000 Subject: [M3devel] gcc 4.5 In-Reply-To: References: Message-ID: This is moving along now. I've moved a few targets to 4.5.1 already. Some targets I haven't tested yet. Some have problems and I've held them back pending investigation. In some cases I compromise, e.g. turning off optimization on ALPHA_OSF. Eventually I might move some forward without testing. Generally I cross build, then self build, and startup some GUI apps. Though my X server is presently broken. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: gcc 4.5 > Date: Sun, 11 Jul 2010 23:51:43 +0000 > > > I'm inclined to make gcc 4.5 the default backend very soon. > AMD64_DARWIN, I386_LINUX, SOLgnu are looking ok. > I could also test PPC, like PPC_LINUX. > > SOLgnu leaves everything volatile (same as 4.3) so maybe isn't much validation. > > I doubt there is much value in testing other operating systems, mainly just other processors. > Though there is sometimes, e.g. I think I386_DARWIN uses sse for floating point and other I386 systems don't. > I should also test SPARC_LINUX to get sparc w/o volatile. > > > There are many other targets. OpenBSD, NetBSD, FreeBSD, OSF/1, I386/AMD64_SOLARIS, ARMEL_LINUX, Cygwin, MinGW, etc. > Others can test them? > > > There is some downside, in particular I disable more optimization at -O3 than with gcc 4.3. > One of the additional optimizations perhaps doesn't exist in 4.3 though. > > > The label/barrier thing still isn't resolved. > I haven't run through m3-sys/m3tests. > > > But that the system can build itself is a good sign, though sometimes I overvalue it. > And I tested some gui apps at least unoptimized. > The "man vs. boy" test works. > > > The 4.3 backend will remain available via cm3 -DGCC43 in the m3cc directory. > You have to be careful about cm3cfg.common probing around and finding the intended one, > such as by deleting all others. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 17 23:20:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 21:20:01 +0000 Subject: [M3devel] TimePosix__ComputeGrain Message-ID: I have now often seen cm3 hang starting up. Here: (gdb) bt #0 0x000003ff8010aed8 in gettimeofday64 () from /usr/shlib/libc.so #1 0x00000001205168a4 in TimePosix__Now () at ../src/time/POSIX/TimePosixC.c:41 #2 0x0000000120516924 in ComputeGrainOnce () at ../src/time/POSIX/TimePosixC.c:61 #3 0x0000000120516990 in TimePosix__ComputeGrain () at ../src/time/POSIX/TimePosixC.c:77 #4 0x00000001204ef344 in TimePosix_M3 ( M3_AcxOUs_mode=) at ../src/time/POSIX/TimePosix.m3:18 #5 0x00000001204c94f0 in RTLinker__RunMainBody ( I have adjusted the code to I believe guarantee forward progress. Some versions of mine did not. Ideas? Better portable ways to write it? It hangs a large fraction of the time on Alpha/OSF for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Aug 17 23:56:52 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 17 Aug 2010 23:56:52 +0200 Subject: [M3devel] [M3commit] "change outside commit" In-Reply-To: References: Message-ID: <20100817235652.tbbwe9lcnc44oggc@mail.elegosoft.com> Quoting Jay K : > same thing here: > > http://hudson.modula3.com:8080/job/cm3-current-build-I386_DARWIN/19/console > > - Jay > > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com > Date: Tue, 17 Aug 2010 20:40:37 +0000 > Subject: [M3commit] "change outside commit" > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-AMD64_DARWIN/6/console > > +"/Users/hudson/work/cm3-inst/jbook2/AMD64_DARWIN/last-ok/bin/config/Darwin.common", line 258: quake runtime error: undefined variable: > SYSTEM_CC > > To deal with that, I manually edited > /Users/hudson/work/cm3-inst/jbook2/AMD64_DARWIN/last-ok/bin/config/Darwin.common > to more closely resemble current source. > > I don't know if merely having commited fixes works here. It is OK for now to manually repair installations in ~/work/cm3-inst. Sometimes broken things get installed, though I've tried to improve the scripts; but some things are just too difficult to implement (wrt. atomicity and concurrency). The problem is that it takes too much time to investigate and understand each failure of a CM3 regression run. I can only do that now and then. I'll keep improving things 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 mika at async.async.caltech.edu Wed Aug 18 00:27:04 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 17 Aug 2010 15:27:04 -0700 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: References: Message-ID: <20100817222704.B3ABE1A209B@async.async.caltech.edu> If you really want it, you can always introduce "cand" and "cor" for the short-circuit versions. Dijkstra advises against it, though. Mika Jay K writes: >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >It would have been nice for and/or to short circuit in quake like they do i= >n C. > > >Code like: > >if not defined("TARGET") > readonly TARGET =3D "I386_FREEBSD" >else > if not equal(TARGET=2C "FreeBSD4") > readonly TARGET =3D "I386_FREEBSD" > end >end > > >is better written as: >if not defined("TARGET") or not equal(TARGET=2C "FreeBSD4") > readonly TARGET =3D "I386_FREEBSD" >end > >but that isn't allowed because equal() will complain that TARGET isn't defi= >ned. > >It probably can't fixed though=2C due to e.g.: > >if TRUE or DoSomething() > ... >end > > >would be broken. > > >perhaps >OR and AND >or short_circuit_and >or and_shorted >or and_short_circuit >or and_early_out >or and_early >or "&&" >or something... > > >Or I should just rewrite so much quake in Modula-3... > > > - Jay > = > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >It would have been nice for and/or to short circuit in quake like they do i= >n C.


Code like:

if not defined("TARGET")
 =3B read= >only TARGET =3D "I386_FREEBSD"
else
 =3B if not equal(TARGET=2C "= >FreeBSD4")
 =3B =3B =3B readonly TARGET =3D "I386_FREEBSD"r> =3B end
end


is better written as:
if not defined("T= >ARGET") or not equal(TARGET=2C "FreeBSD4")
 =3B readonly TARGET =3D = >"I386_FREEBSD"
end

but that isn't allowed because equal() will co= >mplain that TARGET isn't defined.

It probably can't fixed though=2C = >due to e.g.:

if TRUE or DoSomething()
 =3B ...
end

= >
would be broken.


perhaps
OR and AND
or short_circuit_a= >nd
or and_shorted
or and_short_circuit
or and_early_out
or and_= >early
or "&=3B&=3B"
or something...


Or I should just= > rewrite so much quake in Modula-3...


 =3B- Jay
> = > >= > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_-- From hendrik at topoi.pooq.com Wed Aug 18 01:59:01 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 17 Aug 2010 19:59:01 -0400 Subject: [M3devel] dbxout_static_chain_decl? In-Reply-To: <20100528220400.GB4904@topoi.pooq.com> References: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu> <4BFF15CE.7060908@lcwb.coop> <20100528220400.GB4904@topoi.pooq.com> Message-ID: <20100817235900.GB29080@topoi.pooq.com> On Fri, May 28, 2010 at 06:04:01PM -0400, hendrik at topoi.pooq.com wrote: > > In Algol 68, when it's implemented using static links, the static chain > doesn't thread *all* the chain of surrounding procedures -- it skips the > ones that don't define any names used in the inner ones. > > This bit of denesting might improve efficiency even in Modula 3, since > some static chains might end up being shorter. Whether it's worth the > effort is another question, of course. I should perhaps have mentioned that this behaviour is *required* by the Alcol 68 language definition. Not required by Modula 3, where what you can do with local procedures is more restricted. -- hendrik From jay.krell at cornell.edu Wed Aug 18 03:19:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 18 Aug 2010 01:19:48 +0000 Subject: [M3devel] FW: clock_getres / Time.Grain. In-Reply-To: <20100817213538.760482474033@birch.elegosoft.com> References: <20100817213538.760482474033@birch.elegosoft.com> Message-ID: This needs a review. Folks need to read Posix, the Modula-3 *.i3 files, possibly the OS man pages. Possibly run the two versions and compare. Possibly only #ifdef it in when the compare similar, e.g. on OSF and leave the rest alone. Possibly only use the timeofday timer and not the highres timer. Thanks, - Jay > Date: Tue, 17 Aug 2010 23:35:38 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/17 23:35:37 > > Modified files: > cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c > > Log message: > Let's try clock_getres if it is available. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Aug 18 03:17:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 18 Aug 2010 01:17:02 +0000 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: <20100817222704.B3ABE1A209B@async.async.caltech.edu> References: , <20100817222704.B3ABE1A209B@async.async.caltech.edu> Message-ID: I don't know what the names should be, I'm pretty comfortable with "&&" and "||". Short circuiting is very useful. > Dijkstra advises against it, though. That makes me question Dijkstra, not short circuiting. Also useful is assignment being an expression. I wish it was in Modula-3. Such things as: if ((f = fopen(..)) && fread(f,...) or if (p && *p) In the first case Modula-3 forces useless verbosity and indentation. In the second case Modula-3 gets it right but Quake fails. Lacking these features you end up contorting your code one way or another, such as duplicating things. I really can't stand code that looks like: result = do something if success(result) do more stuff if success do more stuff if succes do more stuff Modula-3 this wrong. Exceptions help. But basically I want to be able to introduce WITH or VAR anywhere, but not need to "END" them, and therefore no implied need for indentation.. - Jay > To: jay.krell at cornell.edu > Date: Tue, 17 Aug 2010 15:27:04 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] quake and/or "short circuit" > > If you really want it, you can always introduce "cand" and "cor" for > the short-circuit versions. > > Dijkstra advises against it, though. > > Mika > > Jay K writes: > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >It would have been nice for and/or to short circuit in quake like they do i= > >n C. > > > > > >Code like: > > > >if not defined("TARGET") > > readonly TARGET =3D "I386_FREEBSD" > >else > > if not equal(TARGET=2C "FreeBSD4") > > readonly TARGET =3D "I386_FREEBSD" > > end > >end > > > > > >is better written as: > >if not defined("TARGET") or not equal(TARGET=2C "FreeBSD4") > > readonly TARGET =3D "I386_FREEBSD" > >end > > > >but that isn't allowed because equal() will complain that TARGET isn't defi= > >ned. > > > >It probably can't fixed though=2C due to e.g.: > > > >if TRUE or DoSomething() > > ... > >end > > > > > >would be broken. > > > > > >perhaps > >OR and AND > >or short_circuit_and > >or and_shorted > >or and_short_circuit > >or and_early_out > >or and_early > >or "&&" > >or something... > > > > > >Or I should just rewrite so much quake in Modula-3... > > > > > > - Jay > > = > > > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >It would have been nice for and/or to short circuit in quake like they do i= > >n C.


Code like:

if not defined("TARGET")
 =3B read= > >only TARGET =3D "I386_FREEBSD"
else
 =3B if not equal(TARGET=2C "= > >FreeBSD4")
 =3B =3B =3B readonly TARGET =3D "I386_FREEBSD" >r> =3B end
end


is better written as:
if not defined("T= > >ARGET") or not equal(TARGET=2C "FreeBSD4")
 =3B readonly TARGET =3D = > >"I386_FREEBSD"
end

but that isn't allowed because equal() will co= > >mplain that TARGET isn't defined.

It probably can't fixed though=2C = > >due to e.g.:

if TRUE or DoSomething()
 =3B ...
end

= > >
would be broken.


perhaps
OR and AND
or short_circuit_a= > >nd
or and_shorted
or and_short_circuit
or and_early_out
or and_= > >early
or "&=3B&=3B"
or something...


Or I should just= > > rewrite so much quake in Modula-3...


 =3B- Jay
> > = > > > >= > > > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Aug 18 03:53:46 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 17 Aug 2010 21:53:46 -0400 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: References: <20100817222704.B3ABE1A209B@async.async.caltech.edu> Message-ID: <20100818015346.GB29274@topoi.pooq.com> On Wed, Aug 18, 2010 at 01:17:02AM +0000, Jay K wrote: > > I don't know what the names should be, I'm pretty comfortable with "&&" and "||". > Short circuiting is very useful. > > > Dijkstra advises against it, though. > > That makes me question Dijkstra, not short circuiting. He has specific reasons, having to do with programs being part of a logical calculus. In logic, 'and' and 'or' are both commutative, so he thinks it sim0plifies the formal calculus of programming to have them behave the same in programs. > > > Also useful is assignment being an expression. > I wish it was in Modula-3. So do I. > > Such things as: > > > if ((f = fopen(..)) && fread(f,...) > > > or if (p && *p) > > > In the first case Modula-3 forces useless verbosity and indentation. > In the second case Modula-3 gets it right but Quake fails. > > Lacking these features you end up contorting your code one way or another, such as duplicating things. > > > I really can't stand code that looks like: > > > result = do something > if success(result) > do more stuff > if success > do more stuff > if succes > do more stuff > > > Modula-3 this wrong. > Exceptions help. > But basically I want to be able to introduce WITH or VAR anywhere, but not need to "END" them, and therefore no implied need for indentation.. It looks as if you want Modula 3 with Algol 68 syntax. So do I. -- hendrik From jay.krell at cornell.edu Wed Aug 18 09:53:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 18 Aug 2010 07:53:12 +0000 Subject: [M3devel] FW: clock_getres / Time.Grain. In-Reply-To: References: <20100817213538.760482474033@birch.elegosoft.com>, Message-ID: Well, it seems clock_getres is either not available (Darwin) or varies much from the historical code (Linux, Solaris). So this is only for OSF/1 now. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 18 Aug 2010 01:19:48 +0000 Subject: [M3devel] FW: clock_getres / Time.Grain. This needs a review. Folks need to read Posix, the Modula-3 *.i3 files, possibly the OS man pages. Possibly run the two versions and compare. Possibly only #ifdef it in when the compare similar, e.g. on OSF and leave the rest alone. Possibly only use the timeofday timer and not the highres timer. Thanks, - Jay > Date: Tue, 17 Aug 2010 23:35:38 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/17 23:35:37 > > Modified files: > cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c > > Log message: > Let's try clock_getres if it is available. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Aug 18 19:24:39 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 18 Aug 2010 12:24:39 -0500 Subject: [M3devel] dbxout_static_chain_decl? In-Reply-To: <20100817235900.GB29080@topoi.pooq.com> References: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu> <4BFF15CE.7060908@lcwb.coop> <20100528220400.GB4904@topoi.pooq.com> <20100817235900.GB29080@topoi.pooq.com> Message-ID: <4C6C1757.9080005@lcwb.coop> hendrik at topoi.pooq.com wrote: > On Fri, May 28, 2010 at 06:04:01PM -0400, hendrik at topoi.pooq.com wrote: >> In Algol 68, when it's implemented using static links, the static chain >> doesn't thread *all* the chain of surrounding procedures -- it skips the >> ones that don't define any names used in the inner ones. >> >> This bit of denesting might improve efficiency even in Modula 3, since >> some static chains might end up being shorter. Whether it's worth the >> effort is another question, of course. Well, I'm going to keep beating this drum. Except for highly optimized compiles, I want the debugger to give a view that reflects what is declared. Even when a nonlocal variable is not referred do by any nested procedure, a debugger user (specifically, me) often wants to look at or even change such variables, when stopped inside a nested procedure. I do this a lot. Yes, you can always go up the dynamic call chain with debugger commands to get at them, but this sometimes costs a *lot* of extra time, especially if the nested procedure has called itself recursively umpteen times. Then you have to get back to the frame you were in. Then do it all again later. It's also often quite tricky to get right. All this diverts a lot of mental capacity from actually chasing the bug to how to work the debugger, just for a simple variable access that, by language rules, is visible from right were you are. Of course, it you choose a medium or high level of optimization, then using a debugger is already pretty much an exercise in futility anyway, for various other reasons, so in that case, I wouldn't fight it. > > I should perhaps have mentioned that this behaviour is *required* by the > Alcol 68 language definition. Not required by Modula 3, where what you > can do with local procedures is more restricted. > > -- hendrik > From jay.krell at cornell.edu Thu Aug 19 22:15:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 20:15:32 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson Message-ID: New Hudson node. A VM running on MacBook. ? We'll see if it stays on and if the network works. I386_NETBSD ssh -p 227 hudson at jayk.homedns.org To start, it has: ? /usr/pkg/java/openjdk7/bin/java ? /cm3/bin/cm3 ??? Actually a bunch in /cm3, you can get cm3cg, pkg/{m3core,libm3,etc.} there. ? /usr/pkg/bin/bash It is missing some libraries still so some "late" packages will fail. I haven't tested X apps, have to reboot the MacBook. ?And install more X libraries. AMD64_NETBSD later. I made a new node. Copied from openbsd-jkrell. jkrell-xnbsd. http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin ?- Jay ? From jay.krell at cornell.edu Thu Aug 19 22:32:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 20:32:40 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: ok, I put in a /usr/local/bin/java that Hudson likes. I cloned the m3cc/build/tests jobs from I386_OPENBSD. Not sure what is next, gotta run. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Thu, 19 Aug 2010 20:15:32 +0000 > Subject: [M3devel] VM for I386_NETBSD Hudson > > > New Hudson node. > A VM running on MacBook. > We'll see if it stays on and if the network works. > > I386_NETBSD > > ssh -p 227 hudson at jayk.homedns.org > > To start, it has: > /usr/pkg/java/openjdk7/bin/java > /cm3/bin/cm3 > Actually a bunch in /cm3, you can get cm3cg, pkg/{m3core,libm3,etc.} there. > /usr/pkg/bin/bash > > It is missing some libraries still so some "late" packages > will fail. > > I haven't tested X apps, have to reboot the MacBook. > And install more X libraries. > > AMD64_NETBSD later. > > I made a new node. Copied from openbsd-jkrell. > jkrell-xnbsd. > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > - Jay > From jay.krell at cornell.edu Thu Aug 19 22:54:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 20:54:48 +0000 Subject: [M3devel] more failure to propagate error Message-ID: http://hudson.modula3.com:8080/job/boot-i386-netbsd/4/console I understand the actual error, the config files are missing. ?- Jay From jay.krell at cornell.edu Thu Aug 19 23:05:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:05:17 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: , Message-ID: ok, I cloned boot-ppc-linux and this worked: http://hudson.modula3.com:8080/job/boot-i386-netbsd/5/console I had to: ?- remove the branch ?- change my /cm3 to not delegate to CVS (run scripts/python/make-dist-cfg.py) ?- not sure, but the config files still weren't there, maybe I had to rerun it, maybe I had mkdir config and that stopped ? the copying on subsequent run, I deleted the empty dir and reran We'll see how this goes: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/1/console Somewhat tedious point and click and type here but not terrible. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Thu, 19 Aug 2010 20:32:40 +0000 > Subject: Re: [M3devel] VM for I386_NETBSD Hudson > > > ok, I put in a /usr/local/bin/java that Hudson likes. > I cloned the m3cc/build/tests jobs from I386_OPENBSD. > Not sure what is next, gotta run. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com; m3devel at elegosoft.com > > Date: Thu, 19 Aug 2010 20:15:32 +0000 > > Subject: [M3devel] VM for I386_NETBSD Hudson > > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - Jay > > > From jay.krell at cornell.edu Thu Aug 19 23:10:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:10:20 +0000 Subject: [M3devel] SOLgnu/SOlsun broken Message-ID: I'm aware that SPARC32_SOLARIS/SOLsun/SOLgnu are having problems. e.g.: http://hudson.modula3.com:8080/job/cm3-current-build-SOLgnu/55/console cp: /home/hudson/workspace/cm3-current-build-SOLgnu/cm3/m3-sys/cminstall/src/config-no-install/CVS: is a directory Segmentation Fault - core dumped /home/hudson/work/cm3-inst/ssol/current/bin/cm3- is broken compiler upgrade failed I'll try to get to it soon. Usually, for some reason, these are caused by something related to position independence. - Jay From jay.krell at cornell.edu Thu Aug 19 23:12:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:12:00 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: ,,, , , , , , , , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu>, , , , , , Message-ID: As well, SOLgnu/SOLsun/SPARC32_SOLARIS when using the gcc 4.5.1 backend crash just after raising an exception. Ugh. Needs investigation.. ?- Jay ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] barrier labels? > Date: Tue, 17 Aug 2010 20:44:19 +0000 > > I forgot about this. > I never resolved it. > Things seem to work though. > ? > > - Jay > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > Date: Tue, 13 Jul 2010 06:38:05 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] barrier labels? > > > > > > I don't know. There is so much unknown here. It is frustrating and > difficult. > > We could use an extensive set of test cases. > > Or know more about the test cases we do have. > > And it'd be nice to see if anything varies in the 4.3 path if we put > the labels on that list or not. > > > > tangent: > > > > I'd like automation that compiles the whole system, multiple > architectures, and puts all the *s files in one flat > > directory per architecture. I guess it's just a matter of a little code. > > It should just skip the few errors that are cross problems, which > I should fix anyway. > > That particular problem makes me a little nervous, but I suppose > I can code it to use both INTEGER and Target.Int > > if doing a native build, and assert that the results match. > > I hit a snag yesterday, can't build any tests (just to assembly) > without first shipping m3core/libm3. > > Can't ship m3core/libm3 for cross building. > > I guess, and I forgot this, I should have used -x for override. Duh. > > That's why I tried I386_DARWIN for some current 4.5 problems vs. > SOLgnu, to escape cross building. Oops. > > > > > > - Jay > > > > ---------------------------------------- > > > From: hosking at cs.purdue.edu > > > Date: Mon, 12 Jul 2010 09:43:01 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] barrier labels? > > > > > > Perhaps we just need FORCED_LABEL for these: > > > > > > /* In a LABEL_DECL, nonzero means this label had its address taken > > > and therefore can never be deleted and is a jump target for > > > computed gotos. */ > > > > > > > > > On 11 Jul 2010, at 23:03, Jay K wrote: > > > > > > > > > > > I still don't see it, in the C++ frontend. > > > > > > > > There is: > > > > > > > > void > > > > expand_label (tree label) > > > > { > > > > ... > > > > if (DECL_NONLOCAL (label)) > > > > { > > > > ... nonlocal_goto_handler_labels > > > > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > > > > nonlocal_goto_handler_labels); > > > > } > > > > > > > > but I don't think this works until later. > > > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > >> From: hosking at cs.purdue.edu > > > >> Date: Sun, 11 Jul 2010 20:52:25 -0400 > > > >> To: jay.krell at cornell.edu > > > >> CC: m3devel at elegosoft.com > > > >> Subject: Re: [M3devel] barrier labels? > > > >> > > > >> No, that code came from 4.x... > > > >> > > > >> > > > >> > > > >> > > > >> On 11 Jul 2010, at 19:41, Jay K wrote: > > > >> > > > >>> > > > >>> Tony, thanks for the pointer..though I haven't been able to > find it yet. > > > >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 > was current at the time. > > > >>> > > > >>> - Jay > > > >>> > > > >>> ---------------------------------------- > > > >>>> From: hosking at cs.purdue.edu > > > >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 > > > >>>> To: jay.krell at cornell.edu > > > >>>> CC: m3devel at elegosoft.com > > > >>>> Subject: Re: [M3devel] barrier labels? > > > >>>> > > > >>>> I extracted that usage from what C++ was doing for exception > labels. The point is to make sure that flow analysis knows that the > exception handler label targets are important "non-local" label > targets. I do remember that DECL_NONLOCAL was *not* the right thing to > do (that is used for proper non-local outer-scope goto targets for > nested functions) and I remember the SP hacks being used with that > (they need to recover from targeting from an inner-scope function and > clean up the stack accordingly). I suggest poking around in what the > C++ exception handling now does with table-driven exception targets. > > > >>>> > > > >>>> On 11 Jul 2010, at 07:46, Jay K wrote: > > > >>>> > > > >>>>> > > > >>>>> Tony, six years ago you introduce what is now: > > > >>>>> > > > >>>>> > > > >>>>> > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > > >>>>> > > > >>>>> > > > >>>>> static void > > > >>>>> m3cg_set_label (void) > > > >>>>> { > > > >>>>> ... > > > >>>>> if (barrier) > > > >>>>> { > > > >>>>> ... > > > >>>>> { > > > >>>>> rtx list = DECL_STRUCT_FUNCTION > (current_function_decl)->x_nonlocal_goto_handler_labels; > > > >>>>> DECL_STRUCT_FUNCTION > (current_function_decl)->x_nonlocal_goto_handler_labels > > > >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > > > >>>>> } > > > >>>>> ... > > > >>>>> > > > >>>>> > > > >>>>> I'm not sure what to do here for gcc 4.5. > > > >>>>> The data has moved around and isn't available this early. I > suppose we could hang some information on and > > > >>>>> deal with it later in compilation. > > > >>>>> > > > >>>>> > > > >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very > bad code to be produced (incorrect, not inefficient). > > > >>>>> I didn't look into why. The bad code was changing the stack > pointer where it should leave it alone. > > > >>>>> > > > >>>>> > > > >>>>> gcc-4.5 is working for me now (cm3 built with it can built > itself), at least with -O1, AMD64_DARWIN. > > > >>>>> And Juno/mentor/tetris work without optimization, I'll test > optimized later. > > > >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. > > > >>>>> > > > >>>>> > > > >>>>> Do we have good exception handling tests? > > > >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > > > >>>>> > > > >>>>> > > > >>>>> I'll poke around more.. > > > >>>>> > > > >>>>> > > > >>>>> - Jay > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > From jay.krell at cornell.edu Thu Aug 19 23:27:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:27:27 +0000 Subject: [M3devel] cvs commands in Hudson keep complaining about long-ago deleted directories Message-ID: Olaf there's something somehow slightly off. http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console Started by user jkrell Building remotely on jkrell-xnbsd [m3cc] $ cvs -q -z3 update -PdC -D "Thursday, August 19, 2010 9:16:34 PM UTC" ?cvs update: use `cvs add' to create an entry for `gcc/INSTALL'???? <==? ?cvs update: use `cvs add' to create an entry for `gcc/fixincludes' ?? <== This has been happening on all jobs. I manually removed the directories in most/all. But this is a new node/task. It must be related to the branches varying. But cvs upd shouldn't be so difficult. ?- Jay From wagner at elegosoft.com Fri Aug 20 08:03:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 08:03:38 +0200 Subject: [M3devel] cvs commands in Hudson keep complaining about long-ago deleted directories In-Reply-To: References: Message-ID: <20100820080338.42ud2degysww4gsk@mail.elegosoft.com> Quoting Jay K : > Olaf there's something somehow slightly off. > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > Started by user jkrell > Building remotely on jkrell-xnbsd > [m3cc] $ cvs -q -z3 update -PdC -D "Thursday, August 19, 2010 9:16:34 PM UTC" > > ?cvs update: use `cvs add' to create an entry for `gcc/INSTALL'???? > <==? > ?cvs update: use `cvs add' to create an entry for `gcc/fixincludes' ?? <== > > This has been happening on all jobs. > I manually removed the directories in most/all. > But this is a new node/task. > > It must be related to the branches varying. > But cvs upd shouldn't be so difficult. In my working copy from the trunk these directories are there. They get removed by your m3makefile again, but update -d resurrects them. What exactly have you done to `remove' them from CVS? As CVS doesn't handle directories as first class objects, the only ways to remove a directory are (1) delete all files in it recursively and let CVS know. The -p(rune) option will then delete empty directories. (2) remove the complete history on the server. Not allowed for a simple human user in daily operations ;-) Olaf PS: I'm in a hurry now, do I won't have time to read and answer all mails now. There are still several dozens... More later. -- 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 Fri Aug 20 08:33:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 20 Aug 2010 06:33:53 +0000 Subject: [M3devel] cvs commands in Hudson keep complaining about long-ago deleted directories In-Reply-To: <20100820080338.42ud2degysww4gsk@mail.elegosoft.com> References: , <20100820080338.42ud2degysww4gsk@mail.elegosoft.com> Message-ID: > They get removed by your m3makefile again Oops, I didn't realize, don't see, will keep looking. (See next.) > What exactly have you done to `remove' them from CVS? As CVS doesn't > handle directories as first class objects, the only ways to remove > (1) delete all files in it recursively and let CVS know. > The -p(rune) option will then delete empty directories. Oops, I thought I had done that. Apparently not. > (2) remove the complete history on the server. Not allowed for > a simple human user in daily operations ;-) Of course. Sorry for the misdirection! ?- Jay From wagner at elegosoft.com Fri Aug 20 10:31:57 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 10:31:57 +0200 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: <20100820103157.387frltd2cwooccc@mail.elegosoft.com> Quoting Jay K : > ok, I put in a /usr/local/bin/java that Hudson likes. > I cloned the m3cc/build/tests jobs from I386_OPENBSD. > Not sure what is next, gotta run. To simplify matters, new Hudson nodes should contain the last CM3 rlease in $INSTROOT_REL, which usually is something like $HOME/work/$HOST/cm3-inst/rel-5.8.6 BTW, several nodes still lack the latest release there, and/or reference something like LASTREL=d5.7.0 or similar. These may fail as soon as we rely on features in that release (like quake functions etc.). I haven't had time to check everything yet, Olaf > ?- Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Date: Thu, 19 Aug 2010 20:15:32 +0000 >> Subject: [M3devel] VM for I386_NETBSD Hudson >> >> >> New Hudson node. >> A VM running on MacBook. >> We'll see if it stays on and if the network works. >> >> I386_NETBSD >> >> ssh -p 227 hudson at jayk.homedns.org >> >> To start, it has: >> /usr/pkg/java/openjdk7/bin/java >> /cm3/bin/cm3 >> Actually a bunch in /cm3, you can get cm3cg, >> pkg/{m3core,libm3,etc.} there. >> /usr/pkg/bin/bash >> >> It is missing some libraries still so some "late" packages >> will fail. >> >> I haven't tested X apps, have to reboot the MacBook. >> And install more X libraries. >> >> AMD64_NETBSD later. >> >> I made a new node. Copied from openbsd-jkrell. >> jkrell-xnbsd. >> http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ >> >> PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin >> >> - 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 wagner at elegosoft.com Fri Aug 20 14:58:09 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 14:58:09 +0200 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com> The installed cm3 still uses the wrong target platform name: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. Fix config? Olaf Quoting Jay K : > > New Hudson node. > A VM running on MacBook. > ? We'll see if it stays on and if the network works. > > I386_NETBSD > > ssh -p 227 hudson at jayk.homedns.org > > To start, it has: > ? /usr/pkg/java/openjdk7/bin/java > ? /cm3/bin/cm3 > ??? Actually a bunch in /cm3, you can get cm3cg, > pkg/{m3core,libm3,etc.} there. > ? /usr/pkg/bin/bash > > It is missing some libraries still so some "late" packages > will fail. > > I haven't tested X apps, have to reboot the MacBook. > ?And install more X libraries. > > AMD64_NETBSD later. > > I made a new node. Copied from openbsd-jkrell. > jkrell-xnbsd. > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > ?- 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 wagner at elegosoft.com Fri Aug 20 16:15:36 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 16:15:36 +0200 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Quoting Jay K : > New Hudson node. > A VM running on MacBook. > ? We'll see if it stays on and if the network works. For your information It seems we have crossed the acceptable load boundary for our hosted server birch.elegosoft.com recently. The main problem seems to be I/O caused by lots of concurrent CVS checkouts and updates in combination with internal backup, which make other services like HTTP unresponsive and unusable. As far as I can see there is no easy short-time solution. We are going to find a new and more efficient home for our web services anyway in the fall, but it may be that we will have to limit the number of concurrent CVS accesses or Hudson job executions (including clients) for some time. I'm currently also investigating if we can easily move to another (virtual) host or setup a proxy to improve matters. Both will need some migration on client sides. I'll keep you informed what way we choose to resolve this problem. It will help if you don't check in lots of small changes, but complete reasonable change sets. It would also help if we could reduce the size of the repository again, especially in the gcc and gdb structures. If there is dead content that we don't really need, we might move it to another access path for some time. Thanks in advance for your understanding and cooperation. Please stay calm and continue to enjoy the flight ;-) 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 Sat Aug 21 09:38:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 07:38:29 +0000 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> References: , <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Message-ID: All the more reason to use anything besides CVS? What about checkout vs. update? Is update a problem or just checkout? We don't do many checkouts, right? Can/should the pollling interval be changed, like to every hour? And can machines poll at different times, say at a minute within the hour that is a hash of their hostname? Or more aggressive, have some machines only poll a few times a day, once or twice? Only more mainstream machines poll more frequently? I can always run "build now" if I'm eager for a particular build. Repository size is a tough one. Even if I remove files, the repository size is unchanged, right? We have 3 copies of gcc in semi-active use right now. There are others in the repository. But gcc-apple really isn't active -- it is for ARM_DARWIN. Can the Hudson jobs easily exclude that? Between gcc and gcc-4.5 we are stuck for now. gcc-4.5 works a lot and also definitely fails some. In particular SPARC32_SOLARIS/SOLgnu/SOLsun fail right after throwing an exception. SPARC64_SOLARIS has at least a small problem. I'm not sure if there are problems beyond those. Certainly if you want to "cherry pick" off a few files here and there, there is definitely opportunity. I'm not sure if a few files here and there matter though. m3-pkgtools presently isn't built for example. dll2lib or whatever isn't worth anything these days. The old m3gc-simple and m3gc-enhanced are dead. I like a source control to preserve record of deleted stuff though. - Jay > Date: Fri, 20 Aug 2010 16:15:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: m3-support at elego.de > Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson > > Quoting Jay K : > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > For your information > > It seems we have crossed the acceptable load boundary for our hosted > server birch.elegosoft.com recently. The main problem seems to be > I/O caused by lots of concurrent CVS checkouts and updates in combination > with internal backup, which make other services like HTTP unresponsive and > unusable. > > As far as I can see there is no easy short-time solution. We are going > to find a new and more efficient home for our web services anyway in the > fall, but it may be that we will have to limit the number of concurrent > CVS accesses or Hudson job executions (including clients) for some time. > > I'm currently also investigating if we can easily move to another > (virtual) host or setup a proxy to improve matters. Both will need > some migration on client sides. > > I'll keep you informed what way we choose to resolve this problem. > > It will help if you don't check in lots of small changes, but complete > reasonable change sets. > > It would also help if we could reduce the size of the repository again, > especially in the gcc and gdb structures. If there is dead content > that we don't really need, we might move it to another access path for > some time. > > Thanks in advance for your understanding and cooperation. > > Please stay calm and continue to enjoy the flight ;-) > > 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 wagner at elegosoft.com Sat Aug 21 11:24:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 21 Aug 2010 11:24:43 +0200 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: References: , <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Message-ID: <20100821112443.eb5ljfzklc0kk8wc@mail.elegosoft.com> Quoting Jay K : > All the more reason to use anything besides CVS? I'd doubt that other system will improve this situation much. But I don't know. Peter Eiserloh is currently trying out git. > What about checkout vs. update? > Is update a problem or just checkout? > We don't do many checkouts, right? We're doing mostly updates. But they should generate the same i/o load. > Can/should the pollling interval be changed, like to every hour? > And can machines poll at different times, say at a minute within the > hour that is a hash of their hostname? I've already increased the polling interval on several jobs, but may increase still more. > Or more aggressive, have some machines only poll a few times a day, > once or twice? Well yes, we could just poll locally on birch and start the other jobs on completion. I think I'll do that; I'll probably disable all the polling first by script and then add some dependencies. > Only more mainstream machines poll more frequently? > I can always run "build now" if I'm eager for a particular build. Yes. > Repository size is a tough one. > Even if I remove files, the repository size is unchanged, right? I meant we could move a complete sub-tree to another location for some time if it's not needed. There are several versions of gcc IIRC. If we need all of them for at least one target, we cannot do that. > We have 3 copies of gcc in semi-active use right now. > There are others in the repository. > But gcc-apple really isn't active -- it is for ARM_DARWIN. > Can the Hudson jobs easily exclude that? We can add that where possible, too. > Between gcc and gcc-4.5 we are stuck for now. > gcc-4.5 works a lot and also definitely fails some. > In particular SPARC32_SOLARIS/SOLgnu/SOLsun fail right after > throwing an exception. > SPARC64_SOLARIS has at least a small problem. > I'm not sure if there are problems beyond those. > > Certainly if you want to "cherry pick" off a few files here and > there, there is definitely opportunity. > I'm not sure if a few files here and there matter though. Not worth the trouble. > m3-pkgtools presently isn't built for example. > dll2lib or whatever isn't worth anything these days. It's just the gcc and gdb code that's so large. > The old m3gc-simple and m3gc-enhanced are dead. Also not worth to remove. > I like a source control to preserve record of deleted stuff though. I'm not going to delete anything then. Let's try the polling strategy change first. 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 Sat Aug 21 12:13:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 10:13:03 +0000 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: <20100821112443.eb5ljfzklc0kk8wc@mail.elegosoft.com> References: , <20100820161536.xmld5roocgwgggow@mail.elegosoft.com>, , <20100821112443.eb5ljfzklc0kk8wc@mail.elegosoft.com> Message-ID: > I meant we could move a complete sub-tree to another location for some > time if it's not needed. There are several versions of gcc IIRC. > If we need all of them for at least one target, we cannot do that. Aha, I understand better now. You mean to a new CVS root/repository? You can move this: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.1.1/ e.g. /usr/cvs/cm3_m3cc_gcc-4.1.1. My desire for history, worst case, drop a readme.txt in cm3/m3-sys/m3cc/gcc-4.1.1. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-interix. I merged it into m3cc/gcc long ago (and gcc-4.5 more recently) and it has all been deleted. Again, a marker file could be dropped in. Less clear: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-apple. It is for iphone but surely currently unused. stuck with for now: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.5 http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc I actually have some interest in making this situation worse. It appears OpenBSD doesn't like GPL3, so they have moved some targets up to gcc 4.x, but stopped at 4.2.1. Some are on 3.x I think some are on 2.x. It'd be helpful to branch the OpenBSD versions. Or, on the other hand, I'm starting to put time into a C backend! :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Aug 21 14:05:34 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 21 Aug 2010 08:05:34 -0400 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: References: <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Message-ID: <20100821120534.GA8755@topoi.pooq.com> On Sat, Aug 21, 2010 at 07:38:29AM +0000, Jay K wrote: > > All the more reason to use anything besides CVS? Sorry. I meant to work on conversion to monotone, but I haven't had the time to work on it yet. -- hendrik From wagner at elegosoft.com Sat Aug 21 18:21:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 21 Aug 2010 18:21:44 +0200 Subject: [M3devel] changes in CM3 continuous integration setup Message-ID: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com> Due to I/O overload problems on the Hudson/CVS/WWW server birch.elegosoft.com I have now reduced the jobs that perform actual repository polling on the CM3 CVS repository to two, running locally on birch: cm3-current-m3cc-AMD64_LINUX cm3-current-build-AMD64_LINUX The first checks all the m3cc sources, the second the rest; the first runs all 10, the second all 11 minutes. All other jobs are triggered in several cascades by these two. For each target platform, the dependencies are m3cc --> build --> test-m3tests --> test-all-pkgs The m3cc and build jobs for AMD64_LINUX also trigger other target platform builds in this fashion: AMD64_LINUX --> AMD64_DARWIN --> AMD64_FREEBSD --> PPC_DARWIN --> I386_DARWIN --> I386_NETBSD --> I386_OPENBSD --> SOLsun-opencsw-curent9s --> SOLsun-opencsw-curent10s --> I386_SOLARIS-opencsw-curent10x --> FreeBSD4 --> LINUXLIBC6 --> NT386 --> PPC_LINUX --> SPARC32_LINUX --> SOLgnu This scheme reflects the expected availability and maintainability of the machines by me, in case you wonder ;-) I hope that this will help to reduce the load and not lead to further problems due to parallel updates on one cascade level. Of course, jobs can still be started manually via the HTTP GUI. If you do this, please bear in mind that other jobs will be triggered, too, according to the diagrams above. 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 Sun Aug 22 00:42:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 22:42:21 +0000 Subject: [M3devel] record types in backend In-Reply-To: References: <20100821083935.3593B247400C@birch.elegosoft.com>, Message-ID: In debugging this..the gcc code wants to enumerate the fields of a struct. We spend the effort building up most of this information, but we never hook it up to the parameter. The fields are null. From debugging it. Then from reading our code: declare_param: m3_build_type case T_struct: { tree ts = make_node (RECORD_TYPE); TYPE_FIELDS (ts) = NULL_TREE; Seems to me we should have a hash of typeid to tree, and here we should look up the typeid and set the fields appropriately. I'll try that. Besides fixing SPARC64_SOLARIS here, it should dramatically improve debugging with stock gdb. We'll see. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Sat, 21 Aug 2010 21:49:04 +0000 Subject: Re: [M3commit] CVS Update: cm3 It turns out 4.3.5 fails the same way. - Jay > Date: Sat, 21 Aug 2010 10:39:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/21 10:39:34 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > > Log message: > back to gcc 4.3 for SPARC64_SOLARIS, see m3-sys/m3tests/src/p2/p247 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 22 00:43:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 22:43:53 +0000 Subject: [M3devel] record types in backend In-Reply-To: References: <20100821083935.3593B247400C@birch.elegosoft.com>, , Message-ID: I should point out that the type we do build up contains fields of I think integers. static void debug_field (const char *name) { tree f = build_decl (FIELD_DECL, get_identifier (name), t_int); That also needs work and shouldn't be difficult. I'm not sure where the builtin typeids come from though. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: record types in backend Date: Sat, 21 Aug 2010 22:42:21 +0000 In debugging this..the gcc code wants to enumerate the fields of a struct. We spend the effort building up most of this information, but we never hook it up to the parameter. The fields are null. From debugging it. Then from reading our code: declare_param: m3_build_type case T_struct: { tree ts = make_node (RECORD_TYPE); TYPE_FIELDS (ts) = NULL_TREE; Seems to me we should have a hash of typeid to tree, and here we should look up the typeid and set the fields appropriately. I'll try that. Besides fixing SPARC64_SOLARIS here, it should dramatically improve debugging with stock gdb. We'll see. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Sat, 21 Aug 2010 21:49:04 +0000 Subject: Re: [M3commit] CVS Update: cm3 It turns out 4.3.5 fails the same way. - Jay > Date: Sat, 21 Aug 2010 10:39:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/21 10:39:34 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > > Log message: > back to gcc 4.3 for SPARC64_SOLARIS, see m3-sys/m3tests/src/p2/p247 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 22 12:11:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Aug 2010 10:11:08 +0000 Subject: [M3devel] better type information in gcc backend Message-ID: This is getting interesting. I have a small local change so that local structs have type information -- as to what fields they contain. As a result, you can see like: 0x001d65b7 in RTType__Expand (M3_DaARCY_m=0x0) at ../src/runtime/common/RTType.m3:719 (gdb) info locals M3_BQo8Jp_new = { Bd56fi_0_32_name = 0, D0ztjH_32_32_is_equal = 0, DXHNAh_64_32_rehash = 0, Cwb5VA_96_32_initial_size = 0, Cwb5VA_128_32_full = 0, Cwb5VA_160_32_cnt = 0, Cwb5VA_192_32_max = 0, AcxOUs_224_32_mask = 0, AJWxb1_256_32_map = 0 } which is a great improvement. It used to only show you the address of the locals. *However*, first when I put the change in, gcc would hit infinite recursions, something related to bitfields. So I *again* disabled our wierdo bitfield stuff. That hack is a continuing thorn in my side. Yes it does generate better code, at least when not optimizing. We'd surely be better to get all the type information correct though and use member references. I realize that the frontend "lowers" things generally further than that, it expects a lower level backend than the gcc tree representation is really designed for. Anyway.. Then it compiles. But the result crashes. Using -O3. And info locals actually prints the locals three times each. More to do here.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Sun Aug 22 16:26:33 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Sun, 22 Aug 2010 22:26:33 +0800 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 Message-ID: The CM3 binaries for FreeBSD6 don't work in FreeBSD 8.1 because cminstall is looking for very specific versions of libraries. For example it wants libm.so.4 but I only have libm.so -> libm.so.5. It also looks for libc.so.6 where I can only supply libc.so.7. Even worse is the requirement for libpthread.so.2. There *IS* no libpthread.so.anything. There's a libpthread.so which is a soft link to libthr.so which is itself a soft link to libthr.so.3. If I try to fake any of this out with softlinks I get problems with libpthread.so.2 since it's looking for a symbol (LIBTHREAD_1_0) which is apparently not provided by libthr.so.3. There is nothing in /usr/ports that seems to give me a proper libpthread that cminstall would like, so I'm basically stuck at this point unable to install (not build -- install!) CM3 on this FreeBSD machine. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Aug 22 16:43:49 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 22 Aug 2010 16:43:49 +0200 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: References: Message-ID: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Quoting Michael Richter : > The CM3 binaries for FreeBSD6 don't work in FreeBSD 8.1 because cminstall is > looking for very specific versions of libraries. For example it wants > libm.so.4 but I only have libm.so -> libm.so.5. It also looks for libc.so.6 > where I can only supply libc.so.7. Even worse is the requirement for > libpthread.so.2. There *IS* no libpthread.so.anything. There's a > libpthread.so which is a soft link to libthr.so which is itself a soft link > to libthr.so.3. > > If I try to fake any of this out with softlinks I get problems with > libpthread.so.2 since it's looking for a symbol (LIBTHREAD_1_0) which is > apparently not provided by libthr.so.3. There is nothing in /usr/ports that > seems to give me a proper libpthread that cminstall would like, so I'm > basically stuck at this point unable to install (not build -- install!) CM3 > on this FreeBSD machine. AFAIK FreeBSD always offered so-called compatibility distributions, which contain all old libraries of previous systems. You should be able to install these with the FreeBSD installer and then run cm3 and build your own binary which uses the up-to-date libs. Hope this helps, 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 ttmrichter at gmail.com Sun Aug 22 17:49:33 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Sun, 22 Aug 2010 23:49:33 +0800 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> References: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Message-ID: On 22 August 2010 22:43, Olaf Wagner wrote: > AFAIK FreeBSD always offered so-called compatibility distributions, > which contain all old libraries of previous systems. You should be > able to install these with the FreeBSD installer and then run cm3 > and build your own binary which uses the up-to-date libs. > I'm looking at FreeBSD.org and I'm not seeing anything like that at all. Sysintall doesn't offer anything like that under "distributions" either. Sorry for being such a newb here, but I really have no idea where to even LOOK for the next step. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Sun Aug 22 17:54:57 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Sun, 22 Aug 2010 23:54:57 +0800 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: References: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Message-ID: Of course about ten seconds after I post this I find the "compatx" packages in ports. Teaches me to look for full words in names! Please disregard the earlier message. ;) On 22 August 2010 23:49, Michael Richter wrote: > On 22 August 2010 22:43, Olaf Wagner wrote: > >> AFAIK FreeBSD always offered so-called compatibility distributions, >> which contain all old libraries of previous systems. You should be >> able to install these with the FreeBSD installer and then run cm3 >> and build your own binary which uses the up-to-date libs. >> > > I'm looking at FreeBSD.org and I'm not seeing anything like that at all. > Sysintall doesn't offer anything like that under "distributions" either. > Sorry for being such a newb here, but I really have no idea where to even > LOOK for the next step. > > > -- > "Perhaps people don't believe this, but throughout all of the discussions > of entering China our focus has really been what's best for the Chinese > people. It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Aug 22 18:49:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 22 Aug 2010 18:49:39 +0200 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: References: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Message-ID: <20100822184939.4zv8hdovuowgckok@mail.elegosoft.com> Quoting Michael Richter : > On 22 August 2010 22:43, Olaf Wagner wrote: > >> AFAIK FreeBSD always offered so-called compatibility distributions, >> which contain all old libraries of previous systems. You should be >> able to install these with the FreeBSD installer and then run cm3 >> and build your own binary which uses the up-to-date libs. >> > > I'm looking at FreeBSD.org and I'm not seeing anything like that at all. > Sysintall doesn't offer anything like that under "distributions" either. > Sorry for being such a newb here, but I really have no idea where to even > LOOK for the next step. I think this may be of help: luthien [] root # ls -ld /usr/ports/misc/compat?x drwxrwxr-x 3 root wheel 512 May 25 05:23 /usr/ports/misc/compat3x/ drwxrwxr-x 3 root wheel 512 Aug 22 05:23 /usr/ports/misc/compat4x/ drwxrwxr-x 3 root wheel 512 Aug 22 05:23 /usr/ports/misc/compat5x/ drwxrwxr-x 3 root wheel 512 Dec 6 2009 /usr/ports/misc/compat6x/ drwxr-xr-x 3 wagner wheel 512 Dec 8 2009 /usr/ports/misc/compat7x/ luthien [] root # cat /usr/ports/misc/compat6x/pkg-descr This package allows you to install the compat6x libraries on your system, so you can use legacy binaries that depend on them. Ports usage example: -- .include .if ${OSVERSION} >= 700043 LIB_DEPENDS+= c.6:${PORTSDIR}/misc/compat6x .endif -- 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 Mon Aug 23 09:57:04 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Aug 2010 09:57:04 +0200 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com> References: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com> Message-ID: <20100823095704.6pgf9a9xssc4804o@mail.elegosoft.com> Quoting Olaf Wagner : > AMD64_LINUX --> AMD64_DARWIN > --> AMD64_FREEBSD -//-> PPC_DARWIN --> I386_DARWIN > --> I386_NETBSD > --> I386_OPENBSD > --> SOLsun-opencsw-curent9s > --> SOLsun-opencsw-curent10s > --> I386_SOLARIS-opencsw-curent10x > -//-> FreeBSD4 --> LINUXLIBC6 > --> NT386 > --> PPC_LINUX > --> SPARC32_LINUX > --> SOLgnu I've now cut off the subtrees at PPC_DARWIN and FreeBSD4, as the load was still not much better. Those two poll now for themselves again, but only once or twice a day, so that the number of CVS updates and build runs should be further reduced. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 23 12:44:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 10:44:48 +0000 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100823095704.6pgf9a9xssc4804o@mail.elegosoft.com> References: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com>, <20100823095704.6pgf9a9xssc4804o@mail.elegosoft.com> Message-ID: I don't really understand all of this. Surely CVS can tolerate more than 10 "active" users? Or is it really awful? (or, most likely, both) What if they all poll much less than once an hour? Let's say we have 12 machines. Have them each poll 4 times per day: 48 polls. So that's just one operation every 30 minutes. One poll, possibly followed by one update. Or, didn't you set it up so only one machine polled and all the other builds would follow it, serially? If not, that makes sense. Have one machine poll every 30 minutes. If it finds something, it builds, and the next one builds. If it finds nothing, then nothing occurs. Surely this would work ok? It merely serializes all of our Hudson jobs? Which is, granted, rather unfortunate. Adding machines should allow great parallelism. And CVS is read-mostly, so should handle plenty of load. "Read-mostly" being a property that makes systems easier to scale. I assume if I bothered to learn to use cvsup, it would help much? We'd have a few mirrors and it'd "fan out well"? e.g. 5 cvsup mirrors could each serve 5 cvs clients, 25 for the price of 5? - Jay > Date: Mon, 23 Aug 2010 09:57:04 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com; m3-support at elego.de > Subject: Re: [M3devel] changes in CM3 continuous integration setup > > Quoting Olaf Wagner : > > > AMD64_LINUX --> AMD64_DARWIN > > --> AMD64_FREEBSD -//-> PPC_DARWIN --> I386_DARWIN > > --> I386_NETBSD > > --> I386_OPENBSD > > --> SOLsun-opencsw-curent9s > > --> SOLsun-opencsw-curent10s > > --> I386_SOLARIS-opencsw-curent10x > > -//-> FreeBSD4 --> LINUXLIBC6 > > --> NT386 > > --> PPC_LINUX > > --> SPARC32_LINUX > > --> SOLgnu > > I've now cut off the subtrees at PPC_DARWIN and FreeBSD4, as the load > was still not much better. Those two poll now for themselves again, > but only once or twice a day, so that the number of CVS updates > and build runs should be further reduced. > > 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 Mon Aug 23 12:57:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 10:57:00 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com> References: , <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com> Message-ID: I noticed this too. Not sure yet where it comes from. Would folks mind if I removed "NetBSD2_i386" from the system completely? I don't think anybody uses it.. I386_NETBSD serves about the same purpose. - Jay > Date: Fri, 20 Aug 2010 14:58:09 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: VM for I386_NETBSD Hudson > > The installed cm3 still uses the wrong target platform name: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. > Fix config? > > Olaf > > Quoting Jay K : > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, > > pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 23 13:17:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 11:17:17 +0000 Subject: [M3devel] RTLinker.envp, instance removal? Message-ID: RTLinker exposes: envp instance envp is not entirely useless, but is redundant with Cstdlib.getenv, which is exposed through libm3/Env. RTLinker.envp appears somewhat broken on Windows, despite appearances that I tried to fix it. In particular, broken for gui apps. (btw, gui apps and console apps are far more the same than people realize; this whole business where Modula-3's main varies for each of them is unnecessary; the actual entry point for any Win32 console or gui app takes no parameters; the parameters the C runtime passes to main or WinMain are created by it based on stuff such as GetCommandLine, GetStartupInfo, etc.) instance is pretty much useless. Anyone that needs it can get it via GetModuleHandle(NULL); I suppose RTLinker.instance is more portable, as it'll reliably be null on posix -- ie: the #ifdef is built into startup/m3core, instead of the user's app. (on the other hand, there's probably nothing portable you can do with instance, given that it is useless on Posix) Anyway, on the general premise that less is more and things deemed buggy, of little value, and unused, are best just removed instead of fixed or improved, I propose removing both of these. Once I verify they are unused. ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 23 13:23:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 11:23:25 +0000 Subject: [M3devel] main in C or not? Message-ID: There has long been a configuration variable: MAIN_IN_C. I propose that main always be in C. I made that so already, a small change. I further propose that the support for main to not be in C be removed. "Not in C" is "generating it via the backend", directly an .obj for NT386, or going through the gcc backend for Posix. Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. I have this change about ready. I don't think avoiding C is valuable and I'd rather have fewer configuration variables. Pick one approach that works reasonably always. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 23 13:41:40 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Aug 2010 13:41:40 +0200 Subject: [M3devel] changes in CM3 continuous integration setup Message-ID: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> Quoting Jay K : > I don't really understand all of this. > Surely CVS can tolerate more than 10 "active" users? > Or is it really awful? > (or, most likely, both) > What if they all poll much less than once an hour? It's not just CVS. The machine is running our WWW services, FTP, CVSup, backup for several hosts and secondary mail services. > Let's say we have 12 machines. > Have them each poll 4 times per day: 48 polls. > So that's just one operation every 30 minutes. > One poll, possibly followed by one update. That would be an individual setup for all jobs regarding polling. It's of course possible, but more tedious work again. > Or, didn't you set it up so only one machine polled and all the > other builds would follow it, serially? > If not, that makes sense. > Have one machine poll every 30 minutes. > If it finds something, it builds, and the next one builds. > If it finds nothing, then nothing occurs. > Surely this would work ok? > It merely serializes all of our Hudson jobs? > Which is, granted, rather unfortunate. > Adding machines should allow great parallelism. > And CVS is read-mostly, so should handle plenty of load. > "Read-mostly" being > a property that makes systems easier to scale. The current setup is suboptimal. I've changed things in a way that could be done quickly. But it's not easy to foretell how any change will affect the load and responsiveness, as it isn't even clear where the limits are; and other services are continually competing for resources, too. I've set up continuous logging of system load, top and iotop. You can get a quick summary with this job: http://hudson.modula3.com:8080/view/zzz/job/sysload We'll monitor this for some days and see how our changes affect the situation. Complete logs are written to Hudson's ~/log/ directory. > I assume if I bothered to learn to use cvsup, it would help much? > We'd have a few mirrors and it'd "fan out well"? > e.g. 5 cvsup mirrors could each serve 5 cvs clients, 25 for the price of 5? I think we'd only need one CVS mirror that the continous integration could use. Unfortunately, our system administrator is on vacance (his wife's expecting their second baby) right now, and I haven't got any machine for that readily available. We'll sort that out, though; don't worry too much. It may need some weeks, but we'll find an acceptable solution without much limitations. 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 Mon Aug 23 13:57:01 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Aug 2010 13:57:01 +0200 Subject: [M3devel] main in C or not? In-Reply-To: References: Message-ID: <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Quoting Jay K : > There has long been a configuration variable: MAIN_IN_C. > > I propose that main always be in C. I made that so already, a small change. > > I further propose that the support for main to not be in C be removed. > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > going through the gcc backend for Posix. > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > I have this change about ready. > > I don't think avoiding C is valuable and I'd rather have fewer > configuration variables. > Pick one approach that works reasonably always. This requires that every user must have a C compiler in addition to cm3. I thought the default was not to generate C, and just require a C compiler for special runtime support. I'm not sure if this really a valid argument for the systems we support though, as we also need a system linker, and that is probably bundled with the C compiler in a development package. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 23 23:51:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 21:51:44 +0000 Subject: [M3devel] main in C or not? In-Reply-To: <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Mon Aug 23 23:54:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 21:54:17 +0000 Subject: [M3devel] RTLinker.envp, instance removal? In-Reply-To: References: Message-ID: envp is used at least by posix/RTArgs so will stay. I'll investigate further: ie. if it is used on Windows, test it and make it work, else maybe make it null. Still probably remove instance if it isn't used, I don't think it has a portable use. One could compare it to null to deduce Win32 vs. Posix but there is already Compiler.ThisOS or somesuch. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RTLinker.envp, instance removal? Date: Mon, 23 Aug 2010 11:17:17 +0000 RTLinker exposes: envp instance envp is not entirely useless, but is redundant with Cstdlib.getenv, which is exposed through libm3/Env. RTLinker.envp appears somewhat broken on Windows, despite appearances that I tried to fix it. In particular, broken for gui apps. (btw, gui apps and console apps are far more the same than people realize; this whole business where Modula-3's main varies for each of them is unnecessary; the actual entry point for any Win32 console or gui app takes no parameters; the parameters the C runtime passes to main or WinMain are created by it based on stuff such as GetCommandLine, GetStartupInfo, etc.) instance is pretty much useless. Anyone that needs it can get it via GetModuleHandle(NULL); I suppose RTLinker.instance is more portable, as it'll reliably be null on posix -- ie: the #ifdef is built into startup/m3core, instead of the user's app. (on the other hand, there's probably nothing portable you can do with instance, given that it is useless on Posix) Anyway, on the general premise that less is more and things deemed buggy, of little value, and unused, are best just removed instead of fixed or improved, I propose removing both of these. Once I verify they are unused. ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 23 23:55:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 21:55:55 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, Message-ID: > I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration > is ignored. Alternatively I can change cm3cfg.common. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] main in C or not? Date: Mon, 23 Aug 2010 21:51:44 +0000 Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 rcolebur at SCIRES.COM Tue Aug 24 00:10:15 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:06:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:06:04 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , Message-ID: Randy, yes, that is my same understanding, from fairly recent experience. They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: extern const int max_this = 100; extern const int max_that = 200; etc. Certain updates involve changes to that file, recompile it, relink. As such, not much of a C compiler is needed. On Itanium they do give you an ANSI compiler. The K&R compiler is enough of a compile to compile some gcc 3.x, from which you can compile current gcc (or just stick with 3.x I guess). I was able to do that. The K&R compiler I think is also enough to do 64bit work, but I think offers no shared libraries and no optimization. I haven't booted my HP-UX/hppa in months now, I doubt anyone cares much, and if anyone did, we could probably require either the ANSI compiler or gcc. Perhaps perhaps perhaps I'll bring the system back up and make sure our stuff all compiles ok K&R. Perhaps. It kind of muddies the code and even e.g. gcc 4.x can't be compiled with a K&R compiler, not even with the ansi2kr build-time conversion thingy -- which, btw, I'd be willing to try to use as a compromise. Anyway, while supporting HP-UX/hppa/itanium is on some "list", it might never make it to the top. Nobody seems interested in it. The great thing about a C generating backend if you can fairly honestly claim to support "all" systems while doing "zero" work. You know, consider: #include int main() { printf("hello\n"); return 0; } What does it work on? Pretty much "everything" -- everything with a C compiler and stdio. How much porting work? Pretty much "zero". I say "fairly honestly" because there is still a small amount of #ifdef in the C code. Though the amount of #ifdef we have at present is fairly small and the number of systems it supports is fairly large. And even the generated C code might have some system-dependencies to be smushed out perhaps. autoconf might help. The C-generating backend would theoretically and really probably for real work with HP-UX, AIX, Irix, Android, iPhone, VMS, etc. besides the usual assortment of NT (including AMD64, IA64), Linux, Solaris, FreeBSD, NetBSD, OpenBSD (modulo the threading/context problems), Darwin. (iPhone has a problem with the signal headers perhaps). - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: Re: [M3devel] main in C or not? Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:06:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:06:14 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , Message-ID: Randy, yes, that is my same understanding, from fairly recent experience. They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: extern const int max_this = 100; extern const int max_that = 200; etc. Certain updates involve changes to that file, recompile it, relink. As such, not much of a C compiler is needed. On Itanium they do give you an ANSI compiler. The K&R compiler is enough of a compile to compile some gcc 3.x, from which you can compile current gcc (or just stick with 3.x I guess). I was able to do that. The K&R compiler I think is also enough to do 64bit work, but I think offers no shared libraries and no optimization. I haven't booted my HP-UX/hppa in months now, I doubt anyone cares much, and if anyone did, we could probably require either the ANSI compiler or gcc. Perhaps perhaps perhaps I'll bring the system back up and make sure our stuff all compiles ok K&R. Perhaps. It kind of muddies the code and even e.g. gcc 4.x can't be compiled with a K&R compiler, not even with the ansi2kr build-time conversion thingy -- which, btw, I'd be willing to try to use as a compromise. Anyway, while supporting HP-UX/hppa/itanium is on some "list", it might never make it to the top. Nobody seems interested in it. The great thing about a C generating backend if you can fairly honestly claim to support "all" systems while doing "zero" work. You know, consider: #include int main() { printf("hello\n"); return 0; } What does it work on? Pretty much "everything" -- everything with a C compiler and stdio. How much porting work? Pretty much "zero". I say "fairly honestly" because there is still a small amount of #ifdef in the C code. Though the amount of #ifdef we have at present is fairly small and the number of systems it supports is fairly large. And even the generated C code might have some system-dependencies to be smushed out perhaps. autoconf might help. The C-generating backend would theoretically and really probably for real work with HP-UX, AIX, Irix, Android, iPhone, VMS, etc. besides the usual assortment of NT (including AMD64, IA64), Linux, Solaris, FreeBSD, NetBSD, OpenBSD (modulo the threading/context problems), Darwin. (iPhone has a problem with the signal headers perhaps). - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: Re: [M3devel] main in C or not? Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:12:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:12:14 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , Message-ID: Randy, yes, that is my same understanding, from fairly recent experience. They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: extern const int max_this = 100; extern const int max_that = 200; etc. Certain updates involve changes to that file, recompile it, relink. As such, not much of a C compiler is needed. On Itanium they do give you an ANSI compiler. The K&R compiler is enough of a compile to compile some gcc 3.x, from which you can compile current gcc (or just stick with 3.x I guess). I was able to do that. The K&R compiler I think is also enough to do 64bit work, but I think offers no shared libraries and no optimization. I haven't booted my HP-UX/hppa in months now, I doubt anyone cares much, and if anyone did, we could probably require either the ANSI compiler or gcc. Perhaps perhaps perhaps I'll bring the system back up and make sure our stuff all compiles ok K&R. Perhaps. It kind of muddies the code and even e.g. gcc 4.x can't be compiled with a K&R compiler, not even with the ansi2kr build-time conversion thingy -- which, btw, I'd be willing to try to use as a compromise. Anyway, while supporting HP-UX/hppa/itanium is on some "list", it might never make it to the top. Nobody seems interested in it. The great thing about a C generating backend if you can fairly honestly claim to support "all" systems while doing "zero" work. You know, consider: #include int main() { printf("hello\n"); return 0; } What does it work on? Pretty much "everything" -- everything with a C compiler and stdio. How much porting work? Pretty much "zero". I say "fairly honestly" because there is still a small amount of #ifdef in the C code. Though the amount of #ifdef we have at present is fairly small and the number of systems it supports is fairly large. And even the generated C code might have some system-dependencies to be smushed out perhaps. autoconf might help. The C-generating backend would theoretically and really probably for real work with HP-UX, AIX, Irix, Android, iPhone, VMS, etc. besides the usual assortment of NT (including AMD64, IA64), Linux, Solaris, FreeBSD, NetBSD, OpenBSD (modulo the threading/context problems), Darwin. (iPhone has a problem with the signal headers perhaps). - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: Re: [M3devel] main in C or not? Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:21:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:21:13 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , , , , Message-ID: (sorry, some hotmail error caused 3 sends) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Aug 24 03:06:41 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 23 Aug 2010 21:06:41 -0400 Subject: [M3devel] main in C or not? In-Reply-To: References: Message-ID: <20100824010641.GA22229@topoi.pooq.com> On Tue, Aug 24, 2010 at 12:12:14AM +0000, Jay K wrote: > > Randy, yes, that is my same understanding, from fairly recent experience. > > > They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: > extern const int max_this = 100; > extern const int max_that = 200; > etc. > > > Certain updates involve changes to that file, recompile it, relink. > As such, not much of a C compiler is needed. Watch out for binary libraries fetched in by the C compiler. Depending on license, they may prohibit making a binary distribution. -- hendrik From hosking at cs.purdue.edu Tue Aug 24 03:14:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 23 Aug 2010 21:14:52 -0400 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> 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 23 Aug 2010, at 17:51, Jay K wrote: > Hm. Interesting subtle angle you point out. > I have seen very few systems with ld but not cc. e.g. OLPC default install. > My HP-UX/hppa machine came with only a K&R cc. > Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. > AIX maybe also. > We could potentially call ld directly. > But in general I don't write the configuration files that way, they run cc for linking. > *.c is used a bunch in m3core but not much else. > > > On the other hand: > cc is fairly ubiquitous. > We have a "plan" for a "new distribution format" that will require cc -- users will build more of the > system. Though we'll still provide binaries for some systems. > > > I'm *really* interested in a C-generating backend, which will subsume this. How will source-level debugging work in this instance? > Except perhaps systems like NT386, and maybe we'll expand that set. > I'm becoming increasingly frustrated with the gcc backend. > > > I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration > is ignored. > > > I'll still go ahead and make the C code typesafe via ANSI prototypes. > (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef > all the breakage, or require an ANSI compiler such as gcc; I assume nobody really > cares about K&R). > > > Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, > but I admit I didn't fully debug these. And then, removing variations among configurations, I like. > But that can be achieved via the small change for now and leaving the support in. > > > - Jay > > > Date: Mon, 23 Aug 2010 13:57:01 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] main in C or not? > > > > Quoting Jay K : > > > > > There has long been a configuration variable: MAIN_IN_C. > > > > > > I propose that main always be in C. I made that so already, a small change. > > > > > > I further propose that the support for main to not be in C be removed. > > > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > > going through the gcc backend for Posix. > > > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > > > I have this change about ready. > > > > > > I don't think avoiding C is valuable and I'd rather have fewer > > > configuration variables. > > > Pick one approach that works reasonably always. > > > > This requires that every user must have a C compiler in addition to > > cm3. I thought the default was not to generate C, and just require > > a C compiler for special runtime support. > > > > I'm not sure if this really a valid argument for the systems we support > > though, as we also need a system linker, and that is probably bundled with > > the C compiler in a development package. > > > > 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 Tue Aug 24 06:50:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 04:50:38 +0000 Subject: [M3devel] main in C or not? In-Reply-To: <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> Message-ID: >> [Jay] I'm *really* interested in a C-generating backend, which will subsume this. > [Tony How will source-level debugging work in this instance? #line directiives should be used. stock gdb will have very good type information where today it has virtually none. Besides the other debuggers like windbg/VisualStudio. Expressions would be in C perhaps. You could still hack on m3gdb if you really want, but it seems of reduced utility. Compilation would likely be slower. It might be a few steps backwards besides a few steps forward. I find the lure of portability and possibly much improved exception handling (where applicable in C, else in C++), and source distribution, a very high benefit and worth some tradeoff. We'd also lose the GPL, which would please some people. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 24 07:26:14 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 24 Aug 2010 07:26:14 +0200 Subject: [M3devel] main in C or not? also, backend.... In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> , , <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> Message-ID: <1282627574.2694.37.camel@localhost> Looks like a lobotomy for me. GNU Pascal folks are on similar crossroads now, only they are forced because they follow GCC changes "in realtime", as opposed to fixed version approach used by cm3. C *is* assembly and approach, except this debugger/debugging lobotomy thing, is sound. Except - there are better assemblies, and if we are divorcing cm3 from GCC then let's do it properly - going LLVM way. On Tue, 2010-08-24 at 04:50 +0000, Jay K wrote: > stock gdb will have very good type information where today it has > virtually none. > Besides the other debuggers like windbg/VisualStudio. > Expressions would be in C perhaps. > You could still hack on m3gdb if you really want, but it seems of > reduced utility. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 24 07:46:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 05:46:48 +0000 Subject: [M3devel] main in C or not? also, backend.... In-Reply-To: <1282627574.2694.37.camel@localhost> References: ,, , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>,, ,, <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu>, , <1282627574.2694.37.camel@localhost> Message-ID: You could say the same thing about the gcc internal representation, but no. C is a much more portable more documented more implemented more known assembly. - Jay > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Tue, 24 Aug 2010 07:26:14 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? also, backend.... > > Looks like a lobotomy for me. > > GNU Pascal folks are on similar crossroads now, only they are forced > because they follow GCC changes "in realtime", as opposed to fixed > version approach used by cm3. > > C *is* assembly and approach, except this debugger/debugging lobotomy > thing, is sound. Except - there are better assemblies, and if we are > divorcing cm3 from GCC then let's do it properly - going LLVM way. > > On Tue, 2010-08-24 at 04:50 +0000, Jay K wrote: > > stock gdb will have very good type information where today it has > > virtually none. > > Besides the other debuggers like windbg/VisualStudio. > > Expressions would be in C perhaps. > > You could still hack on m3gdb if you really want, but it seems of > > reduced utility. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 08:02:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 06:02:05 +0000 Subject: [M3devel] remove/rename NT386GNU/NT386MINGNU Message-ID: I'm assuming nobody here uses NT386GNU or NT386MINGNU. I'll remove them. They are replaced by I386_CYGWIN, I386_MINGW, which I think also nobody uses. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 08:18:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 06:18:50 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: , <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com>, Message-ID: aha, regression/defs.sh copied all the uname stuff out of sysinfo.sh.. I hand fixed the config already but will fix defs.sh.. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: VM for I386_NETBSD Hudson Date: Mon, 23 Aug 2010 10:57:00 +0000 I noticed this too. Not sure yet where it comes from. Would folks mind if I removed "NetBSD2_i386" from the system completely? I don't think anybody uses it.. I386_NETBSD serves about the same purpose. - Jay > Date: Fri, 20 Aug 2010 14:58:09 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: VM for I386_NETBSD Hudson > > The installed cm3 still uses the wrong target platform name: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. > Fix config? > > Olaf > > Quoting Jay K : > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, > > pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 08:51:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 06:51:04 +0000 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> References: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> Message-ID: Olaf, ssh and cvs are usually failing now. It is quite bad now. I have to retry cvs -z3 diff and cvs -z3 commit multiple times to get them to work. - Jay > Date: Mon, 23 Aug 2010 13:41:40 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] changes in CM3 continuous integration setup > > Quoting Jay K : > > > I don't really understand all of this. > > Surely CVS can tolerate more than 10 "active" users? > > Or is it really awful? > > (or, most likely, both) > > What if they all poll much less than once an hour? > > It's not just CVS. The machine is running our WWW services, FTP, > CVSup, backup for several hosts and secondary mail services. > > > Let's say we have 12 machines. > > Have them each poll 4 times per day: 48 polls. > > So that's just one operation every 30 minutes. > > One poll, possibly followed by one update. > > That would be an individual setup for all jobs regarding polling. > It's of course possible, but more tedious work again. > > > Or, didn't you set it up so only one machine polled and all the > > other builds would follow it, serially? > > If not, that makes sense. > > Have one machine poll every 30 minutes. > > If it finds something, it builds, and the next one builds. > > If it finds nothing, then nothing occurs. > > Surely this would work ok? > > It merely serializes all of our Hudson jobs? > > Which is, granted, rather unfortunate. > > Adding machines should allow great parallelism. > > And CVS is read-mostly, so should handle plenty of load. > > "Read-mostly" being > > a property that makes systems easier to scale. > > The current setup is suboptimal. > I've changed things in a way that could be done quickly. > But it's not easy to foretell how any change will affect the load > and responsiveness, as it isn't even clear where the limits are; and > other services are continually competing for resources, too. > > I've set up continuous logging of system load, top and iotop. > You can get a quick summary with this job: > > http://hudson.modula3.com:8080/view/zzz/job/sysload > > We'll monitor this for some days and see how our changes affect > the situation. > > Complete logs are written to Hudson's ~/log/ directory. > > > I assume if I bothered to learn to use cvsup, it would help much? > > We'd have a few mirrors and it'd "fan out well"? > > e.g. 5 cvsup mirrors could each serve 5 cvs clients, 25 for the price of 5? > > I think we'd only need one CVS mirror that the continous integration > could use. Unfortunately, our system administrator is on vacance (his wife's > expecting their second baby) right now, and I haven't got any machine > for that readily available. > > We'll sort that out, though; don't worry too much. It may need some > weeks, but we'll find an acceptable solution without much limitations. > > 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 wagner at elegosoft.com Tue Aug 24 09:55:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 09:55:42 +0200 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: References: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> Message-ID: <20100824095542.gsanecbbgko0c8w0@mail.elegosoft.com> Quoting Jay K : > Olaf, ssh and cvs are usually failing now. It is quite bad now. > I have to retry cvs -z3 diff and cvs -z3 commit multiple times to > get them to work. No use to retry in such situations, better wait a quarter of an hour. Yes, that's one of those outages we have observed for some time now. I happened to notice and observe this one. I think it was caused by two backup processes using most of the i/o bandwidth and then several CVS server instances pile up while waiting for disk blocks and prevent each other from making much progress. I think we really need a CVS mirror (as we cannot easily improve the i/o system). Sigh. I tried to stop most of the CVS processes, but response and recovery was very slow nonetheless. Things should have calmed down in the meantime 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 Tue Aug 24 10:53:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 10:53:44 +0200 Subject: [M3devel] changes in CM3 continuous integration setup Message-ID: <20100824105344.eeeppqbtus4skgoc@mail.elegosoft.com> >> AMD64_LINUX --> AMD64_DARWIN >> --> AMD64_FREEBSD -//-> PPC_DARWIN --> I386_DARWIN >> --> I386_NETBSD >> --> I386_OPENBSD >> --> SOLsun-opencsw-curent9s >> --> SOLsun-opencsw-curent10s >> --> I386_SOLARIS-opencsw-curent10x >> -//-> FreeBSD4 --> LINUXLIBC6 >> --> NT386 >> --> PPC_LINUX >> --> SPARC32_LINUX >> --> SOLgnu changed again -- further reduce build load two continuous integration servers on AMD64 and SPARC architecture AMD64_FREEBSD polls for changes every 15 minutes \------> SOLsun-opencsw-curent10s AMD64_LINUX polls once per day 23:20/55 PPC_DARWIN polls once per day 22:22/52 \----> I386_DARWIN \---> I386_NETBSD \--> I386_OPENBSD FreeBSD4 polls once per day 21:14/40 \--------> LINUXLIBC6 \-------> NT386 \------> PPC_LINUX SOLsun-opencsw-curent9s polls once per day 1:14/44 \------> I386_SOLARIS-opencsw-curent10x AMD64_DARWIN polls once per day 0:18/48 SPARC32_LINUX polls once per day 3:18/48 SOLgnu on demand only (--> opencsw job) SOLsun on demand only (--> opencsw job) Further changes to reduce build and CVS load may be made until we've set up a CVS mirror or moved away other services from birch. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 24 10:59:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 08:59:08 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: , <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com>, , Message-ID: This worked now. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: VM for I386_NETBSD Hudson Date: Tue, 24 Aug 2010 06:18:50 +0000 aha, regression/defs.sh copied all the uname stuff out of sysinfo.sh.. I hand fixed the config already but will fix defs.sh.. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: VM for I386_NETBSD Hudson Date: Mon, 23 Aug 2010 10:57:00 +0000 I noticed this too. Not sure yet where it comes from. Would folks mind if I removed "NetBSD2_i386" from the system completely? I don't think anybody uses it.. I386_NETBSD serves about the same purpose. - Jay > Date: Fri, 20 Aug 2010 14:58:09 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: VM for I386_NETBSD Hudson > > The installed cm3 still uses the wrong target platform name: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. > Fix config? > > Olaf > > Quoting Jay K : > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, > > pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 11:40:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 09:40:20 +0000 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100824105344.eeeppqbtus4skgoc@mail.elegosoft.com> References: <20100824105344.eeeppqbtus4skgoc@mail.elegosoft.com> Message-ID: It's still seeming really bad for me..can't work this way.. - Jay > Date: Tue, 24 Aug 2010 10:53:44 +0200 > From: wagner > To: m3devel > Subject: Re: [M3devel] changes in CM3 continuous integration setup > > changed again -- further reduce build load -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 24 12:37:30 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 24 Aug 2010 12:37:30 +0200 Subject: [M3devel] ***SPAM*** RE: main in C or not? also, backend.... In-Reply-To: References: ,, , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> ,, ,, <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> , ,<1282627574.2694.37.camel@localhost> Message-ID: <1282646250.3321.35.camel@localhost> And with C you divorce source level from debugging. Also, Modula-3 was there, early in it's lifetime. For some reason, SRC team went debate-RMS route. IMO, it's better to make effort for better dwarf info to object code, and even better to go LLVM. On Tue, 2010-08-24 at 05:46 +0000, Jay K wrote: > You could say the same thing about the gcc internal representation, > but no. > C is a much more portable more documented more implemented more known > assembly. > > - Jay > > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Tue, 24 Aug 2010 07:26:14 +0200 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] main in C or not? also, backend.... > > > > Looks like a lobotomy for me. > > > > GNU Pascal folks are on similar crossroads now, only they are forced > > because they follow GCC changes "in realtime", as opposed to fixed > > version approach used by cm3. > > > > C *is* assembly and approach, except this debugger/debugging > lobotomy > > thing, is sound. Except - there are better assemblies, and if we are > > divorcing cm3 from GCC then let's do it properly - going LLVM way. > > > > On Tue, 2010-08-24 at 04:50 +0000, Jay K wrote: > > > stock gdb will have very good type information where today it has > > > virtually none. > > > Besides the other debuggers like windbg/VisualStudio. > > > Expressions would be in C perhaps. > > > You could still hack on m3gdb if you really want, but it seems of > > > reduced utility. > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From wagner at elegosoft.com Tue Aug 24 17:08:47 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 17:08:47 +0200 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: <20100824170847.alrnx5h5q8wg484k@mail.elegosoft.com> Quoting Jay K : > I'm *really* interested in a C-generating backend, which will subsume this. > Except perhaps systems like NT386, and maybe we'll expand that set. > I'm becoming increasingly frustrated with the gcc backend. The tide comes and goes. The DEC SRC people were very frustrated with the C-generating M3 compiler long ago, and invested large efforts to build the gcc backend ;-) I think I remember that Bill Kalsow, who wrote much of the original compiler code, said that "C was a very mediocre choice as an intermediate language". (It may have been somebody else who said this though.) > I can compromise and leave the code in m3linker, but I still like > the change in cm3 where the configuration > is ignored. Yes, I think we should not unnecessarily remove this. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 24 17:17:28 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 17:17:28 +0200 Subject: [M3devel] remove/rename NT386GNU/NT386MINGNU In-Reply-To: References: Message-ID: <20100824171728.ti1edlk740owc84k@mail.elegosoft.com> Quoting Jay K : > > I'm assuming nobody here uses NT386GNU or NT386MINGNU. > I'll remove them. > They are replaced by I386_CYGWIN, I386_MINGW, which I think also nobody uses. I would like to add a Cygwin build to our Hudson setup, if only the elego-win-vm wasn't so slow and so much offline. 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 Aug 26 11:45:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 09:45:01 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? Message-ID: Olaf, I have some temporary so far hypothetical interest in trying gcc 4.3.0 again -- the SOLgnu/SOLsun problem with 4.3.5. ? Really, hopefully that's not something needed long term. I have some possibly lasting so far hypothetical interest in another gcc fork -- to fork OpenBSD's 4.2.1. ?Though I guess I can try to apply their patches to 4.5.1. It is trivial and reasonable? Or it would be a pain in Hudson? ? In paritcular the notion of gcc-openbsd in a separate repository? ? I actually think maybe we should use gcc-apple for *_DARWIN but Tony disagreed and mainline seems ok. ? It is for ARM_DARWIN, which isn't in great shape (Hudson?! :) ) I'm open to moving the existing gcc (gcc-4.3/gcc-4.3.5) to its own repository. And the existing gcc-apple to its own. (Besides, a C backends wipes this all away. : ) ) I don't much like CVS but I have slowly learned to use it a bit. ? My favorite by far by far is Perforce. We could possibly use it free for open source work. ? I have lots of experience with it. It is fast. It has good gui. It has atomic changes. It does branching right (unlike svn which does branching completely wrong) I have no experience with anything else -- svn, mtn, git, hg, etc. ?- Jay From jay.krell at cornell.edu Thu Aug 26 11:46:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 09:46:54 +0000 Subject: [M3devel] moving the old gcc-4.1.1? Message-ID: Olaf, would be reasonable, easy, profitable to move the old: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.1.1/ to its own repository? Just a simple mv and done? ? Or more involved, e.g. to update existing CVS checkouts? I believe its presence slows down everyone's update/checkout. And benefits only folks interested in "archaelogoy". Maybe a gcc-4.1.1/readme.txt could be dropped in pointing to the new location? ?- Jay From wagner at elegosoft.com Thu Aug 26 12:59:16 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 26 Aug 2010 12:59:16 +0200 Subject: [M3devel] additional CVS repositories for additional gcc forks? Message-ID: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> Quoting Jay K : > Olaf, I have some temporary so far hypothetical interest in trying > gcc 4.3.0 again -- the SOLgnu/SOLsun problem with 4.3.5. > ? Really, hopefully that's not something needed long term. > > I have some possibly lasting so far hypothetical interest in another > gcc fork -- to fork OpenBSD's 4.2.1. > ?Though I guess I can try to apply their patches to 4.5.1. > > It is trivial and reasonable? > Or it would be a pain in Hudson? The main problem wrt. performance and i/o load is importing different gcc versions in different directories and not as different versions. Thus they get stored as lots of new different files, which all need to be read and their directories locked. The gcc structure is huge compared to all the M3 code. Of course, if we use the gcc versions in parallel, i.e. they are variants in one of our configuration, this is actually needed. It might help if you postpone your gcc projects for some weeks until we've either moved our WWW services or setup a repository mirror or whatever. > ? In paritcular the notion of gcc-openbsd in a separate repository? > ? I actually think maybe we should use gcc-apple for *_DARWIN but > Tony disagreed and mainline seems ok. > ? It is for ARM_DARWIN, which isn't in great shape (Hudson?! :) ) > > I'm open to moving the existing gcc (gcc-4.3/gcc-4.3.5) to its own > repository. > And the existing gcc-apple to its own. I wouldn't like to change much now, just remove what we really don't need. > (Besides, a C backends wipes this all away. : ) ) No. I would see a C backend as a variant (option) too, but probably not use it on platforms were I can compile without it. > I don't much like CVS but I have slowly learned to use it a bit. > ? My favorite by far by far is Perforce. We could possibly use it > free for open source work. Perforce is nice, agreed. I haven't used it much in practice though. I'm not sure how much effort it would cost us to get a Perforce setup, and if all users would be comfortable with it. > I have lots of experience with it. It is fast. It has good gui. It > has atomic changes. It does branching right (unlike svn which does > branching completely wrong) I wouldn't say that, though subversion still has several severe problems with merging, especially tree merges. > I have no experience with anything else -- svn, mtn, git, hg, etc. We (Elego) have, but the experience of the M3 developers will vary very much I think. Git may be an interesting option, though I'm not sure if it is really mature enough and has got all the infrastructure support we may need. We've got commercial customers who are thinking about switching over to it completely though. As I've said before, switching to another version control system will involve much tedious work, and I cannot contribute much (time) for that. However, if the M3 community decides to use something different and plans and implements a reasonable migration to the new tool(s), I wouldn't object to that. 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 Thu Aug 26 13:03:33 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 26 Aug 2010 13:03:33 +0200 Subject: [M3devel] moving the old gcc-4.1.1? In-Reply-To: References: Message-ID: <20100826130333.i4d6awas088g0cw0@mail.elegosoft.com> Quoting Jay K : > Olaf, would be reasonable, easy, profitable to move the old: > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.1.1/ > > to its own repository? > Just a simple mv and done? > ? Or more involved, e.g. to update existing CVS checkouts? > > I believe its presence slows down everyone's update/checkout. > And benefits only folks interested in "archaelogoy". > > Maybe a gcc-4.1.1/readme.txt could be dropped in pointing to the new > location? We can just move it to another path in /usr/cvs, i.e. /usr/cvs/unused/cm3/m3cc/gcc-4.11 or however you'd like to call it. I'm not sure if the updates will just complain that something has vanished from the repository (I think so) or if they will fail: we need to check this. 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 Aug 26 13:34:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 11:34:54 +0000 Subject: [M3devel] passing structs by value Message-ID: On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. I really can't follow the complicated rules here: ?? http://www.x86-64.org/documentation/abi-0.99.pdf? but suffice it to say, records can be passed in registers, but it depends on the types of their fields. As much as we don't pass/return records by value between Modula-3 and C, that is ok. As long as Modula-3 callers/recievers agree. And they do, but... The gcc backend is given good type information at first, but historically throws much of it away. As you start to repair that, it starts following the ABI. At least at the callee side. I think the caller is still devoid of type information. I'm assuming there is a fallback rule for the case of missing type information. So if you give just one side the type information, you get a mismatch, bad code. Passing records in registers is nice, but.. (reminder: I think historically we never did). I thin we should probably just change the frontend to handle passing records by value itself. Like it does for I386_NT/NT386. For any record parameter, introduce a temporary in the caller and pass its address. ? Or whatever the code is already prepared to do. We should probably handle records returned by value similarly. This decision can be revisited if/when there is a C backend. Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. I doubt anyone else is either. I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. Further long term deficiencies this uncovers, I'm very inclined to dig further into. The right fix is probably to maintain types in the expression stack. Or at least throw in more casts on the pops. I don't think pop_param presently recieves enough type information -- no type id. ?- Jay From jay.krell at cornell.edu Thu Aug 26 13:36:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 11:36:51 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: Message-ID: aka: I propose Target.i3 standard_structs always be true, and therefore remove it and propagate true through m3front. Or at least make it always true and leave the code in m3front for future generations to revisit.. I will go ahead and test this. ? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: passing structs by value > Date: Thu, 26 Aug 2010 11:34:54 +0000 > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > I really can't follow the complicated rules here: > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > As long as Modula-3 callers/recievers agree. And they do, but... > > > The gcc backend is given good type information at first, but historically throws much of it away. > As you start to repair that, it starts following the ABI. At least at the callee side. > I think the caller is still devoid of type information. > I'm assuming there is a fallback rule for the case of missing type information. > > So if you give just one side the type information, you get a mismatch, bad code. > > > Passing records in registers is nice, but.. > (reminder: I think historically we never did). > > > I thin we should probably just change the frontend to handle passing records by value itself. > Like it does for I386_NT/NT386. > > > For any record parameter, introduce a temporary in the caller and pass its address. > Or whatever the code is already prepared to do. > > > We should probably handle records returned by value similarly. > > > This decision can be revisited if/when there is a C backend. > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > I doubt anyone else is either. > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > The right fix is probably to maintain types in the expression stack. > Or at least throw in more casts on the pops. > > > I don't think pop_param presently recieves enough type information -- no type id. > > > - Jay > From jay.krell at cornell.edu Thu Aug 26 13:46:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 11:46:13 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> Message-ID: > No. I would see a C backend as a variant (option) too, but probably not > use it on platforms were I can compile without it. I would like to see a C backend at least replace the gcc backend. We could maybe then slowly iterate on the integrated backend. Or LLVM. It would provide more obvious correctness, better debugging, better code quality. Imagine -- basically all platforms would get stack walkers. By generating C++ for most platforms, or using C exception handling in NT/VMS/Tru64. Basically all platforms would just work. Stock debuggers would work, gdb and others. Basically no more porting. Basically all optimizations could be enabled. (Aside: I think the generated C would be sure to store gc roots in volatile locals, but not otherwise use said volatiles.) And in more recent developments, it would enregister some records passed by value. It would, in a sense, shrink the code base (cheating sort of). I'm not holding my breath on any of this. But I'm going to start trying to do more and talk less about it. - Jay ---------------------------------------- > Date: Thu, 26 Aug 2010 12:59:16 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: additional CVS repositories for additional gcc forks? > > Quoting Jay K : > > > Olaf, I have some temporary so far hypothetical interest in trying > > gcc 4.3.0 again -- the SOLgnu/SOLsun problem with 4.3.5. > > Really, hopefully that's not something needed long term. > > > > I have some possibly lasting so far hypothetical interest in another > > gcc fork -- to fork OpenBSD's 4.2.1. > > Though I guess I can try to apply their patches to 4.5.1. > > > > It is trivial and reasonable? > > Or it would be a pain in Hudson? > > The main problem wrt. performance and i/o load is importing different > gcc versions in different directories and not as different versions. > Thus they get stored as lots of new different files, which all need > to be read and their directories locked. The gcc structure is huge > compared to all the M3 code. Of course, if we use the gcc versions in > parallel, i.e. they are variants in one of our configuration, this > is actually needed. > > It might help if you postpone your gcc projects for some weeks until > we've either moved our WWW services or setup a repository mirror or > whatever. > > > In paritcular the notion of gcc-openbsd in a separate repository? > > I actually think maybe we should use gcc-apple for *_DARWIN but > > Tony disagreed and mainline seems ok. > > It is for ARM_DARWIN, which isn't in great shape (Hudson?! :) ) > > > > I'm open to moving the existing gcc (gcc-4.3/gcc-4.3.5) to its own > > repository. > > And the existing gcc-apple to its own. > > I wouldn't like to change much now, just remove what we really don't > need. > > > (Besides, a C backends wipes this all away. : ) ) > > No. I would see a C backend as a variant (option) too, but probably not > use it on platforms were I can compile without it. > > > I don't much like CVS but I have slowly learned to use it a bit. > > My favorite by far by far is Perforce. We could possibly use it > > free for open source work. > > Perforce is nice, agreed. I haven't used it much in practice though. > I'm not sure how much effort it would cost us to get a Perforce setup, > and if all users would be comfortable with it. > > > I have lots of experience with it. It is fast. It has good gui. It > > has atomic changes. It does branching right (unlike svn which does > > branching completely wrong) > > I wouldn't say that, though subversion still has several severe problems > with merging, especially tree merges. > > > I have no experience with anything else -- svn, mtn, git, hg, etc. > We (Elego) have, but the experience of the M3 developers will vary > very much I think. > > Git may be an interesting option, though I'm not sure if it is really > mature enough and has got all the infrastructure support we may need. > We've got commercial customers who are thinking about switching over to > it completely though. > > As I've said before, switching to another version control system will > involve much tedious work, and I cannot contribute much (time) > for that. However, if the M3 community decides to use something > different and plans and implements a reasonable migration to the > new tool(s), I wouldn't object to that. > > 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 Thu Aug 26 14:10:22 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 26 Aug 2010 14:10:22 +0200 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> Message-ID: <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> Quoting Jay K : > > No. I would see a C backend as a variant (option) too, but probably not > > use it on platforms were I can compile without it. > > I would like to see a C backend at least replace the gcc backend. > We could maybe then slowly iterate on the integrated backend. Or LLVM. > It would provide more obvious correctness, better debugging, better > code quality. I don't really see that yet. > Imagine -- basically all platforms would get stack walkers. > By generating C++ for most platforms, or using C exception > handling in NT/VMS/Tru64. > Basically all platforms would just work. I doubt that very much. > Stock debuggers would work, gdb and others. > Basically no more porting. > Basically all optimizations could be enabled. > (Aside: I think the generated C would be sure to store > gc roots in volatile locals, but not otherwise use said volatiles.) As I said: it has been tried before. > And in more recent developments, it would enregister some records > passed by value. > It would, in a sense, shrink the code base (cheating sort of). And it would be an order of magnitude slower. > I'm not holding my breath on any of this. > But I'm going to start trying to do more and talk less about it. I will let you convince me ;-) I've got no problem with trying that. If it's really better, we will use it. If not, we may want to use it for special situations (e.g. porting). 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 Aug 26 14:23:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 12:23:36 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> Message-ID: ?>? better code quality Use the native C++ exception handling. Not more calling setjmp all over the place. Inlining. Currnetly disabled in 4.5.1 because it breaks things. LTO/LTCG -- which we could get today, on gcc platforms, if we are willing to import even more code. ?(link time optimization, link time code gen). e.g. cross module inlining. see also PGO -- profile guided optimization. i.e. whatever the full C/C++ toolset is, you can use it. ?> better debugging ? Existing debuggers would work and work well. Notice today that NT386 has only line numbers. That there are systems that don't support stabs -- e.g. HP-UX. That other -g switches to cm3cg crash. > > Basically all platforms would just work. > > I doubt that very much. It's only a slight exaggeration. We'd still need our #ifdef'ing of the C code. Possibly guided by autoconf. And there are still the threading/gc issues. But for example, we should work on any processor for any operating system for which we already work -- NT, Linux, NetBSD, FreeBSD, Solaris, OSF -- on any processors. And AIX, Irix, VMS would work or be closer to working. (IA64 might need an #ifdef) Anyway, I'll try to work on it. > And it would be an order of magnitude slower. It would be slower. I'm not sure by how much. ?- Jay ---------------------------------------- > Date: Thu, 26 Aug 2010 14:10:22 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? > > Quoting Jay K : > > > > No. I would see a C backend as a variant (option) too, but probably not > > > use it on platforms were I can compile without it. > > > > I would like to see a C backend at least replace the gcc backend. > > We could maybe then slowly iterate on the integrated backend. Or LLVM. > > It would provide more obvious correctness, better debugging, better > > code quality. > > I don't really see that yet. > > > Imagine -- basically all platforms would get stack walkers. > > By generating C++ for most platforms, or using C exception > > handling in NT/VMS/Tru64. > > Basically all platforms would just work. > > I doubt that very much. > > > Stock debuggers would work, gdb and others. > > Basically no more porting. > > Basically all optimizations could be enabled. > > (Aside: I think the generated C would be sure to store > > gc roots in volatile locals, but not otherwise use said volatiles.) > > As I said: it has been tried before. > > > And in more recent developments, it would enregister some records > > passed by value. > > It would, in a sense, shrink the code base (cheating sort of). > > And it would be an order of magnitude slower. > > > I'm not holding my breath on any of this. > > But I'm going to start trying to do more and talk less about it. > > I will let you convince me ;-) > I've got no problem with trying that. If it's really better, we will > use it. If not, we may want to use it for special situations (e.g. porting). > > 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 Aug 27 08:14:05 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 08:14:05 +0200 Subject: [M3devel] Fwd: [CM3] #1148: CVSup stalls on several platforms Message-ID: <20100827081405.vw7d059ulcg8wgcc@mail.elegosoft.com> FYI -- I thought this was working, but it's still broken... ----- Forwarded message from bugs at elego.de ----- Date: Fri, 27 Aug 2010 06:05:05 -0000 From: CM3 Reply-To: CM3 Subject: [CM3] #1148: CVSup stalls on several platforms To: wagner at elego.de #1148: CVSup stalls on several platforms --------------------------+------------------------------------------------- Reporter: wagner | Owner: wagner Type: sw-bug | Status: new Priority: high | Milestone: CM3 Release 5.9 Component: misc | Version: 5.8-RC3 Severity: serious | Keywords: cvsup, stalling, hanging, pthreads Relnote: | Org: Estimatedhours: 0 | Hours: 0 Billable: 0 | Totalhours: 0 Internal: 0 | --------------------------+------------------------------------------------- Htr: try to mirror the cm3 repository, possible any other, too Fix: Env: --------------------------+------------------------------------------------- We either still have a problem with fork, or in the pthreads implementation. Here's some evidence from a mail thread: I do, but I'm having trouble with cvsup from release_branch_cm3_5_8 LINUXLIB6. It stalls and hangs after a few minutes. strace says this forever: clone(child_stack=0xb140f4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb140fbd8, {entry_number:6, base_addr:0xb140fb90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb140fbd8) = 20265 write(1, "Running\n"..., 8Running ) = 8 futex(0x80ac0cc, FUTEX_WAIT, 5, NULL) = -1 EINTR (Interrupted system call) --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- rt_sigsuspend(~[INT QUIT ABRT TERM RTMIN RT_1] --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- <... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call) rt_sigreturn(0xb7aedf00) = -1 EINTR (Interrupted system call) rt_sigreturn(0x80ac0cc) = -1 EINTR (Interrupted system call) futex(0x80ac0cc, FUTEX_WAIT, 5, NULL) = -1 EINTR (Interrupted system call) --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- rt_sigsuspend(~[INT QUIT ABRT TERM RTMIN RT_1] --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- <... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call) rt_sigreturn(0xb7aedf00) = -1 EINTR (Interrupted system call) rt_sigreturn(0x80ac0cc) = -1 EINTR (Interrupted system call) futex(0x80ac0cc, FUTEX_WAIT, 5, NULL) = -1 EINTR (Interrupted system call) --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- rt_sigsuspend(~[INT QUIT ABRT TERM RTMIN RT_1] --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- Any ideas there? Maybe I'll just reinstall with FreeBSD ;-) Is this with the actual release (5.8.6) or any RC? Yes, I used cm3-bin-core-LINUXLIBC6-5.8.6-REL.tgz and cm3-src-all-5.8.6-REL.tgz with. wiley:/home/mand# cvsup -v CVSup client, GUI version Copyright 1996-2003 John D. Polstra Software version: release_branch_cm3_5_8 Protocol version: 17.0 Operating system: LINUXLIBC6 @Jay, you did correct the process startup so that CVSup should work, didn't you? Any ideas about this one? @Mike, can you attach with gdb and get a stack backtrace? Here it is... wiley:/home/mand# gdb -p 32607 GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". Attaching to process 32607 Reading symbols from /usr/local/cm3/bin/cvsup...done. Reading symbols from /usr/local/cm3/lib/libm3formsvbt.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3formsvbt.so.5 Reading symbols from /usr/local/cm3/lib/libm3formsvbtpixmaps.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3formsvbtpixmaps.so.5 Reading symbols from /usr/local/cm3/lib/libvideovbt.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libvideovbt.so.5 Reading symbols from /usr/local/cm3/lib/libweb.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libweb.so.5 Reading symbols from /usr/local/cm3/lib/libjvideo.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libjvideo.so.5 Reading symbols from /usr/local/cm3/lib/libm3vbtkit.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3vbtkit.so.5 Reading symbols from /usr/local/cm3/lib/libm3ui.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3ui.so.5 Reading symbols from /usr/local/cm3/lib/libm3X11R4.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3X11R4.so.5 Reading symbols from /usr/local/cm3/lib/libsuplib.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libsuplib.so.5 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/local/cm3/lib/libm3tcp.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3tcp.so.5 Reading symbols from /usr/local/cm3/lib/libset.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libset.so.5 Reading symbols from /usr/local/cm3/lib/libTempFiles.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libTempFiles.so.5 Reading symbols from /usr/local/cm3/lib/libm3.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3.so.5 Reading symbols from /usr/local/cm3/lib/libm3core.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3core.so.5 Reading symbols from /usr/lib/libXaw.so.7...done. Loaded symbols for /usr/lib/libXaw.so.7 Reading symbols from /usr/lib/libXmu.so.6...done. Loaded symbols for /usr/lib/libXmu.so.6 Reading symbols from /usr/lib/libXext.so.6...done. Loaded symbols for /usr/lib/libXext.so.6 Reading symbols from /usr/lib/libXt.so.6...done. Loaded symbols for /usr/lib/libXt.so.6 Reading symbols from /usr/lib/libSM.so.6...done. Loaded symbols for /usr/lib/libSM.so.6 Reading symbols from /usr/lib/libICE.so.6...done. Loaded symbols for /usr/lib/libICE.so.6 Reading symbols from /usr/lib/libX11.so.6...done. Loaded symbols for /usr/lib/libX11.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 0xb6ec26b0 (LWP 32607)] [New Thread 0xb140fb90 (LWP 32617)] [New Thread 0xb1e0fb90 (LWP 32616)] [New Thread 0xb320fb90 (LWP 32614)] [New Thread 0xb3c0fb90 (LWP 32613)] [New Thread 0xb460fb90 (LWP 32612)] [New Thread 0xb5051b90 (LWP 32611)] [New Thread 0xb5a7fb90 (LWP 32610)] [New Thread 0xb647fb90 (LWP 32609)] [New Thread 0xb6e7fb90 (LWP 32608)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libXpm.so.4...done. Loaded symbols for /usr/lib/libXpm.so.4 Reading symbols from /usr/lib/libXau.so.6...done. Loaded symbols for /usr/lib/libXau.so.6 Reading symbols from /usr/lib/libxcb-xlib.so.0...done. Loaded symbols for /usr/lib/libxcb-xlib.so.0 Reading symbols from /usr/lib/libxcb.so.1...done. Loaded symbols for /usr/lib/libxcb.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libXdmcp.so.6...done. Loaded symbols for /usr/lib/libXdmcp.so.6 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_mdns4_minimal.so.2...done. Loaded symbols for /lib/libnss_mdns4_minimal.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libnss_compat.so.2...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libnss_nis.so.2...done. Loaded symbols for /lib/libnss_nis.so.2 0xb6f2599d in sigsuspend () from /lib/libc.so.6 (gdb) bt #0 0xb6f2599d in sigsuspend () from /lib/libc.so.6 #1 0xb72a7ece in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 #2 0xb72a6d56 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=64, M3_AJWxb1_info=0xbfffc6f0, M3_AJWxb1_context=0xbfffc770) at ../src/thread/PTHREAD/ThreadPThread.m3:1205 #3 #4 0xb70438f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #5 0xb72a84d6 in ThreadPThread__pthread_cond_wait (cond=0x80ac0c8, mutex=0x80ac0a8) at ../src/thread/PTHREAD/ThreadPThreadC.c:507 #6 0xb72a29a9 in ThreadPThread__XWait (M3_DMxDjQ_self=0x80ac018, M3_AYIbX3_m=0xb6e84bc4, M3_Bl0jv4_c=0xb6e84bdc, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #7 0xb72a2a71 in Thread__AlertWait (M3_AYIbX3_m=0xb6e84bc4, M3_Bl0jv4_c=0xb6e84bdc) at ../src/thread/PTHREAD/ThreadPThread.m3:196 #8 0xb7cdd671 in Reaper__AlertJoinNext (M3_Cjq8Fl_reaper=0xb6e84bc4, M3_DTZVTc_thr=0xbfffcf50, M3_EKuYlT_ret=0xbfffcf54) at ../src/Reaper.m3:111 #9 0x08079323 in FSClient__Apply (M3_EVLLAD_self=0xb6eb5ab8) at ../src/FSClient.m3:201 #10 0x08091e26 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:398 #11 0xb7292ccb in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a6d40) at ../src/runtime/common/RTLinker.m3:406 #12 0xb7291ffe in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a6d40) at ../src/runtime/common/RTLinker.m3:113 #13 0xb729208c in RTLinker__AddUnit (M3_DjPxE5_b=0x808d275) at ../src/runtime/common/RTLinker.m3:122 #14 0x0804e9ce in main (argc=6, argv=0xbfffd914, envp=0xbfffd930) at _m3main.mc:4 (gdb) 2 or 3 thoughts: o Did you turn off the GUI (I think -g)? Yes. o Did you increase the debugging level (-L 2?)? Yes. o Have you tried an old binary e.g. from our DCVS packages? Not yet. I'll try that next. [update: yes, it works, needs libc6-i386 of course] I upgraded my vServer and installed a 64-bit Ubuntu with cm3 from AMD_64 sources, but encountered the same stall. I thought perhaps this might have to do with the modified kernel or ulimits on the vServer, but as it turns out, cvsup on birch also hangs, as well as on willow (Ubuntu i386). -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 Aug 27 08:14:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 08:14:59 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms Message-ID: <20100827081459.s88b14400448owk8@mail.elegosoft.com> FYI -- fixed version info (5.8.6) ----- Forwarded message from bugs at elego.de ----- Date: Fri, 27 Aug 2010 06:09:55 -0000 From: CM3 Reply-To: CM3 Subject: Re: [CM3] #1148: CVSup stalls on several platforms To: wagner at elego.de #1148: CVSup stalls on several platforms --------------------------+------------------------------------------------- Reporter: wagner | Owner: wagner Type: sw-bug | Status: new Priority: high | Milestone: CM3 Release 5.9 Component: misc | Version: 5.8.6 Severity: serious | Keywords: cvsup, stalling, hanging, pthreads Relnote: | Org: Estimatedhours: 0.0 | Hours: 0 Billable: 0 | Totalhours: 0 Internal: 0 | --------------------------+------------------------------------------------- Htr: try to mirror the cm3 repository, possible any other, too Fix: Env: --------------------------+------------------------------------------------- Changes (by wagner): * version: 5.8-RC3 => 5.8.6 -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 Fri Aug 27 09:01:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 07:01:57 +0000 Subject: [M3devel] m3cc often succeeds when it should fail Message-ID: I finally looked into this. The reason is that the exit code of a pipeline is the last command. Seems kind of dumb and I don't like any of the options. I like having tee in there to save a log. There is a way to deal it with bash, zsh, and it takes a big function to do it in standard sh. Maybe q_exec or m3_exec? It looks like no. I suppose we could wrap up everything in a .sh file, detect bash 3 or newer, and use set -o pipefail? ?- Jay From jay.krell at cornell.edu Fri Aug 27 09:19:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 07:19:59 +0000 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: References: Message-ID: We could introduce a new quake feature.. if defined("set_pipefail") ? set_pipefail() end q_exec() ? ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 27 Aug 2010 07:01:57 +0000 > Subject: [M3devel] m3cc often succeeds when it should fail > > > I finally looked into this. > > The reason is that the exit code of a pipeline is the last command. > Seems kind of dumb and I don't like any of the options. > I like having tee in there to save a log. > > There is a way to deal it with bash, zsh, and it takes a big function to do it in standard sh. > > Maybe q_exec or m3_exec? > It looks like no. > > I suppose we could wrap up everything in a .sh file, detect bash 3 or newer, and use set -o pipefail? > > - Jay > From jay.krell at cornell.edu Fri Aug 27 11:12:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 09:12:00 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: , Message-ID: Easier said than done. Setting standard_structs = TRUE I thought would free the backend from worrying about passing or returning structs at all, but that's far from true. I thought the frontend would introduce temporaries and pass their addresses. But no. See for example what M3x86 does in pop_struct. Frustrating. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: passing structs by value > Date: Thu, 26 Aug 2010 11:36:51 +0000 > > > aka: I propose Target.i3 standard_structs always be true, and therefore remove it and propagate true through m3front. > Or at least make it always true and leave the code in m3front for future generations to revisit.. > > I will go ahead and test this. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: passing structs by value > > Date: Thu, 26 Aug 2010 11:34:54 +0000 > > > > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > I really can't follow the complicated rules here: > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > As you start to repair that, it starts following the ABI. At least at the callee side. > > I think the caller is still devoid of type information. > > I'm assuming there is a fallback rule for the case of missing type information. > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > Passing records in registers is nice, but.. > > (reminder: I think historically we never did). > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > Like it does for I386_NT/NT386. > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > Or whatever the code is already prepared to do. > > > > > > We should probably handle records returned by value similarly. > > > > > > This decision can be revisited if/when there is a C backend. > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > I doubt anyone else is either. > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > The right fix is probably to maintain types in the expression stack. > > Or at least throw in more casts on the pops. > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > - Jay > > > From jay.krell at cornell.edu Fri Aug 27 11:21:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 09:21:42 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: , , Message-ID: Hm. I think the right fix here is to pass a typeid to pop_struct. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: passing structs by value > Date: Fri, 27 Aug 2010 09:12:00 +0000 > > > Easier said than done. > Setting standard_structs = TRUE I thought would free the backend from worrying > about passing or returning structs at all, but that's far from true. > I thought the frontend would introduce temporaries and pass their addresses. But no. > > See for example what M3x86 does in pop_struct. > Frustrating. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: RE: passing structs by value > > Date: Thu, 26 Aug 2010 11:36:51 +0000 > > > > > > aka: I propose Target.i3 standard_structs always be true, and therefore remove it and propagate true through m3front. > > Or at least make it always true and leave the code in m3front for future generations to revisit.. > > > > I will go ahead and test this. > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Subject: passing structs by value > > > Date: Thu, 26 Aug 2010 11:34:54 +0000 > > > > > > > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > > > I really can't follow the complicated rules here: > > > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > > As you start to repair that, it starts following the ABI. At least at the callee side. > > > I think the caller is still devoid of type information. > > > I'm assuming there is a fallback rule for the case of missing type information. > > > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > > > > Passing records in registers is nice, but.. > > > (reminder: I think historically we never did). > > > > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > > Like it does for I386_NT/NT386. > > > > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > > Or whatever the code is already prepared to do. > > > > > > > > > We should probably handle records returned by value similarly. > > > > > > > > > This decision can be revisited if/when there is a C backend. > > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > > I doubt anyone else is either. > > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > > > > The right fix is probably to maintain types in the expression stack. > > > Or at least throw in more casts on the pops. > > > > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > > > > - Jay > > > > > > From michael.anderson at elego.de Fri Aug 27 12:03:06 2010 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 27 Aug 2010 12:03:06 +0200 Subject: [M3devel] [elego Server Maintenance] Friday 27.08.2010 20:00 Message-ID: <20100827120306.2yrr0fzucgcksk0g@mail.elego.de> Hello, On Friday, August 27 at 8 PM CEST, we will perform scheduled maintenance on our servers, including the modula3 CVS server and Hudson CI server. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 27 12:29:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 10:29:41 +0000 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: <20100827081459.s88b14400448owk8@mail.elegosoft.com> References: <20100827081459.s88b14400448owk8@mail.elegosoft.com> Message-ID: Can you add more information to the bug as to how to reproduce the problem? Exact files? cvsup.conf or whatnot? Exact command lines? I don't use cvsup, don't know how to set it up. Before when I debugging this it wasn't too difficult though. Perhaps we can put something in m3-sys/m3tests even? ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 08:14:59 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms > > FYI -- fixed version info (5.8.6) > > ----- Forwarded message from bugs at elego.de ----- > Date: Fri, 27 Aug 2010 06:09:55 -0000 > From: CM3 > Reply-To: CM3 > Subject: Re: [CM3] #1148: CVSup stalls on several platforms > To: wagner at elego.de > > #1148: CVSup stalls on several platforms > --------------------------+------------------------------------------------- > Reporter: wagner | Owner: wagner > Type: sw-bug | Status: new > Priority: high | Milestone: CM3 Release 5.9 > Component: misc | Version: 5.8.6 > Severity: serious | Keywords: cvsup, stalling, hanging, pthreads > Relnote: | Org: > Estimatedhours: 0.0 | Hours: 0 > Billable: 0 | Totalhours: 0 > Internal: 0 | > --------------------------+------------------------------------------------- > Htr: > try to mirror the cm3 repository, possible any other, too > > > Fix: > > > > Env: > > > --------------------------+------------------------------------------------- > Changes (by wagner): > > * version: 5.8-RC3 => 5.8.6 > > > -- > Ticket URL: > CM3 > Critical Mass Modula3 Compiler > > > ----- End forwarded message ----- > > > -- > 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 Aug 27 13:01:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 13:01:23 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: References: <20100827081459.s88b14400448owk8@mail.elegosoft.com> Message-ID: <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com> Quoting Jay K : > Can you add more information to the bug as to how to reproduce the problem? > Exact files? cvsup.conf or whatnot? > Exact command lines? > > I don't use cvsup, don't know how to set it up. > Before when I debugging this it wasn't too difficult though. > > Perhaps we can put something in m3-sys/m3tests even? I will try to set up an automated cvsup test at the weekend. In our DCVS distribution we had quite a few replication tests; perhaps I can burrow something from that. It won't go into m3tests though, but rather be a subdir to cvsup. m3-sys/m3tests is for language/compiler tests. 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 michael.anderson at elego.de Fri Aug 27 13:25:57 2010 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 27 Aug 2010 13:25:57 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com> References: <20100827081459.s88b14400448owk8@mail.elegosoft.com> <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com> Message-ID: <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> Quoting Olaf Wagner : > Quoting Jay K : > >> Can you add more information to the bug as to how to reproduce the problem? >> Exact files? cvsup.conf or whatnot? >> Exact command lines? >> I'm able to reliably reproduce the problem with this command: /usr/local/cm3/bin/cvsup -g -L 2 cvsupfile.cm3 where the cvsupfile contains: *default host=birch.elego.de *default base=/home/mand/tmp/cvsup *default prefix=/home/mand/tmp/cvs *default release=cvs *default delete use-rel-suffix *default preserve cm3 Sometimes the first sync will finish, but a subsequent sync will hang. >> I don't use cvsup, don't know how to set it up. >> Before when I debugging this it wasn't too difficult though. >> >> Perhaps we can put something in m3-sys/m3tests even? > > I will try to set up an automated cvsup test at the weekend. > In our DCVS distribution we had quite a few replication tests; > perhaps I can burrow something from that. > > It won't go into m3tests though, but rather be a subdir to cvsup. > m3-sys/m3tests is for language/compiler tests. > > 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 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 27 13:44:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 11:44:02 +0000 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> References: <20100827081459.s88b14400448owk8@mail.elegosoft.com>, , <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com>, <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> Message-ID: Michael, thank you. Please add it to the bug. ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 13:25:57 +0200 > From: michael.anderson at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms > > Quoting Olaf Wagner : > > > Quoting Jay K : > > > >> Can you add more information to the bug as to how to reproduce the problem? > >> Exact files? cvsup.conf or whatnot? > >> Exact command lines? > >> > > > I'm able to reliably reproduce the problem with this command: > > /usr/local/cm3/bin/cvsup -g -L 2 cvsupfile.cm3 > > where the cvsupfile contains: > > *default host=birch.elego.de > *default base=/home/mand/tmp/cvsup > *default prefix=/home/mand/tmp/cvs > *default release=cvs > *default delete use-rel-suffix > *default preserve > cm3 > > Sometimes the first sync will finish, but a subsequent sync will hang. > > >> I don't use cvsup, don't know how to set it up. > >> Before when I debugging this it wasn't too difficult though. > >> > >> Perhaps we can put something in m3-sys/m3tests even? > > > > I will try to set up an automated cvsup test at the weekend. > > In our DCVS distribution we had quite a few replication tests; > > perhaps I can burrow something from that. > > > > It won't go into m3tests though, but rather be a subdir to cvsup. > > m3-sys/m3tests is for language/compiler tests. > > > > 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 > > > > -- > Michael Anderson > IT Services & Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Building 12.3 (BIG) room 227 > 13355 Berlin, Germany > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > fax +49 30 23 45 86 95 http://www.elegosoft.com > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > From jay.krell at cornell.edu Fri Aug 27 13:45:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 11:45:07 +0000 Subject: [M3devel] type id for globals? Message-ID: Is it reasonable to desire a typeid for the globals records? ie. to assist in generating type information? I guess I don't need it after all, really.. (3553) comment ? quoted_string:global data type descriptor ? comment: `global data type descriptor' (3554) declare_record ? record id:0xffffffff fields:0xc size:0x3c80 (3555) declare_field ? quoted_string:types ? field types, id 0x454792e7, size 0x240, offset 0x640 (3556) declare_field ? quoted_string:uids ? field uids, id 0x454792e7, size 0x240, offset 0x880 (3557) declare_field ? quoted_string:brands ? field brands, id 0x454792e7, size 0x240, offset 0xac0 (3558) declare_field ? quoted_string:Dummy1_typecell ? field Dummy1_typecell, id 0xf8c78b31, size 0x300, offset 0x1600 (3559) declare_field ? quoted_string:Dummy3_typecell ? field Dummy3_typecell, id 0xf8c78b31, size 0x300, offset 0x1900 (3560) declare_field ? quoted_string:NULL_typecell ? field NULL_typecell, id 0xf8c78b31, size 0x300, offset 0x1c00 (3561) declare_field ? quoted_string:UNROOT_typecell ? field UNROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x1f00 (3562) declare_field ? quoted_string:ROOT_typecell ? field ROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x23c0 (3563) declare_field From hosking at cs.purdue.edu Fri Aug 27 16:00:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Aug 2010 10:00:32 -0400 Subject: [M3devel] type id for globals? In-Reply-To: References: Message-ID: <48EBBDD6-52BE-47DB-A8C8-49413477C615@cs.purdue.edu> Not sure... haven't really been following much lately... On 27 Aug 2010, at 07:45, Jay K wrote: > > Is it reasonable to desire a typeid for the globals records? > ie. to assist in generating type information? > I guess I don't need it after all, really.. > > (3553) comment > quoted_string:global data type descriptor > comment: `global data type descriptor' > (3554) declare_record > record id:0xffffffff fields:0xc size:0x3c80 > (3555) declare_field > quoted_string:types > field types, id 0x454792e7, size 0x240, offset 0x640 > (3556) declare_field > quoted_string:uids > field uids, id 0x454792e7, size 0x240, offset 0x880 > (3557) declare_field > quoted_string:brands > field brands, id 0x454792e7, size 0x240, offset 0xac0 > (3558) declare_field > quoted_string:Dummy1_typecell > field Dummy1_typecell, id 0xf8c78b31, size 0x300, offset 0x1600 > (3559) declare_field > quoted_string:Dummy3_typecell > field Dummy3_typecell, id 0xf8c78b31, size 0x300, offset 0x1900 > (3560) declare_field > quoted_string:NULL_typecell > field NULL_typecell, id 0xf8c78b31, size 0x300, offset 0x1c00 > (3561) declare_field > quoted_string:UNROOT_typecell > field UNROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x1f00 > (3562) declare_field > quoted_string:ROOT_typecell > field ROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x23c0 > (3563) declare_field > > > > > From wagner at elegosoft.com Fri Aug 27 17:17:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 17:17:23 +0200 Subject: [M3devel] Potential bug in RTAllocator.Clone, was: Fwd: Auto-discard notification Message-ID: <20100827171723.2a60uadm0wos04gw@mail.elegosoft.com> Forwarded; sent before subscription was confirmed: The attached message has been automatically discarded. Info The following are the headers for this message/rfc822 message. Date: Fri, 27 Aug 2010 15:39:23 +0100 Subject: Potential bug in RTAllocator.Clone From: Raja Mukherji To: m3devel at elegosoft.com 2.1 unnamed [text/plain] 0.58 KB Download Hi, this is my first post to the Modula-3 mailing list... While using RTAllocator.Clone in a project, I kept getting errors related to the type of the returned object. The debugger m3gdb returned a TYPECODE of 0. I think the cause is line 84 in RTAllocator.m3 which currently reads res := AllocTraced(dataSize, def.dataAlignment, thread^); which doesn't seem to set the header of the clone. Changing it to res := LOOPHOLE(GetTraced(def), ADDRESS); seems to fix the problems, but since I'm not that familiar with the object representation I thought I should ask here first. Thanks, Raja ----- Forwarded message from m3devel-bounces at elegosoft.com ----- Date: Fri, 27 Aug 2010 16:48:17 +0200 From: m3devel-bounces at elegosoft.com Reply-To: m3devel-bounces at elegosoft.com Subject: Auto-discard notification To: m3devel-owner at elegosoft.com The attached message has been automatically discarded. ----- End forwarded message ----- -- 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 rajamukherji at gmail.com Fri Aug 27 17:19:18 2010 From: rajamukherji at gmail.com (Raja Mukherji) Date: Fri, 27 Aug 2010 16:19:18 +0100 Subject: [M3devel] Potential bug in RTAllocator.Clone Message-ID: Hi, this is my first post to the Modula-3 mailing list... While using RTAllocator.Clone in a project, I kept getting errors related to the type of the returned object. The debugger m3gdb returned a TYPECODE of 0. I think the cause is line 84 in RTAllocator.m3 which currently reads res := AllocTraced(dataSize, def.dataAlignment, thread^); which doesn't seem to set the header of the clone. Changing it to res := LOOPHOLE(GetTraced(def), ADDRESS); seems to fix the problems, but since I'm not that familiar with the object representation I thought I should ask here first. Thanks, Raja From rodney_bates at lcwb.coop Fri Aug 27 17:20:51 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 Aug 2010 10:20:51 -0500 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> Message-ID: <4C77D7D3.6070602@lcwb.coop> Jay K wrote: > > better code quality > > Use the native C++ exception handling. Not more calling setjmp all over the place. > Inlining. Currnetly disabled in 4.5.1 because it breaks things. > LTO/LTCG -- which we could get today, on gcc platforms, if we are willing to import even more code. > (link time optimization, link time code gen). e.g. cross module inlining. > see also PGO -- profile guided optimization. > i.e. whatever the full C/C++ toolset is, you can use it. > > > > better debugging > > > Existing debuggers would work and work well. There is no way a debugger that has no Modula-3 awareness is going to provide a Modula-3-like view. The operators will have C spellings and C semantics, and these do differ. The syntax will be strictly C. The display of values will be C. TEXT won't work in any reasonable way at all. Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 type info would be lost, and output formats would lose. Things that use pointers at the machine level can never know whether the pointers point to a single value or an array, and if the latter, with what bounds. Display of whole arrays is pretty much out of the question. Probably the worst thing will be calls. They just don't work without the debugger having knowledge of a lot of stuff. There are extra hidden parameters, method calls, passing procedure-typed parameters with environments, calling the same, the three modes of Modula-3, etc. I consider calls in debugger commands very valuable. This could probably be improved a lot by switching to a better debug info format, probably the latest Dwarf variant. But that is a big job. > Notice today that NT386 has only line numbers. > That there are systems that don't support stabs -- e.g. HP-UX. > That other -g switches to cm3cg crash. > > >>> Basically all platforms would just work. >> I doubt that very much. > > It's only a slight exaggeration. > We'd still need our #ifdef'ing of the C code. Possibly guided by autoconf. > And there are still the threading/gc issues. > But for example, we should work on any processor for any operating system > for which we already work -- NT, Linux, NetBSD, FreeBSD, Solaris, OSF -- on any processors. > And AIX, Irix, VMS would work or be closer to working. > (IA64 might need an #ifdef) > > Anyway, I'll try to work on it. > >> And it would be an order of magnitude slower. > > It would be slower. I'm not sure by how much. > > - Jay > > > ---------------------------------------- >> Date: Thu, 26 Aug 2010 14:10:22 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? >> >> Quoting Jay K : >> >>>> No. I would see a C backend as a variant (option) too, but probably not >>>> use it on platforms were I can compile without it. >>> I would like to see a C backend at least replace the gcc backend. >>> We could maybe then slowly iterate on the integrated backend. Or LLVM. >>> It would provide more obvious correctness, better debugging, better >>> code quality. >> I don't really see that yet. >> >>> Imagine -- basically all platforms would get stack walkers. >>> By generating C++ for most platforms, or using C exception >>> handling in NT/VMS/Tru64. >>> Basically all platforms would just work. >> I doubt that very much. >> >>> Stock debuggers would work, gdb and others. >>> Basically no more porting. >>> Basically all optimizations could be enabled. >>> (Aside: I think the generated C would be sure to store >>> gc roots in volatile locals, but not otherwise use said volatiles.) >> As I said: it has been tried before. >> >>> And in more recent developments, it would enregister some records >>> passed by value. >>> It would, in a sense, shrink the code base (cheating sort of). >> And it would be an order of magnitude slower. >> >>> I'm not holding my breath on any of this. >>> But I'm going to start trying to do more and talk less about it. >> I will let you convince me ;-) >> I've got no problem with trying that. If it's really better, we will >> use it. If not, we may want to use it for special situations (e.g. porting). >> >> 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 Aug 27 17:31:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 17:31:06 +0200 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: References: Message-ID: <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> Quoting Jay K : > We could introduce a new quake feature.. > if defined("set_pipefail") > ? set_pipefail() > end > q_exec() > ? Could you elaborate what exactly fails? I don't think we should rely on bash3 or zsh or something else fancy. I'm also not sure that we can easily implement it in quake. The problem with pipelining logs through tee and losing result values is a standard one, but has no canonical solution AFAIK. More details would help, Olaf > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Fri, 27 Aug 2010 07:01:57 +0000 >> Subject: [M3devel] m3cc often succeeds when it should fail >> >> >> I finally looked into this. >> >> The reason is that the exit code of a pipeline is the last command. >> Seems kind of dumb and I don't like any of the options. >> I like having tee in there to save a log. >> >> There is a way to deal it with bash, zsh, and it takes a big >> function to do it in standard sh. >> >> Maybe q_exec or m3_exec? >> It looks like no. >> >> I suppose we could wrap up everything in a .sh file, detect bash 3 >> or newer, and use set -o pipefail? >> >> - 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 rodney_bates at lcwb.coop Fri Aug 27 17:30:15 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 Aug 2010 10:30:15 -0500 Subject: [M3devel] passing structs by value In-Reply-To: References: Message-ID: <4C77DA07.8030608@lcwb.coop> Jay, I am not sure what you are saying here, but it sounds like you might be considering the passing mode of records to be an implementor choice. Have I read this right? It isn't a choice for Modula-3. The language specifies the mode. Value for VALUE in the signature, reference for VAR, and for READONLY, it depends on the form of the actual. For function returns, the semantics are always by value. Of course, at the machine level, you can always pass a pointer between caller and callee, as long as the necessary copying is done somewhere This is the only reasonable way to implement READONLY, since whether a copy is to be made will differ at different call sites. Jay K wrote: > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > I really can't follow the complicated rules here: > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > As long as Modula-3 callers/recievers agree. And they do, but... > > > The gcc backend is given good type information at first, but historically throws much of it away. > As you start to repair that, it starts following the ABI. At least at the callee side. > I think the caller is still devoid of type information. > I'm assuming there is a fallback rule for the case of missing type information. > > So if you give just one side the type information, you get a mismatch, bad code. > > > Passing records in registers is nice, but.. > (reminder: I think historically we never did). > > > I thin we should probably just change the frontend to handle passing records by value itself. > Like it does for I386_NT/NT386. > > > For any record parameter, introduce a temporary in the caller and pass its address. > Or whatever the code is already prepared to do. > > > We should probably handle records returned by value similarly. > > > This decision can be revisited if/when there is a C backend. > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > I doubt anyone else is either. > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > The right fix is probably to maintain types in the expression stack. > Or at least throw in more casts on the pops. > > > I don't think pop_param presently recieves enough type information -- no type id. > > > - Jay > From hosking at cs.purdue.edu Fri Aug 27 18:11:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Aug 2010 12:11:50 -0400 Subject: [M3devel] Potential bug in RTAllocator.Clone, was: Fwd: Auto-discard notification In-Reply-To: <20100827171723.2a60uadm0wos04gw@mail.elegosoft.com> References: <20100827171723.2a60uadm0wos04gw@mail.elegosoft.com> Message-ID: I just committed a fix for this. On 27 Aug 2010, at 11:17, Olaf Wagner wrote: > Forwarded; sent before subscription was confirmed: > > The attached message has been automatically discarded. > Info The following are the headers for this message/rfc822 message. > Date: Fri, 27 Aug 2010 15:39:23 +0100 > Subject: Potential bug in RTAllocator.Clone > From: Raja Mukherji > To: m3devel at elegosoft.com > 2.1 unnamed [text/plain] 0.58 KB Download > Hi, this is my first post to the Modula-3 mailing list... > > While using RTAllocator.Clone in a project, I kept getting errors > related to the type of the returned object. The debugger m3gdb > returned a TYPECODE of 0. > I think the cause is line 84 in RTAllocator.m3 which currently reads > > res := AllocTraced(dataSize, def.dataAlignment, thread^); > > which doesn't seem to set the header of the clone. Changing it to > > res := LOOPHOLE(GetTraced(def), ADDRESS); > > seems to fix the problems, but since I'm not that familiar with the > object representation I thought I should ask here first. > > Thanks, > Raja > > ----- Forwarded message from m3devel-bounces at elegosoft.com ----- > Date: Fri, 27 Aug 2010 16:48:17 +0200 > From: m3devel-bounces at elegosoft.com > Reply-To: m3devel-bounces at elegosoft.com > Subject: Auto-discard notification > To: m3devel-owner at elegosoft.com > > The attached message has been automatically discarded. > > ----- End forwarded message ----- > > > -- > 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 Fri Aug 27 18:36:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 16:36:19 +0000 Subject: [M3devel] passing structs by value In-Reply-To: <4C77DA07.8030608@lcwb.coop> References: , <4C77DA07.8030608@lcwb.coop> Message-ID: Rodney, don't worry too much, I believe I understand the language semantics and won't deliberately change them. > Of course, at the machine levelI'm talking about the machine level. Passing a record by value can be in registers or a pointer to a copy. The gcc backend wasn't passing enough type information around, such that where the C ABI specified in registers, it'd a be a pointer to a copy. ?? Imho, it's kind of bad of the gcc code to even have accepted the trees we give it. I don't much mind the inefficiency, but I do mind missing type information in the debugger. And what really got me started here is an assertion failure in the SPARC64_SOLARIS backend. It goes to decide how to pass a record by value, which includes looking at what fields the record has, and it had none. Which it is sometimes ok with, but not in this case. If you just change parse.c to pass around the type information it has, well, the easy code only has information at the reciever, not the caller, leading to inconsistency, bad code, crash. The badness only occurs in a little bit of code in the system, and then, only on some platforms. I was lucky to be using such a platform! I have fixed it now so that the passer and recieve both have the information. The result should be, on some platforms, depending on the ABI, depending on the exact RECORD, some records will be passed in registers. Minor side benefit is correct interop with C, though I'd suggest just staying away from passing records by value with C. Unfortunately SPARC64_SOLARIS still hits the same assertion failure in gcc. :( I'm double checking to make sure I used current source. Accidentally doing a clean build of m3cc, so it'll be a while. ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 10:30:15 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] passing structs by value > > Jay, I am not sure what you are saying here, but it sounds like you might be considering the > passing mode of records to be an implementor choice. Have I read this right? > > It isn't a choice for Modula-3. The language specifies the mode. Value for VALUE in the > signature, reference for VAR, and for READONLY, it depends on the form of the actual. > > For function returns, the semantics are always by value. > > Of course, at the machine level, you can always pass a pointer between caller and callee, > as long as the necessary copying is done somewhere This is the only reasonable way to > implement READONLY, since whether a copy is to be made will differ at different call > sites. > > Jay K wrote: > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > I really can't follow the complicated rules here: > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > As you start to repair that, it starts following the ABI. At least at the callee side. > > I think the caller is still devoid of type information. > > I'm assuming there is a fallback rule for the case of missing type information. > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > Passing records in registers is nice, but.. > > (reminder: I think historically we never did). > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > Like it does for I386_NT/NT386. > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > Or whatever the code is already prepared to do. > > > > > > We should probably handle records returned by value similarly. > > > > > > This decision can be revisited if/when there is a C backend. > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > I doubt anyone else is either. > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > The right fix is probably to maintain types in the expression stack. > > Or at least throw in more casts on the pops. > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > - Jay > > From jay.krell at cornell.edu Fri Aug 27 18:51:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 16:51:57 +0000 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> References: , , <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> Message-ID: > Could you elaborate what exactly fails? I use make | tee -a. Any compilation failure..and still success. > I don't think we should rely on bash3 or zsh or something else fancy. Agreed. > I'm also not sure that we can easily implement it in quake. Here is where I disagree...though I'm not certain. You put in a substantial sh emulation already, in sysutils, already exposed in quake. m3-libs/sysutils/src/System.m3 ? PROCEDURE WaitForAll() : INTEGER = ??? VAR p: Process.T; ret: INTEGER := 0; ??? BEGIN ????? WHILE processes.size() > 0 DO ??????? p := NARROW(processes.remlo(), Process.T); ??????? ret := Process.Wait(p); ??????? CloseFiles(cjobid); ??????? INC(cjobid); ????? END; ????? RETURN ret; ??? END WaitForAll; A small change there would do what I want I think. ? PROCEDURE WaitForAll() : INTEGER = ??? VAR p: Process.T; ret := 0; overall := 0; ??? BEGIN ????? WHILE processes.size() > 0 DO ??????? p := NARROW(processes.remlo(), Process.T); ??????? ret := Process.Wait(p); ??????? IF ret <> 0 AND overall = 0 THEN ?????????? overall := ret; ??????? END; ??????? CloseFiles(cjobid); ??????? INC(cjobid); ????? END; ????? RETURN overall; ??? END WaitForAll; It could be made optional, though the way I showed would be global for that cm3 invocation, once set. It'd probably be safe to make it not optional. ? > The problem with pipelining logs through tee and losing result > values is a standard one, but has no canonical solution AFAIK. Agreed, based on my web searching last night. ?- Jay From jay.krell at cornell.edu Fri Aug 27 18:54:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 16:54:50 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: , , <4C77DA07.8030608@lcwb.coop>, Message-ID: > bad code, crash. Clarification, not a crash but an "orderly" error. This is somewhat by chance though. You could imagine perhaps a record that just contains a pointer, and a crash. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Fri, 27 Aug 2010 16:36:19 +0000 > Subject: Re: [M3devel] passing structs by value > > > Rodney, don't worry too much, I believe I understand the language semantics and won't deliberately change them. > > > Of course, at the machine levelI'm talking about the machine level. > > Passing a record by value can be in registers or a pointer to a copy. > The gcc backend wasn't passing enough type information around, such that > where the C ABI specified in registers, it'd a be a pointer to a copy. > Imho, it's kind of bad of the gcc code to even have accepted the trees we give it. > I don't much mind the inefficiency, but I do mind missing type information in the debugger. > > And what really got me started here is an assertion failure in the SPARC64_SOLARIS backend. > It goes to decide how to pass a record by value, which includes looking at what fields the record > has, and it had none. Which it is sometimes ok with, but not in this case. > > If you just change parse.c to pass around the type information it has, well, the easy > code only has information at the reciever, not the caller, leading to inconsistency, bad code, crash. > The badness only occurs in a little bit of code in the system, and then, only on some platforms. > I was lucky to be using such a platform! > > I have fixed it now so that the passer and recieve both have the information. > > The result should be, on some platforms, depending on the ABI, depending on the exact RECORD, > some records will be passed in registers. > Minor side benefit is correct interop with C, though I'd suggest just staying away from > passing records by value with C. > > Unfortunately SPARC64_SOLARIS still hits the same assertion failure in gcc. :( > I'm double checking to make sure I used current source. Accidentally doing > a clean build of m3cc, so it'll be a while. > > > - Jay > > > ---------------------------------------- > > Date: Fri, 27 Aug 2010 10:30:15 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] passing structs by value > > > > Jay, I am not sure what you are saying here, but it sounds like you might be considering the > > passing mode of records to be an implementor choice. Have I read this right? > > > > It isn't a choice for Modula-3. The language specifies the mode. Value for VALUE in the > > signature, reference for VAR, and for READONLY, it depends on the form of the actual. > > > > For function returns, the semantics are always by value. > > > > Of course, at the machine level, you can always pass a pointer between caller and callee, > > as long as the necessary copying is done somewhere This is the only reasonable way to > > implement READONLY, since whether a copy is to be made will differ at different call > > sites. > > > > Jay K wrote: > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > > > I really can't follow the complicated rules here: > > > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > > As you start to repair that, it starts following the ABI. At least at the callee side. > > > I think the caller is still devoid of type information. > > > I'm assuming there is a fallback rule for the case of missing type information. > > > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > > > > Passing records in registers is nice, but.. > > > (reminder: I think historically we never did). > > > > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > > Like it does for I386_NT/NT386. > > > > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > > Or whatever the code is already prepared to do. > > > > > > > > > We should probably handle records returned by value similarly. > > > > > > > > > This decision can be revisited if/when there is a C backend. > > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > > I doubt anyone else is either. > > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > > > > The right fix is probably to maintain types in the expression stack. > > > Or at least throw in more casts on the pops. > > > > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > > > > - Jay > > > > From wagner at elegosoft.com Fri Aug 27 19:23:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 19:23:31 +0200 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: References: , , <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> Message-ID: <20100827192331.fwoon2w4sgwgks8w@mail.elegosoft.com> Quoting Jay K : >> Could you elaborate what exactly fails? > > I use make | tee -a. > Any compilation failure..and still success. You loose stderr there. One standard solution would be to write stderr to a file and check that for content afterwards: make 2>make.err | tee -a log if[ -s make.err ]; then # error >> I'm also not sure that we can easily implement it in quake. > > Here is where I disagree...though I'm not certain. > You put in a substantial sh emulation already, in sysutils, already > exposed in quake. > > m3-libs/sysutils/src/System.m3 > > ? PROCEDURE WaitForAll() : INTEGER = > ??? VAR p: Process.T; ret: INTEGER := 0; > ??? BEGIN > ????? WHILE processes.size() > 0 DO > ??????? p := NARROW(processes.remlo(), Process.T); > ??????? ret := Process.Wait(p); > ??????? CloseFiles(cjobid); > ??????? INC(cjobid); > ????? END; > ????? RETURN ret; > ??? END WaitForAll; > > A small change there would do what I want I think. > > ? PROCEDURE WaitForAll() : INTEGER = > > ??? VAR p: Process.T; ret := 0; overall := 0; > ??? BEGIN > ????? WHILE processes.size() > 0 DO > ??????? p := NARROW(processes.remlo(), Process.T); > ??????? ret := Process.Wait(p); > ??????? IF ret <> 0 AND overall = 0 THEN > ?????????? overall := ret; > ??????? END; > ??????? CloseFiles(cjobid); > ??????? INC(cjobid); > ????? END; > ????? RETURN overall; > ??? END WaitForAll; > > It could be made optional, though the way I showed would be global for > that cm3 invocation, once set. > > It'd probably be safe to make it not optional. ? If this is what is used in your situation I'm in favour of making it the default to heed all return codes. I only said that I'm not sure it can be done easily, as there are different ways how processes are created in quake, often via system shells (might even be a cmd.exe) or anything specified in QUAKE_SHELL. As long as we're using one of the new functions I wrote some years ago it should be no problem. If it's working for you, just change it and document it in the quake manual (cm3/doc/help/cm3/quake.html). 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 hendrik at topoi.pooq.com Fri Aug 27 19:35:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 13:35:02 -0400 Subject: [M3devel] conversion to another version control system Message-ID: <20100827173502.GA8777@topoi.pooq.com> I was tinkering with a copy of the Modula 3 cvs repository I had made a few months ago using cvsup, seeing of cvs2git would make me a proper git-fast-import file. It complained that what I provided wasn't a valid CVS repository: ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS repository, nor a path within a CVS repository. A CVS repository contains a CVSROOT directory within its root directory. Now I looked around, and couldn't find a CVSROOT directory anywhere except in /usr/lib/cvs, which is probably irrelevant. Is this a problem with cvs2git, a problem with the repository, or a problem with cvsup, or a problem with the way I used cvsup to copy the repository? Or would any regular cvs user know just exactly what to do? By the way, the recent problems mentioned on this list about cvsup have made me afraid to use it again. Are those problems restricted to a few platforms, or widespread? -- hendrik From hendrik at topoi.pooq.com Fri Aug 27 20:09:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 14:09:02 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827173502.GA8777@topoi.pooq.com> References: <20100827173502.GA8777@topoi.pooq.com> Message-ID: <20100827180902.GA8903@topoi.pooq.com> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: > I was tinkering with a copy of the Modula 3 cvs repository I had made > a few months ago using cvsup, seeing of cvs2git would make me a proper > git-fast-import file. It complained that what I provided wasn't a valid > CVS repository: > > ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS > repository, nor a path within a CVS repository. A CVS repository > contains a CVSROOT directory within its root directory. > > Now I looked around, and couldn't find a CVSROOT directory anywhere > except in /usr/lib/cvs, which is probably irrelevant. > > Is this a problem with cvs2git, a problem with the repository, or a > problem with cvsup, or a problem with the way I used cvsup to copy the > repository? Or would any regular cvs user know just exactly what to do? Should I perhaps just create an empty CVSROOT directory somewhere? In case it indicates what I did wrong, an ancient log indicates that when I created the copy of the repository in the first place, I used the commands cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 -- hendrik From hosking at cs.purdue.edu Fri Aug 27 20:02:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Aug 2010 14:02:50 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827180902.GA8903@topoi.pooq.com> References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> Message-ID: cvs checkout gives you a checked out working directory not a repository. You'd need to *copy* the repository hierarchy verbatim. On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >> I was tinkering with a copy of the Modula 3 cvs repository I had made >> a few months ago using cvsup, seeing of cvs2git would make me a proper >> git-fast-import file. It complained that what I provided wasn't a valid >> CVS repository: >> >> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >> repository, nor a path within a CVS repository. A CVS repository >> contains a CVSROOT directory within its root directory. >> >> Now I looked around, and couldn't find a CVSROOT directory anywhere >> except in /usr/lib/cvs, which is probably irrelevant. >> >> Is this a problem with cvs2git, a problem with the repository, or a >> problem with cvsup, or a problem with the way I used cvsup to copy the >> repository? Or would any regular cvs user know just exactly what to do? > > Should I perhaps just create an empty CVSROOT directory somewhere? > > In case it indicates what I did wrong, an ancient log indicates that > when I created the copy of the repository in the first place, I used the > commands > > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 > > -- hendrik From jay.krell at cornell.edu Fri Aug 27 20:28:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 18:28:47 +0000 Subject: [M3devel] importing types not described to backend Message-ID: This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 INTERFACE Color; TYPE T = RECORD a,b,c:REAL; END; END Color. MODULE Main; IMPORT Color; TYPE ColorT = RECORD a,b,c: REAL; END; <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = BEGIN END F1; <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = BEGIN END F2; BEGIN ? F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); ? F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); END Main. On SPARC64_SOLARIS there is an assertion failure in the backend: /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1? -mno-app-regs? -quiet -fno-reorder-blocks -funwind-tables -fPIC?? -m64? -gstabs+ Main.mc -o Main.ms ../Main.m3: In function 'Main__F1': ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 I fixed it so F1 is ok. But still F2 isn't. The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. The problem as I understand is we don't tell the backend about imported types. ?There is nothing in the IR about them, judging from -y and a quick look at parse.c. I intend to fix this if I don't here any objections. I'm hoping it isn't too much work. I believe it will mostly/all be in m3front. My opinion of our gcc backend drops.. Perhaps the time is better used on a C front end. Though in this case, I think the work is shared, the same stuff would be missing there too. Thanks, ?- Jay From jay.krell at cornell.edu Fri Aug 27 20:35:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 18:35:00 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: Message-ID: Very wierd: MODULE Main; IMPORT Color; TYPE ColorT = RECORD a,b,c: REAL; END; <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = BEGIN END F1; BEGIN ? F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); END Main. This fails. If you remove the IMPORT, it worked. The declare_record of ColorT comes and goes with that change. So I guess the error really is in F1. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 27 Aug 2010 18:28:47 +0000 > Subject: [M3devel] importing types not described to backend > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > INTERFACE Color; > TYPE T = RECORD a,b,c:REAL; END; > END Color. > > > MODULE Main; > IMPORT Color; > TYPE ColorT = RECORD a,b,c: REAL; END; > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > BEGIN > END F1; > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > BEGIN > END F2; > > > BEGIN > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > END Main. > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > ../Main.m3: In function 'Main__F1': > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > I fixed it so F1 is ok. > But still F2 isn't. > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > The problem as I understand is we don't tell the backend about imported types. > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > I intend to fix this if I don't here any objections. > I'm hoping it isn't too much work. > I believe it will mostly/all be in m3front. > > > My opinion of our gcc backend drops.. > > > Perhaps the time is better used on a C front end. > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > Thanks, > - Jay > From wagner at elegosoft.com Fri Aug 27 20:55:55 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 20:55:55 +0200 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> Message-ID: <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> Quoting Tony Hosking : > cvs checkout gives you a checked out working directory not a repository. > You'd need to *copy* the repository hierarchy verbatim. The CM3 repository is on birch.elegosoft.com:/usr/cvs It contains CVSROOT and cm3 as CVS modules. CVSROOT contains metainformation about the versions. You'll probably need it for git conversion. You can get the whole repository via cvsup, rsync or scp. The last two require an ssh account on birch. Olaf PS: I did mention that Peter Eiserloh is also working on a git conversion of our history? > On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > >> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >>> I was tinkering with a copy of the Modula 3 cvs repository I had made >>> a few months ago using cvsup, seeing of cvs2git would make me a proper >>> git-fast-import file. It complained that what I provided wasn't a valid >>> CVS repository: >>> >>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >>> repository, nor a path within a CVS repository. A CVS repository >>> contains a CVSROOT directory within its root directory. >>> >>> Now I looked around, and couldn't find a CVSROOT directory anywhere >>> except in /usr/lib/cvs, which is probably irrelevant. >>> >>> Is this a problem with cvs2git, a problem with the repository, or a >>> problem with cvsup, or a problem with the way I used cvsup to copy the >>> repository? Or would any regular cvs user know just exactly what to do? >> >> Should I perhaps just create an empty CVSROOT directory somewhere? >> >> In case it indicates what I did wrong, an ancient log indicates that >> when I created the copy of the repository in the first place, I used the >> commands >> >> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login >> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 >> >> -- hendrik > > -- 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 hendrik at topoi.pooq.com Fri Aug 27 21:31:56 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 15:31:56 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> Message-ID: <20100827193155.GB8903@topoi.pooq.com> On Fri, Aug 27, 2010 at 02:02:50PM -0400, Tony Hosking wrote: > cvs checkout gives you a checked out working directory not a repository. > You'd need to *copy* the repository hierarchy verbatim. > > On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > > > On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: > >> I was tinkering with a copy of the Modula 3 cvs repository I had made > >> a few months ago using cvsup, seeing of cvs2git would make me a proper > >> git-fast-import file. It complained that what I provided wasn't a valid > >> CVS repository: > >> > >> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS > >> repository, nor a path within a CVS repository. A CVS repository > >> contains a CVSROOT directory within its root directory. > >> > >> Now I looked around, and couldn't find a CVSROOT directory anywhere > >> except in /usr/lib/cvs, which is probably irrelevant. > >> > >> Is this a problem with cvs2git, a problem with the repository, or a > >> problem with cvsup, or a problem with the way I used cvsup to copy the > >> repository? Or would any regular cvs user know just exactly what to do? > > > > Should I perhaps just create an empty CVSROOT directory somewhere? > > > > In case it indicates what I did wrong, an ancient log indicates that > > when I created the copy of the repository in the first place, I used the > > commands > > > > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 OK. it looks as if this wasn't the command I used. I do remember using cvsup at some point. I do have a lot of ,v files. so it's not a checkout I'm looking at. I seem to have looked at the wrong set of logs. That's was from the set that records how I compiled cvsup. I found the cvsupfile.cm3 file I used. It looks as if I didn't fully uncomment stuff. Will rerun. I hope it won't overload the server. -- hendrik From wagner at elegosoft.com Fri Aug 27 21:29:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 21:29:06 +0200 Subject: [M3devel] cm3cg running amok Message-ID: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> I was just able to kill this process before my system ran out of swap space: % ps -wwwlp 95345 UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? 0:22.91 /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ RTHeapDebug.mc -o RTHeapDebug.ms It had already acquired more than 16 GB. Any ideas? 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 hendrik at topoi.pooq.com Fri Aug 27 21:38:37 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 15:38:37 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> Message-ID: <20100827193836.GC8903@topoi.pooq.com> On Fri, Aug 27, 2010 at 08:55:55PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > >> cvs checkout gives you a checked out working directory not a repository. >> You'd need to *copy* the repository hierarchy verbatim. > > The CM3 repository is on birch.elegosoft.com:/usr/cvs > It contains CVSROOT and cm3 as CVS modules. > CVSROOT contains metainformation about the versions. You'll > probably need it for git conversion. > > You can get the whole repository via cvsup, rsync or scp. The last > two require an ssh account on birch. > > Olaf > > PS: I did mention that Peter Eiserloh is also working on a git > conversion of our history? No. From discussions half a year ago or longer, I thought that monotone was the preferred solution. Git is easier, I suppose, because no one has to write anything to feed git-fast-import into monotone. And a git-fast-import file would probably be the first step to get it into monotone anyway, since the direct cvs import I tried into monotone failed one of monotone's internal sanity checks. Perhaps this means I don't have to do the cvs2mtn stuff any more. Not for Modula 3, anyway. Though git2mtn might still be useful for others. -- hendrik > >> On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: >> >>> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >>>> I was tinkering with a copy of the Modula 3 cvs repository I had made >>>> a few months ago using cvsup, seeing of cvs2git would make me a proper >>>> git-fast-import file. It complained that what I provided wasn't a valid >>>> CVS repository: >>>> >>>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >>>> repository, nor a path within a CVS repository. A CVS repository >>>> contains a CVSROOT directory within its root directory. >>>> >>>> Now I looked around, and couldn't find a CVSROOT directory anywhere >>>> except in /usr/lib/cvs, which is probably irrelevant. >>>> >>>> Is this a problem with cvs2git, a problem with the repository, or a >>>> problem with cvsup, or a problem with the way I used cvsup to copy the >>>> repository? Or would any regular cvs user know just exactly what to do? >>> >>> Should I perhaps just create an empty CVSROOT directory somewhere? >>> >>> In case it indicates what I did wrong, an ancient log indicates that >>> when I created the copy of the repository in the first place, I used the >>> commands >>> >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 >>> >>> -- hendrik >> >> > > > > -- > 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 Sat Aug 28 00:05:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 22:05:38 +0000 Subject: [M3devel] cm3cg running amok In-Reply-To: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> Message-ID: Hm. I've only been testing AMD64_DARWIN lately. ? > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg This path -- to m3-sys/m3cc: When I made the pop_struct change, I changed my cm3cfg.common to only use $PATH, and not root around in the CVS tree. To use old cm3cg with old cm3, new cm3cg with new cm3. Could that be the problem here? ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 21:29:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] cm3cg running amok > > I was just able to kill this process before my system ran out of swap > space: > > % ps -wwwlp 95345 > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? > 0:22.91 > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ RTHeapDebug.mc -o > RTHeapDebug.ms > > It had already acquired more than 16 GB. > > Any ideas? > > 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 Sat Aug 28 00:15:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 22:15:42 +0000 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827193836.GC8903@topoi.pooq.com> References: <20100827173502.GA8777@topoi.pooq.com>, <20100827180902.GA8903@topoi.pooq.com>, , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, <20100827193836.GC8903@topoi.pooq.com> Message-ID: > I thought that monotone was the preferred solutionMy "ressearch" (not really worth calling it that), suggests the following are good options, roughly in this order: ?perforce ("p4") ?mercurial ("hg") ?git ?monotone ("mtn")? ?subversion ("svn") ?subversion doesn't do branching right, but for us it probably is good enough. ?Perforce is my favorite by far. I know very well how to use it and it works very well. ?I just could never find a hoster for it. ?svn's familiar centralized model might put it up at #2 after p4. ?hg is said to be easier to use and understand than git. ?hg and git seems to be the running favorites of the distributed systems. ?mtn was rejected by Linus because it was too slow. It is better now and ?? probably ok. svn doesn't do branching right and isn't distibuted, but as I said, maybe #2. It also pays to use the heavily used systems. They become the most reliable. (Modula-3 not necessarily a counterexcample...) ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 15:38:37 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] conversion to another version control system > > On Fri, Aug 27, 2010 at 08:55:55PM +0200, Olaf Wagner wrote: > > Quoting Tony Hosking : > > > >> cvs checkout gives you a checked out working directory not a repository. > >> You'd need to *copy* the repository hierarchy verbatim. > > > > The CM3 repository is on birch.elegosoft.com:/usr/cvs > > It contains CVSROOT and cm3 as CVS modules. > > CVSROOT contains metainformation about the versions. You'll > > probably need it for git conversion. > > > > You can get the whole repository via cvsup, rsync or scp. The last > > two require an ssh account on birch. > > > > Olaf > > > > PS: I did mention that Peter Eiserloh is also working on a git > > conversion of our history? > > No. From discussions half a year ago or longer, I thought that monotone > was the preferred solution. Git is easier, I suppose, because no one > has to write anything to feed git-fast-import into monotone. And > a git-fast-import file would probably be the first step to get it into > monotone anyway, since the direct cvs import I tried into monotone > failed one of monotone's internal sanity checks. > > Perhaps this means I don't have to do the cvs2mtn stuff any more. Not > for Modula 3, anyway. Though git2mtn might still be useful for others. > > -- hendrik > > > > >> On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > >> > >>> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: > >>>> I was tinkering with a copy of the Modula 3 cvs repository I had made > >>>> a few months ago using cvsup, seeing of cvs2git would make me a proper > >>>> git-fast-import file. It complained that what I provided wasn't a valid > >>>> CVS repository: > >>>> > >>>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS > >>>> repository, nor a path within a CVS repository. A CVS repository > >>>> contains a CVSROOT directory within its root directory. > >>>> > >>>> Now I looked around, and couldn't find a CVSROOT directory anywhere > >>>> except in /usr/lib/cvs, which is probably irrelevant. > >>>> > >>>> Is this a problem with cvs2git, a problem with the repository, or a > >>>> problem with cvsup, or a problem with the way I used cvsup to copy the > >>>> repository? Or would any regular cvs user know just exactly what to do? > >>> > >>> Should I perhaps just create an empty CVSROOT directory somewhere? > >>> > >>> In case it indicates what I did wrong, an ancient log indicates that > >>> when I created the copy of the repository in the first place, I used the > >>> commands > >>> > >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 > >>> > >>> -- hendrik > >> > >> > > > > > > > > -- > > 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 Sat Aug 28 00:31:51 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 28 Aug 2010 00:31:51 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: References: <20100827081459.s88b14400448owk8@mail.elegosoft.com>, , <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com>, <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> Message-ID: <20100828003151.nqk0l9d7w0owcswg@mail.elegosoft.com> I compiled the latest code on my FreeBSD 8 system and found that it sometimes hangs when shutting down the connection. Here is a backtrace: (m3gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x00000008033087dc in poll () from /lib/libc.so.7 (m3gdb) bt #0 0x00000008033087dc in poll () from /lib/libc.so.7 #1 0x000000080315a85e in poll () from /lib/libthr.so.3 #2 0x0000000801d7e0bd in ThreadInternal__Poll (fd=8, read=1, m3timeout=1) at ../src/thread/Common/ThreadInternal.c:31 #3 0x0000000801d8161a in XIOWait (Cannot resolve type with uid DMxDjQ ) at ../src/thread/PTHREAD/ThreadPThread.m3:627 #4 0x0000000801d814c2 in IOAlertWait (fd=8, read=TRUE, timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:603 #5 0x00000008012f1528 in ReadPipe (fd=8) at ../src/SigHandler.m3:221 #6 0x00000008012f0d80 in DoDispatch () at ../src/SigHandler.m3:138 #7 0x00000008012f0b58 in DispatcherRun (closure=16_00000008005cc378) at ../src/SigHandler.m3:112 #8 0x0000000801d806a5 in RunThread (Cannot resolve type with uid DMxDjQ ) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #9 0x0000000801d80359 in ThreadBase (param=16_0000000803c76f80) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #10 0x0000000803158511 in pthread_getprio () from /lib/libthr.so.3 #11 0x0000000000000000 in ?? () There seem to be no other threads at this point. Olaf Quoting Jay K : > > Michael, thank you. Please add it to the bug. > > ?- Jay > > > ---------------------------------------- >> Date: Fri, 27 Aug 2010 13:25:57 +0200 >> From: michael.anderson at elego.de >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on >> several platforms >> >> Quoting Olaf Wagner : >> >> > Quoting Jay K : >> > >> >> Can you add more information to the bug as to how to reproduce >> the problem? >> >> Exact files? cvsup.conf or whatnot? >> >> Exact command lines? >> >> >> >> >> I'm able to reliably reproduce the problem with this command: >> >> /usr/local/cm3/bin/cvsup -g -L 2 cvsupfile.cm3 >> >> where the cvsupfile contains: >> >> *default host=birch.elego.de >> *default base=/home/mand/tmp/cvsup >> *default prefix=/home/mand/tmp/cvs >> *default release=cvs >> *default delete use-rel-suffix >> *default preserve >> cm3 >> >> Sometimes the first sync will finish, but a subsequent sync will hang. >> >> >> I don't use cvsup, don't know how to set it up. >> >> Before when I debugging this it wasn't too difficult though. >> >> >> >> Perhaps we can put something in m3-sys/m3tests even? >> > >> > I will try to set up an automated cvsup test at the weekend. >> > In our DCVS distribution we had quite a few replication tests; >> > perhaps I can burrow something from that. >> > >> > It won't go into m3tests though, but rather be a subdir to cvsup. >> > m3-sys/m3tests is for language/compiler tests. >> > >> > 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 >> >> >> >> -- >> Michael Anderson >> IT Services & Support >> >> elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 >> Building 12.3 (BIG) room 227 >> 13355 Berlin, Germany >> >> phone +49 30 23 45 86 96 michael.anderson at elegosoft.com >> fax +49 30 23 45 86 95 http://www.elegosoft.com >> >> Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin >> Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 >> >> > -- 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 Sat Aug 28 00:38:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 28 Aug 2010 00:38:39 +0200 Subject: [M3devel] cm3cg running amok In-Reply-To: References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> Message-ID: <20100828003839.izqrqjd14w44owk4@mail.elegosoft.com> Quoting Jay K : > Hm. I've only been testing AMD64_DARWIN lately. > ? > > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg > > This path -- to m3-sys/m3cc: > When I made the pop_struct change, I changed my cm3cfg.common to > only use $PATH, and not root around > in the CVS tree. To use old cm3cg with old cm3, new cm3cg with new cm3. > Could that be the problem here? I don't know. It was part of the Hudson regression, so the upgrade should have been done properly. Let's just see if it happens again. I need to get some sleep now, 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 rodney_bates at lcwb.coop Sat Aug 28 03:43:36 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 Aug 2010 20:43:36 -0500 Subject: [M3devel] cm3cg running amok In-Reply-To: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> Message-ID: <4C7869C8.7050600@lcwb.coop> The ticked #1147 I reported a couple of weeks ago would probably show this symptom. That was AMD64_LINUX. Hmm, I think I never got back to supplying the attachment .ms file to reproduce. I'll try to do that tomorrow. I need sleep now too. Olaf Wagner wrote: > I was just able to kill this process before my system ran out of swap > space: > > % ps -wwwlp 95345 > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? 0:22.91 > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg > -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 > -gstabs+ RTHeapDebug.mc -o RTHeapDebug.ms > > It had already acquired more than 16 GB. > > Any ideas? > > Olaf From darko at darko.org Sat Aug 28 08:31:13 2010 From: darko at darko.org (Darko) Date: Fri, 27 Aug 2010 23:31:13 -0700 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, <20100827180902.GA8903@topoi.pooq.com>, , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, <20100827193836.GC8903@topoi.pooq.com> Message-ID: <45AF1046-B964-4509-878D-406269EEA3EC@darko.org> FWIW, I like and use mercurial which has good support generally. Perforce is commercial and proprietary. On 27/08/2010, at 3:15 PM, Jay K wrote: > >> I thought that monotone was the preferred solutionMy "ressearch" (not really worth calling it that), suggests the following are good > options, roughly in this order: > > perforce ("p4") > mercurial ("hg") > git > monotone ("mtn") > subversion ("svn") > > subversion doesn't do branching right, but for us it probably is good enough. > Perforce is my favorite by far. I know very well how to use it and it works very well. > I just could never find a hoster for it. > > svn's familiar centralized model might put it up at #2 after p4. > hg is said to be easier to use and understand than git. > hg and git seems to be the running favorites of the distributed systems. > mtn was rejected by Linus because it was too slow. It is better now and > probably ok. > svn doesn't do branching right and isn't distibuted, but as I said, maybe #2. > > > It also pays to use the heavily used systems. They become the most > reliable. (Modula-3 not necessarily a counterexcample...) > > > - Jay > > ---------------------------------------- >> Date: Fri, 27 Aug 2010 15:38:37 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] conversion to another version control system >> >> On Fri, Aug 27, 2010 at 08:55:55PM +0200, Olaf Wagner wrote: >>> Quoting Tony Hosking : >>> >>>> cvs checkout gives you a checked out working directory not a repository. >>>> You'd need to *copy* the repository hierarchy verbatim. >>> >>> The CM3 repository is on birch.elegosoft.com:/usr/cvs >>> It contains CVSROOT and cm3 as CVS modules. >>> CVSROOT contains metainformation about the versions. You'll >>> probably need it for git conversion. >>> >>> You can get the whole repository via cvsup, rsync or scp. The last >>> two require an ssh account on birch. >>> >>> Olaf >>> >>> PS: I did mention that Peter Eiserloh is also working on a git >>> conversion of our history? >> >> No. From discussions half a year ago or longer, I thought that monotone >> was the preferred solution. Git is easier, I suppose, because no one >> has to write anything to feed git-fast-import into monotone. And >> a git-fast-import file would probably be the first step to get it into >> monotone anyway, since the direct cvs import I tried into monotone >> failed one of monotone's internal sanity checks. >> >> Perhaps this means I don't have to do the cvs2mtn stuff any more. Not >> for Modula 3, anyway. Though git2mtn might still be useful for others. >> >> -- hendrik >> >>> >>>> On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: >>>> >>>>> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >>>>>> I was tinkering with a copy of the Modula 3 cvs repository I had made >>>>>> a few months ago using cvsup, seeing of cvs2git would make me a proper >>>>>> git-fast-import file. It complained that what I provided wasn't a valid >>>>>> CVS repository: >>>>>> >>>>>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >>>>>> repository, nor a path within a CVS repository. A CVS repository >>>>>> contains a CVSROOT directory within its root directory. >>>>>> >>>>>> Now I looked around, and couldn't find a CVSROOT directory anywhere >>>>>> except in /usr/lib/cvs, which is probably irrelevant. >>>>>> >>>>>> Is this a problem with cvs2git, a problem with the repository, or a >>>>>> problem with cvsup, or a problem with the way I used cvsup to copy the >>>>>> repository? Or would any regular cvs user know just exactly what to do? >>>>> >>>>> Should I perhaps just create an empty CVSROOT directory somewhere? >>>>> >>>>> In case it indicates what I did wrong, an ancient log indicates that >>>>> when I created the copy of the repository in the first place, I used the >>>>> commands >>>>> >>>>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login >>>>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 >>>>> >>>>> -- hendrik >>>> >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > From dragisha at m3w.org Sat Aug 28 10:12:52 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Aug 2010 10:12:52 +0200 Subject: [M3devel] conversion to another version control system In-Reply-To: <45AF1046-B964-4509-878D-406269EEA3EC@darko.org> References: <20100827173502.GA8777@topoi.pooq.com> , <20100827180902.GA8903@topoi.pooq.com> , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> , <20100827193836.GC8903@topoi.pooq.com> <45AF1046-B964-4509-878D-406269EEA3EC@darko.org> Message-ID: <1282983172.2770.71.camel@boromir.m3w.org> I use mercurial from time to time and from what I found it's excellent little package. Does its work well, is distributed, supported by trac... What else we need? :) On Fri, 2010-08-27 at 23:31 -0700, Darko wrote: > FWIW, I like and use mercurial which has good support generally. > Perforce is commercial and proprietary. -- Dragi?a Duri? From jay.krell at cornell.edu Sat Aug 28 10:40:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Aug 2010 08:40:29 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <4C77D7D3.6070602@lcwb.coop> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , <4C77D7D3.6070602@lcwb.coop> Message-ID: > > There is no way a debugger that has no Modula-3 awareness is going to provide > a Modula-3-like view. The operators will have C spellings and C semantics, How many operators do people use in a debugger? I use very few. Partly because for a long time I used a debugger with a great gui and an awful expression evaluator. Still, I use basically only "+" "->" "*" (dereference) and "=" for assignment. ?Sometimes multiplication and subtraction. I agree it would be nice if all the C debuggers would be lenient about "->" vs. ".". ? That would unify Modula-3, Java, C#, C, C++. ?? Except where C++ has an operator-> overload. But operator overload ?? is an area where.. tangent... C++ is a great language..my compiler implements ?? it well..but my debugger, my editor, plain text search.. can't cope with it. ?? Modula-3, C#, Java run afoul of plain text search too -- anything with prevalent "scoped names". ?? In C you get Window_Init, File_Open, etc. never just Init or Open. ?? How do you search for calls to operator+ in C++? For a certain type? ?? In C, except for the builtin types, they'd be unique function names. ? Anyway, tangent over. + is the same in the various languages. I think "=", ":=", "==" are the main problem. You might try a compare and accidentally to an assignment. > The syntax will be strictly C. Almost the same. ?> The display of values will be C. Almost the same. Also if you have a particularly good C compiler/debugger, we could do ? #define AND &&? ? #define OR ||? getting you back those two operators, which I rarely use in a debugger. ?> TEXT won't work in any reasonable way at all. Sure it might. In Visual Studio you can write little addins to help the debugger display stuff. I believe there is a small builtin "language" or I believe you can write actual code. In Windbg you can write little plugins. You could provide like !m3.text. I don't know if you can tell the debugger ahead of time how to custom display types. I don't know if gdb has a story here. Still, one might imagine a *small* patch to gdb. ?> Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 ?> type info would be lost, and output formats would lose. Um, you think maybe this stuff was done the wrong way in the first place? ?That the names shouldn't be mangled in the first place? ? I strongly suspect so. Other systems don't depend on this. ?? (Yes, I know about C++ name mangling, and even though it does something similar, ?? that's a trick for the linker and now how debug information works. It for ?? in the absence of debug information, among other reasons.) There is "naturally" type information you get just by building up decent gcc trees. Ditto for intermediate C code. For a while you know, every record is a void* or just has a size, and all the type information is buried in the names. This is questionable. I'm sure it has some advantages. You can describe things maybe not easily described in C. ? e.g. Subranges? And then our code in m3gdb is probably very portable, in that, I think, we just ferry along some strings, from our code to our code, and we can decipher them the same in all systems. I think, I'm not sure, there is like no dependence on the vagaries of coff, dwarf, etc., and what they can or cannot represent. However there is a dependency on stabs being available. It is not for example available on HP-UX. Furthermore the lack of correct type information, apart from stabs, causes problems. For some targets the backend wants accurate type information to pass records by value. I again/still think we should probably not rely on the backend for this anyway. We should probably make a copy and pass a pointer to it, kind of like m3x86 does. ?> Things that use pointers at the machine level can never know whether the pointers ?> point to a single value or an array, and if the latter, with what bounds. C programmers can cope with that. Can't we? And..I admit.. I don't know what our machine level mapping looks like. Do we pass a pointer and a size as two parameters? Or a small record with pointer/size by value? The debugger need not be a full blown Modula-3 interpreter. > Probably the worst thing will be calls. They just don't work without the debugger > having knowledge of a lot of stuff. There are extra hidden parameters, method > calls, passing procedure-typed parameters with environments, calling the same, > the three modes of Modula-3, etc. I consider calls in debugger commands very > valuable. I use calls very rarely. I'm not super keen on running some of my code when otherwise my code is all frozen and some of it is misbehaving. I know this is partly me. Even so, generally you only call certain functions that put there for use from a debugger, right? Like gcc's debug_node or such? And they tend to not be fancy? And the extra parameters..debugger would complain about missing them, programmer would figure it out? I'm not saying there aren't drawbacks here. But there are also major advantages. There are major costs and drawbacks to our current approach. ? We have a ton of extra code. ? Which I don't think we are well equipped for. ? Maybe Tony is. Maybe someone else is. I'm not. ? Partly, I'll admit, anything I write, I am much more able to maintain. Or, another lazy angle, anything smaller is easier to maintain. In gcc we have a large code base. It takes me a long time to get just slightly up to speed on it. We have several nagging problems with it. Maybe I just need to look at the C front end more. Or read tree.h. I don't know. ?4.5.1 doesn't work with SPARC32_SOLARIS/SOLgnu/SOLsun. ?4.3.5 maybe not either. ?A few optimizations I have turned off for 4.5.1 because they cause problems. Including inlining. ?Maybe I just need to debug more. ?Apple and OpenBSD each maintain their own forks. So that, *sort of but not really*, triples things. ?? (now, they are all highly related, so it doesn't) So far we don't have the OpenBSD fork. ? But for example 4.5.1 doesn't have the OpenBSD/powerpc stuff quite. And there is a small OpenBSD/mips64 ?? problem I worked around. Minor, I guess. We could just drop these platforms, or OpenBSD entirely. ? Not a huge deal. But it is yet more stuff that C as an intermediate platform solves. ? Exception handling stinks on all platforms but SOLsun/SOLgnu. ?? The ALPHA_OSF code no longer works. I tried. ? Generating C/C++ would significantly improve exception handling nearly across the board. ?? It is possible otherwise, but much more difficult. So, again, C as intermediate code isn't perfect or without drawbacks, but it promises: ? greatly increased portability ? more efficient exception handling ? better codegen by letting the optimizer be full on, even acrosss modules with some C compilers (gcc 4.5, Visual C++, at least) ? better debugging with stock debuggers (including Visual C++, windbg) ? a portable distribution format -- no more having to distribute binaries, though they still have advantages ???? easier to get into the various "ports" systems I think as a result ? a much smaller system overall (no GPL, if it matters) Again, there are drawbacks, but it just seems so very tempting. I'm sure I'll plug away at m3cc a while longer, but I think more and more it is questionable. I can try again to read the LLVM stuff. A new backend I think is unavoidably a lot of work, be it C or LLVM. That's my hangup on both of these. It requires knowing a lot about two big things -- M3CG and the underlying generator. parse.c is "only" 6,000 lines but pretty dense in terms of information gone into it. Maybe I'm just feeling dumb. The thing about C though, is it is a very well understood next layer down. Certainly compared to the gcc trees or LLVM. I don't think it is just me, that I'm some C expert. > This could probably be improved a lot by switching to a better debug info format, > probably the latest Dwarf variant. But that is a big job. I don't believe we have to do *anything* sort of to switch debug formats. We just have to provide gcc with decently formed typeful trees. It should do the rest. Currently I guess it is all custom. I tried -g again, thinking maybe things were better now. It still crashes. It seems related to the fact that _m3_fault is in an unknown location. But that seems actually deliberate and reasonable, and I tried fiddling with it anyway. No luck yet. This debug format problem is also solved by using C intermediate code. You just use -g or -gdb or -Zi or whatever, whatever is normal for C, and it'd just work. Anyway.. ?- Jay From jay.krell at cornell.edu Sat Aug 28 10:46:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Aug 2010 08:46:51 +0000 Subject: [M3devel] conversion to another version control system In-Reply-To: <1282983172.2770.71.camel@boromir.m3w.org> References: <20100827173502.GA8777@topoi.pooq.com>,, <20100827180902.GA8903@topoi.pooq.com>,, ,, <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>,, <20100827193836.GC8903@topoi.pooq.com>, , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, <1282983172.2770.71.camel@boromir.m3w.org> Message-ID: Perforce is closed source, but it is free of charge ("free beer") for Open Source work. It is an excellent excellent system and I can provide good support here for it, writing up introductory and advanced material and answering questions. It is easy to use. It is just an excellent system and I've used it *a lot*. FreeBSD and OpenWatcom use it. The FreeBSD Perforce repository: ? http://p4web.freebsd.org/@md=d&cd=//&c=0qt@//?ac=83 The OpenWatcom Perforce repository: http://perforce.openwatcom.org:4000/@md=d&cd=//&c=bxM@//?ac=83 ?- Jay ---------------------------------------- > From: dragisha at m3w.org > To: darko at darko.org > Date: Sat, 28 Aug 2010 10:12:52 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] conversion to another version control system > > I use mercurial from time to time and from what I found it's excellent > little package. Does its work well, is distributed, supported by trac... > What else we need? :) > > On Fri, 2010-08-27 at 23:31 -0700, Darko wrote: > > FWIW, I like and use mercurial which has good support generally. > > Perforce is commercial and proprietary. > -- > Dragi?a Duri? > From darko at darko.org Sat Aug 28 10:56:11 2010 From: darko at darko.org (Darko) Date: Sat, 28 Aug 2010 01:56:11 -0700 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, , <20100827180902.GA8903@topoi.pooq.com>, , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , <20100827193836.GC8903@topoi.pooq.com>, , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, <1282983172.2770.71.camel@boromir.m3w.org> Message-ID: <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org> I sort of meant software support. But isn't this all academic since Elego is a CVS shop and they host the project? On 28/08/2010, at 1:46 AM, Jay K wrote: > > Perforce is closed source, but it is free of charge ("free beer") for Open Source work. > > > It is an excellent excellent system and I can provide good support here for it, > writing up introductory and advanced material and answering questions. > It is easy to use. > It is just an excellent system and I've used it *a lot*. > > > FreeBSD and OpenWatcom use it. > The FreeBSD Perforce repository: http://p4web.freebsd.org/@md=d&cd=//&c=0qt@//?ac=83 > The OpenWatcom Perforce repository: http://perforce.openwatcom.org:4000/@md=d&cd=//&c=bxM@//?ac=83 > > > - Jay > > ---------------------------------------- >> From: dragisha at m3w.org >> To: darko at darko.org >> Date: Sat, 28 Aug 2010 10:12:52 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] conversion to another version control system >> >> I use mercurial from time to time and from what I found it's excellent >> little package. Does its work well, is distributed, supported by trac... >> What else we need? :) >> >> On Fri, 2010-08-27 at 23:31 -0700, Darko wrote: >>> FWIW, I like and use mercurial which has good support generally. >>> Perforce is commercial and proprietary. >> -- >> Dragi?a Duri? >> > From jay.krell at cornell.edu Sat Aug 28 11:54:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Aug 2010 09:54:54 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: , Message-ID: Interesting. TYPE Color1 = RECORD a,b,c: REAL; END; TYPE Color2 = RECORD a,b,c: REAL; END; Have the same id. If the module defining them also imports an interface with a type with the same id, ? or I think, if its interface defines a type with same id (same thing I think, ? no relationship at the cg level between a module and its interface), then the declare_records are skipped. The fix is probably something simple in Type.Compile involve the order it checks the tables in when deciding to call t.compile or not. Or can it just always call t.compile? Worst thing is that extra type information created? A lot of it? (all types in all imports, instead of just the used ones??) ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] importing types not described to backend > Date: Fri, 27 Aug 2010 18:35:00 +0000 > > > Very wierd: > > MODULE Main; > IMPORT Color; > TYPE ColorT = RECORD a,b,c: REAL; END; > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > BEGIN > END F1; > > BEGIN > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > END Main. > > > This fails. If you remove the IMPORT, it worked. > The declare_record of ColorT comes and goes with that change. > So I guess the error really is in F1. > > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Fri, 27 Aug 2010 18:28:47 +0000 > > Subject: [M3devel] importing types not described to backend > > > > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > > > INTERFACE Color; > > TYPE T = RECORD a,b,c:REAL; END; > > END Color. > > > > > > MODULE Main; > > IMPORT Color; > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > BEGIN > > END F1; > > > > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > > BEGIN > > END F2; > > > > > > BEGIN > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > > END Main. > > > > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > > ../Main.m3: In function 'Main__F1': > > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > > > > I fixed it so F1 is ok. > > But still F2 isn't. > > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > > > > The problem as I understand is we don't tell the backend about imported types. > > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > > > > I intend to fix this if I don't here any objections. > > I'm hoping it isn't too much work. > > I believe it will mostly/all be in m3front. > > > > > > My opinion of our gcc backend drops.. > > > > > > Perhaps the time is better used on a C front end. > > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > > > > Thanks, > > - Jay > > > From rodney_bates at lcwb.coop Sat Aug 28 21:15:02 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 28 Aug 2010 14:15:02 -0500 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , <4C77D7D3.6070602@lcwb.coop> Message-ID: <4C796036.1000806@lcwb.coop> Jay K wrote: > >> There is no way a debugger that has no Modula-3 awareness is going to provide >> a Modula-3-like view. The operators will have C spellings and C semantics, > > > How many operators do people use in a debugger? > > I use very few. Partly because for a long time I used a debugger > with a great gui and an awful expression evaluator. > > > Still, I use basically only "+" "->" "*" (dereference) and "=" for assignment. > Sometimes multiplication and subtraction. > I agree it would be nice if all the C debuggers would be lenient about "->" vs. ".". > That would unify Modula-3, Java, C#, C, C++. > Except where C++ has an operator-> overload. But operator overload > is an area where.. tangent... C++ is a great language..my compiler implements > it well..but my debugger, my editor, plain text search.. can't cope with it. > Modula-3, C#, Java run afoul of plain text search too -- anything with prevalent "scoped names". > In C you get Window_Init, File_Open, etc. never just Init or Open. > How do you search for calls to operator+ in C++? For a certain type? > In C, except for the builtin types, they'd be unique function names. > Anyway, tangent over. > > > + is the same in the various languages. > > I think "=", ":=", "==" are the main problem. > You might try a compare and accidentally to an assignment. > > >> The syntax will be strictly C. > > Almost the same. > > > > The display of values will be C. > > Almost the same. On the strength of your comments, I rest my case. > > Also if you have a particularly good C compiler/debugger, we could do > #define AND && > #define OR || > > > getting you back those two operators, which I rarely use in a debugger. > > > > TEXT won't work in any reasonable way at all. > > Sure it might. > In Visual Studio you can write little addins to help the debugger display stuff. > I believe there is a small builtin "language" or I believe you can write actual code. > In Windbg you can write little plugins. You could provide like !m3.text. > I don't know if you can tell the debugger ahead of time how to custom display types. > I don't know if gdb has a story here. > Still, one might imagine a *small* patch to gdb. All of which is just different ways of providing a debugger with proper Modula-3 support. > > > > Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 > > type info would be lost, and output formats would lose. > > > Um, you think maybe this stuff was done the wrong way in the first place? > That the names shouldn't be mangled in the first place? > I strongly suspect so. Other systems don't depend on this. > (Yes, I know about C++ name mangling, and even though it does something similar, > that's a trick for the linker and now how debug information works. It for > in the absence of debug information, among other reasons.) > I think it could be done a lot better if switching to a better debug info format. stabs may have been the best option around at the time it was done. And I don't know if Modula-3's structural type equivalence rules could be supported any better without the uid's. But there will still have to be name mangling to get a standard linker to work, with just about any language. Stock gdb does what it does in part because it has builtin demanglers for the various languages it supports. It chooses the appropriate demangler dynamically. It would be a pretty ugly user interface if it didn't. > There is "naturally" type information you get just by building up decent gcc trees. > Ditto for intermediate C code. > For a while you know, every record is a void* or just has a size, and all the type information > is buried in the names. This is questionable. I'm sure it has some advantages. > You can describe things maybe not easily described in C. > e.g. Subranges? > And then our code in m3gdb is probably very portable, in that, I think, we just ferry along > some strings, from our code to our code, and we can decipher them the same in all systems. > I think, I'm not sure, there is like no dependence on the vagaries of coff, dwarf, etc., and > what they can or cannot represent. However there is a dependency on stabs being available. > It is not for example available on HP-UX. > > > Furthermore the lack of correct type information, apart from stabs, causes problems. > For some targets the backend wants accurate type information to pass records by value. > I again/still think we should probably not rely on the backend for this anyway. > We should probably make a copy and pass a pointer to it, kind of like m3x86 does. > Certainly, a back end needs type information for code generation. That won't do much to help a debugger that is oblivious to the source language. > > > Things that use pointers at the machine level can never know whether the pointers > > point to a single value or an array, and if the latter, with what bounds. > > > C programmers can cope with that. Can't we? Look at the security advisories. Buffer overflow, buffer overrun, buffer overflow, ... over and over. Almost all of them are buffer overruns. But that's a tangent too. > And..I admit.. I don't know what our machine level mapping looks like. > Do we pass a pointer and a size as two parameters? Or a small record with pointer/size by value? > If it's a fixed array, its all in the static type, which the stabs (as extended for Modula-3) info conveys. If it's an open array, there is runtime dope: a pointer to the zero-th array element, followed by a shape, which is just a list of words giving the NUMBER of each dimension. The dimension count is statically known. generally passed by reference, although it is never altered. For heap-allocated arrays, it's located right in the heap object, at the beginning, making the pointer redundant. For Formal parameters, if the actual doesn't already have the needed dope, it is constructed at runtime by code at the call site. This works for, e.g., passing a fixed array or a SUBARRAY to a formal that is open. BTW, this is another thing a debugger has to know about to either pass, display, or alter open array values. Perhaps Dwarf is sophisticated enough that it could just be encoded in Dwarf, but certainly not in stabs. (Well, we could probably cobble up yet another stabs extension, but that would still require specialized debugger support.) > > The debugger need not be a full blown Modula-3 interpreter. > > >> Probably the worst thing will be calls. They just don't work without the debugger >> having knowledge of a lot of stuff. There are extra hidden parameters, method >> calls, passing procedure-typed parameters with environments, calling the same, >> the three modes of Modula-3, etc. I consider calls in debugger commands very >> valuable. > > > I use calls very rarely. > I'm not super keen on running some of my code when otherwise my code is all frozen > and some of it is misbehaving. I know this is partly me. > > > Even so, generally you only call certain functions that put there for use from a debugger, right? > Like gcc's debug_node or such? > And they tend to not be fancy? I regularly type a debugger call to rexecute something that I just stepped over, not knowing whether the problem I am looking for would occur inside the procedure or not. Reverse debugging in the newest gdb could provide an alternative, but I am hearing that the necessary recording costs ~ n*10 slowdown. I also do it as an easy way to test some parameter combination. Kind of like having an interpreter for the language. And I do it with fancy procedures that format some elaborate data structure in a readable, high-level way, which is, I think, what you meant. Sometimes a *lot* of effort. > > And the extra parameters..debugger would complain about missing them, programmer would figure it out? Before I got call support working, I found there were many calls I could not make work at all. Either I couldn't figure out what was needed (This amounts, in part, to manually reading stabs), or there was no way to supply what was needed in a debugger command. Also, on method calls, there was no way to figure out where it would dispatch to, even when you could locate all the possible overrides in all the subtypes, in all the source files of the closure. Language-specific support can take care of this, when done completely. m3gdb is a long way from there now, but it helps a lot. > > > I'm not saying there aren't drawbacks here. > But there are also major advantages. > There are major costs and drawbacks to our current approach. > We have a ton of extra code. > Which I don't think we are well equipped for. > Maybe Tony is. Maybe someone else is. I'm not. > > > Partly, I'll admit, anything I write, I am much more able to maintain. > Or, another lazy angle, anything smaller is easier to maintain. > > > In gcc we have a large code base. It takes me a long time to get just slightly up to speed on it. > We have several nagging problems with it. Maybe I just need to look at the C front end more. > Or read tree.h. I don't know. > > > 4.5.1 doesn't work with SPARC32_SOLARIS/SOLgnu/SOLsun. > 4.3.5 maybe not either. > A few optimizations I have turned off for 4.5.1 because they cause problems. Including inlining. > Maybe I just need to debug more. > Apple and OpenBSD each maintain their own forks. So that, *sort of but not really*, triples things. > (now, they are all highly related, so it doesn't) So far we don't have the OpenBSD fork. > But for example 4.5.1 doesn't have the OpenBSD/powerpc stuff quite. And there is a small OpenBSD/mips64 > problem I worked around. Minor, I guess. We could just drop these platforms, or OpenBSD entirely. > Not a huge deal. But it is yet more stuff that C as an intermediate platform solves. > Exception handling stinks on all platforms but SOLsun/SOLgnu. > The ALPHA_OSF code no longer works. I tried. > Generating C/C++ would significantly improve exception handling nearly across the board. > It is possible otherwise, but much more difficult. > > > So, again, C as intermediate code isn't perfect or without drawbacks, but it promises: > greatly increased portability > more efficient exception handling > better codegen by letting the optimizer be full on, even acrosss modules with some C compilers (gcc 4.5, Visual C++, at least) > better debugging with stock debuggers (including Visual C++, windbg) > a portable distribution format -- no more having to distribute binaries, though they still have advantages > easier to get into the various "ports" systems I think as a result > a much smaller system overall (no GPL, if it matters) > > > Again, there are drawbacks, but it just seems so very tempting. > > > I'm sure I'll plug away at m3cc a while longer, but I think more and more it is questionable. > > > I can try again to read the LLVM stuff. > > > A new backend I think is unavoidably a lot of work, be it C or LLVM. > That's my hangup on both of these. It requires knowing a lot about two big things -- M3CG and the underlying generator. > parse.c is "only" 6,000 lines but pretty dense in terms of information gone into it. Maybe I'm just feeling dumb. > > > The thing about C though, is it is a very well understood next layer down. Certainly compared to > the gcc trees or LLVM. I don't think it is just me, that I'm some C expert. > > > >> This could probably be improved a lot by switching to a better debug info format, >> probably the latest Dwarf variant. But that is a big job. > > > I don't believe we have to do *anything* sort of to switch debug formats. > We just have to provide gcc with decently formed typeful trees. > It should do the rest. > Currently I guess it is all custom. It doesn't provide nearly enough information in stock form. The "stabs" it now produces has a lot of Modula-3-specific stuff crammed inside the fields of stabs entries. This had be be added by the original implementors of the gcc backend. A different debug format will need changes to gcc to emit what is needed. However, it might well be entirely within the "llanguage" of, say Dwarf, which is very general. It certainly would be a lot cleaner, and it could easily be completed in places that are now hard. So there would still be a lot of work. I don't completely understand where the current back end emits all the stabs stuff, but I believe all or almost all of it comes through code in parse.c calling utility code (dbxout.c, e.g.), and is not much taken from the trees gcc uses. This is why I have yet to figure out how to write correct debug info describing the locations of static links, since gcc develops this information by transforming trees, after parse.c has done its thing. > > I tried -g again, thinking maybe things were better now. It still crashes. > It seems related to the fact that _m3_fault is in an unknown location. > But that seems actually deliberate and reasonable, and I tried fiddling with it anyway. > No luck yet. > > > This debug format problem is also solved by using C intermediate code. > You just use -g or -gdb or -Zi or whatever, whatever is normal for C, and it'd just work. > Lots of things, TEXT being probably the worst, won't display in a Modula-3 form this way. And things in expressions/statements won't work either. A debugger user will have to understand a lot of low-level stuff about how the C back end translates Modula-3 code to C, to use it at all, and it will still be far less convenient. > > Anyway.. > - Jay > From mvfranz at gmail.com Sun Aug 29 01:06:45 2010 From: mvfranz at gmail.com (Michael Franz) Date: Sat, 28 Aug 2010 19:06:45 -0400 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system Message-ID: Hi, I have been reading Systems Programming with Modula-3, edited by Greg Nelson. The chapter on Trestle refers to SRC Report 69 - Performance analysis of a multiprocessor window system. I have some link on the web, but they are all broken. The one that did work I cannot display. Does anyone know where I can get the pdf version? Thank you Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Aug 29 01:51:57 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 28 Aug 2010 18:51:57 -0500 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system In-Reply-To: References: Message-ID: <4C79A11D.8010008@lcwb.coop> Inside the cm3 CVS release branch (cm3-58--release) (and no doubt the head too), is file doc/src_reports/src-069.pdf. When I open it, its title page has report number 69 and title "Trestle Tutorial", which agrees with its contents. It is hard to image SRC would have ambiguously numbered reports. The report number must be a mistake in the citation. I have a printed copy of SRC 135a, with a listing in the back of the reports through 133b, with no mention of that title. Not much help, but it might help structure searches more effectively. I think copies of a lot of the SRC stuff are still online somewhere, but I don't remember where. Perhaps an HP site? Michael Franz wrote: > Hi, > > I have been reading Systems Programming with Modula-3, edited by Greg > Nelson. The chapter on Trestle refers to SRC Report 69 - Performance > analysis of a multiprocessor window system. I have some link on the > web, but they are all broken. The one that did work I cannot display. > Does anyone know where I can get the pdf version? > > Thank you > > Michael From rodney_bates at lcwb.coop Sun Aug 29 02:02:17 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 28 Aug 2010 19:02:17 -0500 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system In-Reply-To: <4C79A11D.8010008@lcwb.coop> References: <4C79A11D.8010008@lcwb.coop> Message-ID: <4C79A389.1070202@lcwb.coop> Rodney M. Bates wrote: > Inside the cm3 CVS release branch (cm3-58--release) (and no doubt the > head too), > is file doc/src_reports/src-069.pdf. When I open it, its title page has > report > number 69 and title "Trestle Tutorial", which agrees with its contents. > It is hard to image SRC would have ambiguously numbered reports. > The report number must be a mistake in the citation. > > I have a printed copy of SRC 135a, with a listing in the back of the > reports > through 133b, with no mention of that title. > > Not much help, but it might help structure searches more effectively. > > I think copies of a lot of the SRC stuff are still online somewhere, but I > don't remember where. Perhaps an HP site? P.S.: http://www.hpl.hp.com/techreports/Compaq-DEC/ has them. But not that title. P.P.S. If you are seriously reading either the Trestle tutorial or reference manual are puzzled the concept of a "share of a mutex", I can help, if I can remember it. It took me years to figure out what it meant. > > Michael Franz wrote: >> Hi, >> >> I have been reading Systems Programming with Modula-3, edited by Greg >> Nelson. The chapter on Trestle refers to SRC Report 69 - Performance >> analysis of a multiprocessor window system. I have some link on the >> web, but they are all broken. The one that did work I cannot display. >> Does anyone know where I can get the pdf version? >> >> Thank you >> >> Michael > From jay.krell at cornell.edu Sun Aug 29 02:21:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 00:21:31 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <4C796036.1000806@lcwb.coop> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, ,,, , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , , , <4C77D7D3.6070602@lcwb.coop>, , <4C796036.1000806@lcwb.coop> Message-ID: Ps we don't even have m3gdb for all systems e.g. Darwin, and the Windows debuggers are much better than anything I've seen on Unix. On these systems intermediate C would improve debugging much. Though Darwin gdb I've also been improving. Also you seem to confuse C name mangling with what Modula-3 does. They are quite different. C only mangles things with linkage, for linking reasons, not for debugging information. Locals, parameters, record fields: no mangling. C code analogous to what Modula-3 allows would survive with everything being extern C, no name mangling. In both cases as I understand, an effective hack to tunnel information through systems not quite designed/extended to suit. What we have is flawed. What I favor is flawed. But differently. - Jay/phone > Date: Sat, 28 Aug 2010 14:15:02 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? > > > > Jay K wrote: > > > >> There is no way a debugger that has no Modula-3 awareness is going to provide > >> a Modula-3-like view. The operators will have C spellings and C semantics, > > > > > > How many operators do people use in a debugger? > > > > I use very few. Partly because for a long time I used a debugger > > with a great gui and an awful expression evaluator. > > > > > > Still, I use basically only "+" "->" "*" (dereference) and "=" for assignment. > > Sometimes multiplication and subtraction. > > I agree it would be nice if all the C debuggers would be lenient about "->" vs. ".". > > That would unify Modula-3, Java, C#, C, C++. > > Except where C++ has an operator-> overload. But operator overload > > is an area where.. tangent... C++ is a great language..my compiler implements > > it well..but my debugger, my editor, plain text search.. can't cope with it. > > Modula-3, C#, Java run afoul of plain text search too -- anything with prevalent "scoped names". > > In C you get Window_Init, File_Open, etc. never just Init or Open. > > How do you search for calls to operator+ in C++? For a certain type? > > In C, except for the builtin types, they'd be unique function names. > > Anyway, tangent over. > > > > > > + is the same in the various languages. > > > > I think "=", ":=", "==" are the main problem. > > You might try a compare and accidentally to an assignment. > > > > > >> The syntax will be strictly C. > > > > Almost the same. > > > > > > > The display of values will be C. > > > > Almost the same. > > On the strength of your comments, I rest my case. > > > > > Also if you have a particularly good C compiler/debugger, we could do > > #define AND && > > #define OR || > > > > > > getting you back those two operators, which I rarely use in a debugger. > > > > > > > TEXT won't work in any reasonable way at all. > > > > Sure it might. > > In Visual Studio you can write little addins to help the debugger display stuff. > > I believe there is a small builtin "language" or I believe you can write actual code. > > In Windbg you can write little plugins. You could provide like !m3.text. > > I don't know if you can tell the debugger ahead of time how to custom display types. > > I don't know if gdb has a story here. > > Still, one might imagine a *small* patch to gdb. > > All of which is just different ways of providing a debugger with proper Modula-3 support. > > > > > > > > Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 > > > type info would be lost, and output formats would lose. > > > > > > Um, you think maybe this stuff was done the wrong way in the first place? > > That the names shouldn't be mangled in the first place? > > I strongly suspect so. Other systems don't depend on this. > > (Yes, I know about C++ name mangling, and even though it does something similar, > > that's a trick for the linker and now how debug information works. It for > > in the absence of debug information, among other reasons.) > > > > I think it could be done a lot better if switching to a better debug info format. > stabs may have been the best option around at the time it was done. And I don't > know if Modula-3's structural type equivalence rules could be supported any better > without the uid's. > > But there will still have to be name mangling to get a standard linker to work, > with just about any language. Stock gdb does what it does in part because it > has builtin demanglers for the various languages it supports. It chooses the > appropriate demangler dynamically. It would be a pretty ugly user interface if > it didn't. > > > There is "naturally" type information you get just by building up decent gcc trees. > > Ditto for intermediate C code. > > For a while you know, every record is a void* or just has a size, and all the type information > > is buried in the names. This is questionable. I'm sure it has some advantages. > > You can describe things maybe not easily described in C. > > e.g. Subranges? > > And then our code in m3gdb is probably very portable, in that, I think, we just ferry along > > some strings, from our code to our code, and we can decipher them the same in all systems. > > I think, I'm not sure, there is like no dependence on the vagaries of coff, dwarf, etc., and > > what they can or cannot represent. However there is a dependency on stabs being available. > > It is not for example available on HP-UX. > > > > > > Furthermore the lack of correct type information, apart from stabs, causes problems. > > For some targets the backend wants accurate type information to pass records by value. > > I again/still think we should probably not rely on the backend for this anyway. > > We should probably make a copy and pass a pointer to it, kind of like m3x86 does. > > > > Certainly, a back end needs type information for code generation. That won't do much to > help a debugger that is oblivious to the source language. > > > > > > Things that use pointers at the machine level can never know whether the pointers > > > point to a single value or an array, and if the latter, with what bounds. > > > > > > C programmers can cope with that. Can't we? > > Look at the security advisories. Buffer overflow, buffer overrun, buffer overflow, ... > over and over. Almost all of them are buffer overruns. But that's a tangent too. > > > And..I admit.. I don't know what our machine level mapping looks like. > > Do we pass a pointer and a size as two parameters? Or a small record with pointer/size by value? > > > > If it's a fixed array, its all in the static type, which the stabs (as extended for Modula-3) > info conveys. If it's an open array, there is runtime dope: a pointer to the zero-th array > element, followed by a shape, which is just a list of words giving the NUMBER of each dimension. > The dimension count is statically known. generally passed by reference, although it is never > altered. For heap-allocated arrays, it's located right in the heap object, at the beginning, > making the pointer redundant. For Formal parameters, if the actual doesn't already have the > needed dope, it is constructed at runtime by code at the call site. This works for, e.g., > passing a fixed array or a SUBARRAY to a formal that is open. > > BTW, this is another thing a debugger has to know about to either pass, display, or alter > open array values. Perhaps Dwarf is sophisticated enough that it could just be encoded in > Dwarf, but certainly not in stabs. (Well, we could probably cobble up yet another stabs > extension, but that would still require specialized debugger support.) > > > > > The debugger need not be a full blown Modula-3 interpreter. > > > > > >> Probably the worst thing will be calls. They just don't work without the debugger > >> having knowledge of a lot of stuff. There are extra hidden parameters, method > >> calls, passing procedure-typed parameters with environments, calling the same, > >> the three modes of Modula-3, etc. I consider calls in debugger commands very > >> valuable. > > > > > > I use calls very rarely. > > I'm not super keen on running some of my code when otherwise my code is all frozen > > and some of it is misbehaving. I know this is partly me. > > > > > > Even so, generally you only call certain functions that put there for use from a debugger, right? > > Like gcc's debug_node or such? > > And they tend to not be fancy? > > I regularly type a debugger call to rexecute something that I just stepped over, not knowing whether > the problem I am looking for would occur inside the procedure or not. Reverse debugging in the newest > gdb could provide an alternative, but I am hearing that the necessary recording costs ~ n*10 slowdown. > > I also do it as an easy way to test some parameter combination. Kind of like having an interpreter for > the language. And I do it with fancy procedures that format some elaborate data structure in a readable, > high-level way, which is, I think, what you meant. Sometimes a *lot* of effort. > > > > > > And the extra parameters..debugger would complain about missing them, programmer would figure it out? > > Before I got call support working, I found there were many calls I could not make work at all. Either > I couldn't figure out what was needed (This amounts, in part, to manually reading stabs), or there > was no way to supply what was needed in a debugger command. Also, on method calls, there was no way > to figure out where it would dispatch to, even when you could locate all the possible overrides in all > the subtypes, in all the source files of the closure. Language-specific support can take care of this, > when done completely. m3gdb is a long way from there now, but it helps a lot. > > > > > > > I'm not saying there aren't drawbacks here. > > But there are also major advantages. > > There are major costs and drawbacks to our current approach. > > We have a ton of extra code. > > Which I don't think we are well equipped for. > > Maybe Tony is. Maybe someone else is. I'm not. > > > > > > Partly, I'll admit, anything I write, I am much more able to maintain. > > Or, another lazy angle, anything smaller is easier to maintain. > > > > > > In gcc we have a large code base. It takes me a long time to get just slightly up to speed on it. > > We have several nagging problems with it. Maybe I just need to look at the C front end more. > > Or read tree.h. I don't know. > > > > > > 4.5.1 doesn't work with SPARC32_SOLARIS/SOLgnu/SOLsun. > > 4.3.5 maybe not either. > > A few optimizations I have turned off for 4.5.1 because they cause problems. Including inlining. > > Maybe I just need to debug more. > > Apple and OpenBSD each maintain their own forks. So that, *sort of but not really*, triples things. > > (now, they are all highly related, so it doesn't) So far we don't have the OpenBSD fork. > > But for example 4.5.1 doesn't have the OpenBSD/powerpc stuff quite. And there is a small OpenBSD/mips64 > > problem I worked around. Minor, I guess. We could just drop these platforms, or OpenBSD entirely. > > Not a huge deal. But it is yet more stuff that C as an intermediate platform solves. > > Exception handling stinks on all platforms but SOLsun/SOLgnu. > > The ALPHA_OSF code no longer works. I tried. > > Generating C/C++ would significantly improve exception handling nearly across the board. > > It is possible otherwise, but much more difficult. > > > > > > So, again, C as intermediate code isn't perfect or without drawbacks, but it promises: > > greatly increased portability > > more efficient exception handling > > better codegen by letting the optimizer be full on, even acrosss modules with some C compilers (gcc 4.5, Visual C++, at least) > > better debugging with stock debuggers (including Visual C++, windbg) > > a portable distribution format -- no more having to distribute binaries, though they still have advantages > > easier to get into the various "ports" systems I think as a result > > a much smaller system overall (no GPL, if it matters) > > > > > > Again, there are drawbacks, but it just seems so very tempting. > > > > > > I'm sure I'll plug away at m3cc a while longer, but I think more and more it is questionable. > > > > > > I can try again to read the LLVM stuff. > > > > > > A new backend I think is unavoidably a lot of work, be it C or LLVM. > > That's my hangup on both of these. It requires knowing a lot about two big things -- M3CG and the underlying generator. > > parse.c is "only" 6,000 lines but pretty dense in terms of information gone into it. Maybe I'm just feeling dumb. > > > > > > The thing about C though, is it is a very well understood next layer down. Certainly compared to > > the gcc trees or LLVM. I don't think it is just me, that I'm some C expert. > > > > > > > >> This could probably be improved a lot by switching to a better debug info format, > >> probably the latest Dwarf variant. But that is a big job. > > > > > > I don't believe we have to do *anything* sort of to switch debug formats. > > We just have to provide gcc with decently formed typeful trees. > > It should do the rest. > > Currently I guess it is all custom. > > It doesn't provide nearly enough information in stock form. The "stabs" it now produces has a lot > of Modula-3-specific stuff crammed inside the fields of stabs entries. This had be be added by the > original implementors of the gcc backend. A different debug format will need changes to gcc to > emit what is needed. However, it might well be entirely within the "llanguage" of, say Dwarf, which > is very general. It certainly would be a lot cleaner, and it could easily be completed in places > that are now hard. So there would still be a lot of work. > > I don't completely understand where the current back end emits all the stabs stuff, but I believe > all or almost all of it comes through code in parse.c calling utility code (dbxout.c, e.g.), and > is not much taken from the trees gcc uses. This is why I have yet to figure out how to write > correct debug info describing the locations of static links, since gcc develops this information > by transforming trees, after parse.c has done its thing. > > > > > I tried -g again, thinking maybe things were better now. It still crashes. > > It seems related to the fact that _m3_fault is in an unknown location. > > But that seems actually deliberate and reasonable, and I tried fiddling with it anyway. > > No luck yet. > > > > > > This debug format problem is also solved by using C intermediate code. > > You just use -g or -gdb or -Zi or whatever, whatever is normal for C, and it'd just work. > > > > Lots of things, TEXT being probably the worst, won't display in a Modula-3 form this way. > And things in expressions/statements won't work either. A debugger user will have to understand > a lot of low-level stuff about how the C back end translates Modula-3 code to C, to use it at all, > and it will still be far less convenient. > > > > > Anyway.. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvfranz at gmail.com Sun Aug 29 05:40:12 2010 From: mvfranz at gmail.com (Michael Franz) Date: Sat, 28 Aug 2010 23:40:12 -0400 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system In-Reply-To: <4C79A389.1070202@lcwb.coop> References: <4C79A11D.8010008@lcwb.coop> <4C79A389.1070202@lcwb.coop> Message-ID: I did manage to find a version of SRC-69, but it is as you pointed out the Trestle Tutorial. I have found reference to Performance analysis of a multiprocessor window system, but not the actual report. Either the citation is wrong or SRC numbers there reports from 1 every year. The report I am looking for is from 1991, but the tutorial is from 1992. When I get to the shared mutex and have issues I will contact you, for now, I am just reading for an overview. Thank you On Sat, Aug 28, 2010 at 8:02 PM, Rodney M. Bates wrote: > > > Rodney M. Bates wrote: > >> Inside the cm3 CVS release branch (cm3-58--release) (and no doubt the head >> too), >> is file doc/src_reports/src-069.pdf. When I open it, its title page has >> report >> number 69 and title "Trestle Tutorial", which agrees with its contents. >> It is hard to image SRC would have ambiguously numbered reports. >> The report number must be a mistake in the citation. >> >> I have a printed copy of SRC 135a, with a listing in the back of the >> reports >> through 133b, with no mention of that title. >> >> Not much help, but it might help structure searches more effectively. >> >> I think copies of a lot of the SRC stuff are still online somewhere, but I >> don't remember where. Perhaps an HP site? >> > > P.S.: http://www.hpl.hp.com/techreports/Compaq-DEC/ has them. But not > that title. > > P.P.S. If you are seriously reading either the Trestle tutorial or > reference manual are puzzled the concept of a "share of a mutex", > I can help, if I can remember it. It took me years to figure out > what it meant. > > > >> Michael Franz wrote: >> >>> Hi, >>> >>> I have been reading Systems Programming with Modula-3, edited by Greg >>> Nelson. The chapter on Trestle refers to SRC Report 69 - Performance >>> analysis of a multiprocessor window system. I have some link on the web, >>> but they are all broken. The one that did work I cannot display. Does >>> anyone know where I can get the pdf version? >>> >>> Thank you >>> >>> Michael >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 29 09:35:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 07:35:24 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: , , Message-ID: I've been quite banging my head against this. I believe basically every type referenced in a module must be "described" to the backend, such as with declare_opaque, declare_record, etc. Type.Compile should call t.compile on more stuff. You need not declare everything in every imported module. Only types that are used. There is at least one hard to solve problem here, for some level of lack of understanding at least. Specifically if you call t.compile on all types in Type.Compile, RecordType.Compiler => Scope.InitValues ?=> assertion failures about non-empty stack. It seems Type.Compile gets called "in the middle of stuff" instead of just from CompileAll. I'm almost stumped. I have to check still where Type.Compile vs. Type.CompileAll are called. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] importing types not described to backend > Date: Sat, 28 Aug 2010 09:54:54 +0000 > > > Interesting. > > TYPE Color1 = RECORD a,b,c: REAL; END; > TYPE Color2 = RECORD a,b,c: REAL; END; > > Have the same id. > If the module defining them also imports an interface with a type with the same id, > or I think, if its interface defines a type with same id (same thing I think, > no relationship at the cg level between a module and its interface), > then the declare_records are skipped. > > The fix is probably something simple in Type.Compile involve the order it checks the tables in > when deciding to call t.compile or not. > > Or can it just always call t.compile? > Worst thing is that extra type information created? > A lot of it? (all types in all imports, instead of just the used ones??) > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: RE: [M3devel] importing types not described to backend > > Date: Fri, 27 Aug 2010 18:35:00 +0000 > > > > > > Very wierd: > > > > MODULE Main; > > IMPORT Color; > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > BEGIN > > END F1; > > > > BEGIN > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > END Main. > > > > > > This fails. If you remove the IMPORT, it worked. > > The declare_record of ColorT comes and goes with that change. > > So I guess the error really is in F1. > > > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Date: Fri, 27 Aug 2010 18:28:47 +0000 > > > Subject: [M3devel] importing types not described to backend > > > > > > > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > > > > > INTERFACE Color; > > > TYPE T = RECORD a,b,c:REAL; END; > > > END Color. > > > > > > > > > MODULE Main; > > > IMPORT Color; > > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > > BEGIN > > > END F1; > > > > > > > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > > > BEGIN > > > END F2; > > > > > > > > > BEGIN > > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > > > END Main. > > > > > > > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > > > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > > > ../Main.m3: In function 'Main__F1': > > > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > > > > > > > I fixed it so F1 is ok. > > > But still F2 isn't. > > > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > > > > > > > The problem as I understand is we don't tell the backend about imported types. > > > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > > > > > > > I intend to fix this if I don't here any objections. > > > I'm hoping it isn't too much work. > > > I believe it will mostly/all be in m3front. > > > > > > > > > My opinion of our gcc backend drops.. > > > > > > > > > Perhaps the time is better used on a C front end. > > > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > > > > > > > Thanks, > > > - Jay > > > > > > From jay.krell at cornell.edu Sun Aug 29 09:52:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 07:52:23 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: , , , , , Message-ID: Arg. Another problem I see in some attempted fixes is: opaque type defined twice: _t9a0e5dbc ? defined in? FileWr.i3 ? and also??? System.m3 ? I don't need to reveal opaque types repeatedly but I do need to declare them repeatedly -- so that backend knows they are pointers.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 29 Aug 2010 07:35:24 +0000 > Subject: Re: [M3devel] importing types not described to backend > > > I've been quite banging my head against this. > I believe basically every type referenced in a module must be > "described" to the backend, such as with declare_opaque, declare_record, etc. > > Type.Compile should call t.compile on more stuff. > You need not declare everything in every imported module. Only types that are used. > > There is at least one hard to solve problem here, for some level of lack of understanding at least. > Specifically if you call t.compile on all types in Type.Compile, RecordType.Compiler => Scope.InitValues > => assertion failures about non-empty stack. > > It seems Type.Compile gets called "in the middle of stuff" instead of just from CompileAll. > > I'm almost stumped. > I have to check still where Type.Compile vs. Type.CompileAll are called. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: RE: [M3devel] importing types not described to backend > > Date: Sat, 28 Aug 2010 09:54:54 +0000 > > > > > > Interesting. > > > > TYPE Color1 = RECORD a,b,c: REAL; END; > > TYPE Color2 = RECORD a,b,c: REAL; END; > > > > Have the same id. > > If the module defining them also imports an interface with a type with the same id, > > or I think, if its interface defines a type with same id (same thing I think, > > no relationship at the cg level between a module and its interface), > > then the declare_records are skipped. > > > > The fix is probably something simple in Type.Compile involve the order it checks the tables in > > when deciding to call t.compile or not. > > > > Or can it just always call t.compile? > > Worst thing is that extra type information created? > > A lot of it? (all types in all imports, instead of just the used ones??) > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Subject: RE: [M3devel] importing types not described to backend > > > Date: Fri, 27 Aug 2010 18:35:00 +0000 > > > > > > > > > Very wierd: > > > > > > MODULE Main; > > > IMPORT Color; > > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > > BEGIN > > > END F1; > > > > > > BEGIN > > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > > END Main. > > > > > > > > > This fails. If you remove the IMPORT, it worked. > > > The declare_record of ColorT comes and goes with that change. > > > So I guess the error really is in F1. > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > > > From: jay.krell at cornell.edu > > > > To: m3devel at elegosoft.com > > > > Date: Fri, 27 Aug 2010 18:28:47 +0000 > > > > Subject: [M3devel] importing types not described to backend > > > > > > > > > > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > > > > > > > INTERFACE Color; > > > > TYPE T = RECORD a,b,c:REAL; END; > > > > END Color. > > > > > > > > > > > > MODULE Main; > > > > IMPORT Color; > > > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > > > BEGIN > > > > END F1; > > > > > > > > > > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > > > > BEGIN > > > > END F2; > > > > > > > > > > > > BEGIN > > > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > > > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > > > > END Main. > > > > > > > > > > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > > > > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > > > > ../Main.m3: In function 'Main__F1': > > > > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > > > > > > > > > > I fixed it so F1 is ok. > > > > But still F2 isn't. > > > > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > > > > > > > > > > The problem as I understand is we don't tell the backend about imported types. > > > > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > > > > > > > > > > I intend to fix this if I don't here any objections. > > > > I'm hoping it isn't too much work. > > > > I believe it will mostly/all be in m3front. > > > > > > > > > > > > My opinion of our gcc backend drops.. > > > > > > > > > > > > Perhaps the time is better used on a C front end. > > > > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > > > > > > > > > > Thanks, > > > > - Jay > > > > > > > > > > From jay.krell at cornell.edu Sun Aug 29 11:54:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 09:54:16 +0000 Subject: [M3devel] representation of opaque types? Message-ID: Are values of opaque types always pointers? Is that something that might change/improve? This for purposes of fixing the type information in the gcc backend. The backend really would like accurate type information. For purposes of passing records by value, and for debugging, at least. ?? Unless we would/should/could/will just deoptimize passing records by value, which would cover up this headache. I'll poke around more.. http://www.cs.tut.fi/lintula/manual/modula3/m3defn/html/opaques.html TYPE T <: U where T is an identifier and U an expression denoting a reference type. It introduces the name T as an opaque type and reveals that U is a supertype of T. The concrete type of T must be revealed elsewhere in the program. That clears it up -- U is a reference type. Seems like it might be nice if the "linker" could optimize and teach clients of opaque types their sizes and allow them to be stack-allocated. What does it mean when the front end says "new opaque info, recompiling"? I'll poke around.. ?- Jay From wagner at elegosoft.com Sun Aug 29 12:45:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 12:45:13 +0200 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, ,,, , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , , , <4C77D7D3.6070602@lcwb.coop>, , <4C796036.1000806@lcwb.coop> Message-ID: <20100829124513.otk0e8am8ww00gw8@mail.elegosoft.com> Quoting Jay K : > Ps we don't even have m3gdb for all systems e.g. Darwin, and the > Windows debuggers are much better than anything I've seen on Unix. > On these systems intermediate C would improve debugging much. Though > Darwin gdb I've also been improving. > > Also you seem to confuse C name mangling with what Modula-3 does. > They are quite different. C only mangles things with linkage, for > linking reasons, not for debugging information. Locals, parameters, > record fields: no mangling. C code analogous to what Modula-3 > allows would survive with everything being extern C, no name mangling. > > In both cases as I understand, an effective hack to tunnel > information through systems not quite designed/extended to suit. > > What we have is flawed. What I favor is flawed. But differently. We don't need to give up what we have in order to try something else additionally, do we? I think m3gdb works quite well on some platforms these days. Unfortunately, it doesn't build on others. On Windows we'll need something for the native debuggers anyway. Improving the use of other C debuggers will be good, too, for platforms we haven't got anything else. What I've learned from this discussion is that we should definitely try to support dwarf debugging format for the gcc backend. I'll add that as a task for the 5.9 release. And Jay has already announced that he will be working on a C backend. That should open up other possibilities. 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 Sun Aug 29 13:15:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 13:15:44 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org> References: <20100827173502.GA8777@topoi.pooq.com>, , <20100827180902.GA8903@topoi.pooq.com>, , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , <20100827193836.GC8903@topoi.pooq.com>, , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, <1282983172.2770.71.camel@boromir.m3w.org> <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org> Message-ID: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Quoting Darko : > I sort of meant software support. But isn't this all academic since > Elego is a CVS shop and they host the project? No. Elego is no CVS shop. We're not a shop at all in the sense that you can buy anything from our shelves. We help other companies improve their development processes wrt. software configuration management. Actually, almost all our work in the recent 2 yours has been Subversion-related. For more information of what we do, have a look at our web pages at http://www.elegosoft.com/. We used CVS for M3 at the start because it was the only reasonable possibility several years ago. I always opposed a switch of the system because it will bind a lot of resources we could use better, e.g. for improving the debugging support, IPv6 support, writing a C backend, etc. And we don't really need more than CVS offers. I still doubt that somebody will do all the work to set up a new version control infrastructure with easy migration, Hudson and trac integration, etc. If anybody sets up something that works better than what we have, we will of course use it. Elego will continue to provide some resources for the M3 project in form of CPU time, disk space and administration support if the community wants that. And we'll provide git or mercurial or svn access for M3 if it is needed. Actually, svn should be rather easy. We currently have some overload problems with the server that hosts CVS and the M3 continuous integration, which led me to reduce the number of checkouts and builds. This will be sorted out during the fall. Unfortunately, we don't have hard data about i/o needs of other systems compared to CVS yet (but we'll get them). BTW, CI is working quite well now, and produces nightly snapshots that can be downloaded for almost all supported platforms, so this is better than ever before. See http://hudson.modula3.com:8080/view/cm3-current/ for details. 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 Sun Aug 29 14:02:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 12:02:01 +0000 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: ?> We're not a shop at all in the sense that you can buy anything from our shelves "Shop" has a different meaning in this context. English is wierd. Roughly speaking "an X shop" is a "company that tends to use product X or products from company X, not necessarily to the exclusion of others" "a Microsoft shop" "a Java shop" "a Unix shop" "an Oracle shop" "a .NET shop" ?> And we don't really need more than CVS offers. ? A few things bug me. The number one is that there are no change lists, just multiple independent changes to independent files. I want to be able to browse history as a list of changes, and click on them, not navigate to each file individually. I would also like a system that keeps enough local state so that I can diff my local version against current without going to the slow unreliable network. The network is indeed very slow and unreliable. Perforce seems ideal in so many ways. Its command line interface is excellent. Its gui is very good. Its feature set is excellent. Its branching support is excellent. I don't know if it has good offline support though. I think I would settle for SVN. Though SVN has completely broken branching last I checked, and they acknowledged it. SVN also has relatively large dependencies to build from source. I would also like a system that doesn't drop files/directories all over the place. Just in the root of a checkout should suffice and be ideal. CVS is awful here and I believe SVN is too. Perforce maybe doesn't have the portability I'd like -- e.g. I don't see OpenBSD. But that might be an ok compromise, if copying can be done, or if those platforms can be requested. It seems they are extremely extremely portable but just don't bother to provide the binaries. Through time they do have excellent platform coverage. I'm sure we don't go for this, but I do recommend it wholeheartedly. I want a system that makes me do *something* before editing a file. ? Run some command to acknowledge I'm editing it, so it can keep track. I want a systerm with a command to undo the edits. With CVS I delete and update. Lame. I want a system that quickly knows which files I have changed. Perforce meets all these requirements. When I'm lazy I do: ? p4 edit ... ? spend a while editing ? p4 revert -a? to revert anything I didn't actually change ? It is wasteful, but plenty fast. I'd prefer a system that knows how to use windiff or some other decent gui to show diffs. I've gradually become comfortable with textual diffs. But I like gui diffs. Windiff is nice. Some people think it is old and limited, but it is much better than textual diffs. CVS handling of merges and conflicts is also very poor. ?- Jay ---------------------------------------- > Date: Sun, 29 Aug 2010 13:15:44 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system > > Quoting Darko : > > > I sort of meant software support. But isn't this all academic since > > Elego is a CVS shop and they host the project? > > No. Elego is no CVS shop. We're not a shop at all in the sense > that you can buy anything from our shelves. We help other companies > improve their development processes wrt. software configuration > management. Actually, almost all our work in the recent 2 yours > has been Subversion-related. For more information of what we do, > have a look at our web pages at http://www.elegosoft.com/. > > We used CVS for M3 at the start because it was the only reasonable > possibility several years ago. > > I always opposed a switch of the system because it will bind a lot > of resources we could use better, e.g. for improving the debugging > support, IPv6 support, writing a C backend, etc. And we don't > really need more than CVS offers. > > I still doubt that somebody will do all the work to set up a new > version control infrastructure with easy migration, Hudson and trac > integration, etc. If anybody sets up something that works better > than what we have, we will of course use it. > > Elego will continue to provide some resources for the M3 project > in form of CPU time, disk space and administration support if the > community wants that. And we'll provide git or mercurial or svn > access for M3 if it is needed. Actually, svn should be rather easy. > > We currently have some overload problems with the server that hosts > CVS and the M3 continuous integration, which led me to reduce the > number of checkouts and builds. This will be sorted out during > the fall. Unfortunately, we don't have hard data about i/o needs > of other systems compared to CVS yet (but we'll get them). > > BTW, CI is working quite well now, and produces nightly snapshots > that can be downloaded for almost all supported platforms, so this > is better than ever before. See > > http://hudson.modula3.com:8080/view/cm3-current/ > > for details. > > 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 Sun Aug 29 14:25:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 12:25:33 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <20100829124513.otk0e8am8ww00gw8@mail.elegosoft.com> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , , , , , ,,<20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, ,,, , , <4C77D7D3.6070602@lcwb.coop>, , , , <4C796036.1000806@lcwb.coop>, , <20100829124513.otk0e8am8ww00gw8@mail.elegosoft.com> Message-ID: > What I've learned from this discussion is that we should definitely try > to support dwarf debugging format for the gcc backend. I'll add that > as a task for the 5.9 release. I am not certain this makes any sense at all. I'm not sure. I don't think it is the job of a gcc front end (as Modula-3 is structured) to do anything for debugging, to know about debug formats, *except* to provide type-ful trees to the backend, which they should do anyway, except which Modula-3 historically doesn't do much. It is the job of the gcc backend -- below parse.c -- to generate debugging information. I think what Modula-3 currently does is "tunnel" a bunch of private data through to m3gdb. I think "stabs" might help associate the data with the code. Again, I don't know. And I think the trees are slightly well formed such that gcc can generate line numbers and knows a little bit about locals -- it shows pretty much everything as? void*. This is getting better lately though. I'm not doing anything specific to debugging or stabs or dwarf or something. I'm just filling in the types in the trees. There was already some code. I couldn't have figured this out so fast otherwise. We were already building struct types. But we weren't associating them with locals/parameters. What got me started down this area is actually that gcc cannot generate SPARC64_SOLARIS code that passes records by value without type information for the records. As well, if you only provide information to the caller or callee but not both, then AMD64_DARWIN and possibly others generate incorrect code. Then I realized what I had actually discovered is how to get stock gdb to work significantly better. What the code should have been doing all along. I suppose we could tunnel the private data through dwarf, but I don't think it would provide much gain. Mainly that HP-UX might stand a chance of working with a debugger. Might. Given the "data intensity" of the many debugging tasks, sprinking in RTIO calls is actually often much more effective than any debugger could be. You know, the code I want to debug gets hit many many times and I don't want to debug it until a certain late point. Getting there in a debugger is too difficult. Though easier if there is a way to get the debugger to stop, like by putting int 3 in x86 code. Win32 has the portable (to Win32 architectures) DebugBreak() call. Macintosh has similar. Too bad I haven't seen anything like this in Posix. Posix is generally very small and limiting.. ?- Jay ---------------------------------------- > Date: Sun, 29 Aug 2010 12:45:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? > > Quoting Jay K : > > > Ps we don't even have m3gdb for all systems e.g. Darwin, and the > > Windows debuggers are much better than anything I've seen on Unix. > > On these systems intermediate C would improve debugging much. Though > > Darwin gdb I've also been improving. > > > > Also you seem to confuse C name mangling with what Modula-3 does. > > They are quite different. C only mangles things with linkage, for > > linking reasons, not for debugging information. Locals, parameters, > > record fields: no mangling. C code analogous to what Modula-3 > > allows would survive with everything being extern C, no name mangling. > > > > In both cases as I understand, an effective hack to tunnel > > information through systems not quite designed/extended to suit. > > > > What we have is flawed. What I favor is flawed. But differently. > > We don't need to give up what we have in order to try something else > additionally, do we? > > I think m3gdb works quite well on some platforms these days. Unfortunately, > it doesn't build on others. > > On Windows we'll need something for the native debuggers anyway. > > Improving the use of other C debuggers will be good, too, for platforms > we haven't got anything else. > > What I've learned from this discussion is that we should definitely try > to support dwarf debugging format for the gcc backend. I'll add that > as a task for the 5.9 release. > > And Jay has already announced that he will be working on a C backend. > That should open up other possibilities. > > 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 Sun Aug 29 15:58:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 15:58:21 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> Quoting Jay K : > I think I would settle for SVN. > Though SVN has completely broken branching last I checked, and they > acknowledged it. > SVN also has relatively large dependencies to build from source. Branching in SVN is OK, merging is still wanting in case of tree conflicts. > I would also like a system that doesn't drop files/directories all > over the place. Just in the root of a checkout should > suffice and be ideal. CVS is awful here and I believe SVN is too. The working copy overhaul expected to be included in SVN 1.7 will keep all metadata at the root of the checkout in an SQL database. > I want a system that makes me do *something* before editing a file. > ? Run some command to acknowledge I'm editing it, so it can keep track. You can use cvs watch and cvs edit for that. I really wouldn't recommend it though. See also CVSREAD. > I want a systerm with a command to undo the edits. With CVS I delete > and update. Lame. cvs unedit > I'd prefer a system that knows how to use windiff or some other > decent gui to show diffs. tkcvs should work on all platforms. You may want to look at that. It also show graphical development line trees. > I've gradually become comfortable with textual diffs. > But I like gui diffs. Windiff is nice. Some people think it is old > and limited, but it is > much better than textual diffs. > > CVS handling of merges and conflicts is also very poor. Yes. No way to improve that, I'm afraid. 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 Sun Aug 29 17:05:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 17:05:44 +0200 Subject: [M3devel] cm3cg running amok In-Reply-To: <4C7869C8.7050600@lcwb.coop> References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> <4C7869C8.7050600@lcwb.coop> Message-ID: <20100829170544.l9x4yvd5340g0gkg@mail.elegosoft.com> The Hudson job for package tests on AMD64_FREEBSD was actually using a cm3cg binary from 2010-06-04 due to a configuration mistake. It may well be that changes in the interface or tree construction since then caused the problem. Currently the test-all-pkgs job progresses well on my system. Olaf Quoting "Rodney M. Bates" : > The ticked #1147 I reported a couple of weeks ago would probably show > this symptom. > That was AMD64_LINUX. > > Hmm, I think I never got back to supplying the attachment .ms file to > reproduce. > I'll try to do that tomorrow. I need sleep now too. > > Olaf Wagner wrote: >> I was just able to kill this process before my system ran out of swap >> space: >> >> % ps -wwwlp 95345 >> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND >> 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? >> 0:22.91 >> /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ RTHeapDebug.mc -o >> RTHeapDebug.ms >> >> It had already acquired more than 16 GB. >> >> Any ideas? >> >> 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 rcolebur at SCIRES.COM Sun Aug 29 19:19:28 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 29 Aug 2010 13:19:28 -0400 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com>, Message-ID: >I'd prefer a system that knows how to use windiff or some other decent gui to show diffs. >I've gradually become comfortable with textual diffs.> >But I like gui diffs. Windiff is nice. Some people think it is old and limited, but it is >much better than textual diffs. Jay, have you looked into WinMerge on Windows? I use WinMerge and TortoiseCVS with cm3. http://winmerge.org/ http://www.tortoisecvs.org/ Regards, Randy From hendrik at topoi.pooq.com Sun Aug 29 20:40:12 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 29 Aug 2010 14:40:12 -0400 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: <20100829184012.GA17077@topoi.pooq.com> On Sun, Aug 29, 2010 at 12:02:01PM +0000, Jay K wrote: > > ?> We're not a shop at all in the sense that you can buy anything from our shelves > > > "Shop" has a different meaning in this context. > English is wierd. > > > Roughly speaking "an X shop" is a "company that tends to use product X or products from company X, not necessarily to the exclusion of others" > "a Microsoft shop" > "a Java shop" > "a Unix shop" > "an Oracle shop" > "a .NET shop" > > > ?> And we don't really need more than CVS offers. > ? > > A few things bug me. > The number one is that there are no change lists, just multiple independent changes to independent files. monotone does this. > I want to be able to browse history as a list of changes, and click on them, not navigate to each file individually. One of the independent GUIs associated with monotone does this. > I would also like a system that keeps enough local state so that I can diff my local version against current > without going to the slow unreliable network. The network is indeed very slow and unreliable. monotone does this withoug using the unreliable network. > > > Perforce seems ideal in so many ways. Its command line interface is excellent. > Its gui is very good. > Its feature set is excellent. > Its branching support is excellent. > I don't know if it has good offline support though. > > > I think I would settle for SVN. > Though SVN has completely broken branching last I checked, and they acknowledged it. > SVN also has relatively large dependencies to build from source. > > > I would also like a system that doesn't drop files/directories all over the place. Just in the root of a checkout should > suffice and be ideal. CVS is awful here and I believe SVN is too. I don't know what you mean with files/directories all over the place. monotone does allow you to have mutiple workspaces (perhaps you are working on several bugs simultaneousle, on the same of different branches, without having more than one local copy of the entire repository. But I suspect this isn't what you mean with "all over the place". > > > Perforce maybe doesn't have the portability I'd like -- e.g. I don't see OpenBSD. > But that might be an ok compromise, if copying can be done, or if those platforms can be requested. > It seems they are extremely extremely portable but just don't bother to provide the binaries. > Through time they do have excellent platform coverage. > I'm sure we don't go for this, but I do recommend it wholeheartedly. monotone available for * Cygwin * Debian Linux * FreeBSD Ports * Mac OS X MacPorts * NetBSD pkgsrc * openSuSE Linux * Fedora Linux * Gentoo Linux and it's free and open source. So are quite a few other VCS's. We certainly don't want to be in the position the Linux kernel got into with bitkeeper. > I want a system that makes me do *something* before editing a file. > ? Run some command to acknowledge I'm editing it, so it can keep track. monotone can tell you what *has* been edited. Though it doesn't have a specific command that allows editing ... just what do you mean here? What do you really need? > I want a systerm with a command to undo the edits. With CVS I delete and update. Lame. I'm not sure what you mean here. > I want a system that quickly knows which files I have changed. > Perforce meets all these requirements. > > > When I'm lazy I do: > ? p4 edit ... > ? spend a while editing > ? p4 revert -a? to revert anything I didn't actually change > ? It is wasteful, but plenty fast. In monotone, you can just discard the entire workspace, create another. But you can also use the mtn revert ... command, where ... is a list od files and directories you specifically want to revert. There's also a command to remove the last revision you committed to the repository, as long as you haven't sync'd with another copy of the repositiry (in that case it would just com back the next time you sync'd) Is that wnat you want? > > > I'd prefer a system that knows how to use windiff or some other decent gui to show diffs. > I've gradually become comfortable with textual diffs. > But I like gui diffs. Windiff is nice. Some people think it is old and limited, but it is > much better than textual diffs. > > > CVS handling of merges and conflicts is also very poor. > Monotone on my system deals with merge conflicts by using emacs merge mode. Is that what you're talking about? But it's possible to have multiple heads on a branch. But that's not why I use monotone in my own work. I chose it primarily because of its utter paranoia about data loss. It's primarily its internal self-checking that makes it slow to the extent that it still is slow. I like that. For example, it will *not* sync with a damaged repository, thereby limiting contagion. I've heard of occasional problems checing out extremely old versions from CVS. Single-bit errors can have long-lasting consequences. But converting CVS to monotone seems still to be a pain. Monotone's own cvs to monotone conversion campaign failed on my (it turns out incomplete) copy of the Modula 3 repository I made several months ago, failing on some kind of internal consistency check, thereby protecting the monotone repository it was building. I should try it again after I re-cvsup the whole repository. For all I know, it may be a problem with my missing CVSROOT. -- hendrik P.S. I don't know how other version control systems rate on these issues at present. I suspect several would rate as well. Input on this from people with actual experience would be very useful. -- hendrik > > ?- Jay > From hendrik at topoi.pooq.com Sun Aug 29 20:43:28 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 29 Aug 2010 14:43:28 -0400 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> References: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> Message-ID: <20100829184327.GB17077@topoi.pooq.com> On Sun, Aug 29, 2010 at 03:58:21PM +0200, Olaf Wagner wrote: > >> I would also like a system that doesn't drop files/directories all >> over the place. Just in the root of a checkout should >> suffice and be ideal. CVS is awful here and I believe SVN is too. > > The working copy overhaul expected to be included in SVN 1.7 will > keep all metadata at the root of the checkout in an SQL database. There's some mechanism in monotone to handle checkouts from one package in a subdirectory of a checkout of another package, possibly from another repository. I don't kno whow it works. Other than this, all the metadata is indeed kept in the _MTN subdirectory of the root directory of a workspace. -- hendrik From hosking at cs.purdue.edu Mon Aug 30 15:58:36 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Aug 2010 09:58:36 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100830070111.78809247400F@birch.elegosoft.com> Message-ID: <77612C42-A038-4D0D-A47D-F731DB3D825C@cs.purdue.edu> This code using NARROW in RecordType.m3 is unfortunate. Should you not implement the "declare" method for Field.T instead, and then invoke Value.Declare on it? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 30 Aug 2010, at 03:09, Jay K wrote: > > diff attached > > - Jay > > ---------------------------------------- >> Date: Mon, 30 Aug 2010 09:01:11 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/08/30 09:01:11 >> >> Modified files: >> cm3/m3-sys/m3front/src/values/: Field.i3 Field.m3 >> cm3/m3-sys/m3front/src/types/: Type.m3 RecordType.m3 >> cm3/m3-sys/m3front/src/builtinOps/: BitSize.m3 >> >> Log message: >> Pass more type information to backend. Hopefully it will use it. >> >> In particular, if you imported: >> >> TYPE Foo = RECORD a:INTEGER; END: >> >> and you also defined yourself unrelated: >> >> TYPE Bar = RECORD a:INTEGER; END; >> >> then the anonymous "RECORD a:INTEGER END;" >> >> would not be described to the backend. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 30 22:46:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 30 Aug 2010 20:46:00 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <77612C42-A038-4D0D-A47D-F731DB3D825C@cs.purdue.edu> References: <20100830070111.78809247400F@birch.elegosoft.com> , <77612C42-A038-4D0D-A47D-F731DB3D825C@cs.purdue.edu> Message-ID: I'll look into that. My home network is down currently. There's still problems in this area, at least in the backend, probably not in the frontend at this point. - Jay Subject: Re: [M3commit] CVS Update: cm3 From: hosking at cs.purdue.edu Date: Mon, 30 Aug 2010 09:58:36 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu This code using NARROW in RecordType.m3 is unfortunate. Should you not implement the "declare" method for Field.T instead, and then invoke Value.Declare on it? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 30 Aug 2010, at 03:09, Jay K wrote: diff attached - Jay ---------------------------------------- Date: Mon, 30 Aug 2010 09:01:11 +0000 To: m3commit at elegosoft.com From: jkrell at elego.de Subject: [M3commit] CVS Update: cm3 CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/08/30 09:01:11 Modified files: cm3/m3-sys/m3front/src/values/: Field.i3 Field.m3 cm3/m3-sys/m3front/src/types/: Type.m3 RecordType.m3 cm3/m3-sys/m3front/src/builtinOps/: BitSize.m3 Log message: Pass more type information to backend. Hopefully it will use it. In particular, if you imported: TYPE Foo = RECORD a:INTEGER; END: and you also defined yourself unrelated: TYPE Bar = RECORD a:INTEGER; END; then the anonymous "RECORD a:INTEGER END;" would not be described to the backend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 31 13:25:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 11:25:43 +0000 Subject: [M3devel] a trouble with passing records by value.. Message-ID: Given something like this: jbook2:p247 jay$ more 1.c #include typedef struct { long code; long value; } T1; void ActionLookup(T1 t, long code, long value); void ActionLookup(T1 t, long code, long value) { ? assert(t.code == code); ? assert(t.value == value); } int main() { ? T1 t1 = {2,2}; ? ActionLookup(t1, 2, 2); ? return 0; } j on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. Darn. If m3cg were higher level this could be better. There should be a viable compromise where the parameter is passed in registers, and only "homed" to some stack location if its address is used -- e.g. to pass unused parameters in registers. But given the inefficiency of field accesses, I'm not sure it is worth trying? Maybe we should have M3CG include field references? There is this basic problem that the interface between m3front and m3cc isn't really at the right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. ?- Jay From hosking at cs.purdue.edu Tue Aug 31 15:15:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Aug 2010 09:15:32 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: Message-ID: What happens if you take the address of t inside ActionLookup? What happens if you take the address of t1 inside main? On 31 Aug 2010, at 07:25, Jay K wrote: > > Given something like this: > > jbook2:p247 jay$ more 1.c > #include > > typedef struct { long code; long value; } T1; > > void ActionLookup(T1 t, long code, long value); > > void ActionLookup(T1 t, long code, long value) > { > assert(t.code == code); > assert(t.value == value); > } > > int main() > { > T1 t1 = {2,2}; > ActionLookup(t1, 2, 2); > return 0; > } > j > > > on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > > However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > Darn. > > > If m3cg were higher level this could be better. > > > There should be a viable compromise where the parameter is passed in registers, and only "homed" > to some stack location if its address is used -- e.g. to pass unused parameters in registers. > But given the inefficiency of field accesses, I'm not sure it is worth trying? > > > Maybe we should have M3CG include field references? > > > There is this basic problem that the interface between m3front and m3cc isn't really at the > right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > > - Jay > From jay.krell at cornell.edu Sun Aug 1 00:13:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 31 Jul 2010 22:13:58 +0000 Subject: [M3devel] rmrec problems -- delete while enumerating Message-ID: Aha. http://www.cz.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/readdir.c Strongly hints at problems related to deleting and enumerating at the same time. >From that then, I'll make another speculation -- enumeration ends up missing entries. IF IF IF the directory is viewed like an array, and if readdir maintains a position, moving forwad in chunks, and if delete underneath it shifts everything down, then, I think one can see the problem. I'm not sure which of these statements is true though. Certainly deleting while enumerating is not in general obvious how to deal with. Depending on a few factors. In STL documentation, they always mention what iterators are invalidated by deletion. It varies from collection to collection and perhaps other aspects. As to why my "rewrite" isn't working, I don't know, I can't look at until Monday. It looks simple and correct, I tested it some, and should deal with delete-during-enumerate. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Aug 3 01:08:48 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 02 Aug 2010 18:08:48 -0500 Subject: [M3devel] trac ticket 1147, additional info Message-ID: <4C575000.5000208@lcwb.coop> I couldn't find any place to attach these files directly to a ticket. They are definitely relevant. The file Test.mc, needed to rerun the error, is 906386 bytes. Ask if you want it. Note: The same symptom occurs on LINUXLIBC6. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: failurelog URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: backtrace URL: From wagner at elegosoft.com Tue Aug 3 09:05:17 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 03 Aug 2010 09:05:17 +0200 Subject: [M3devel] Fwd: [CM3] #1147: Runaway recursion in m3cc. Message-ID: <20100803090517.km5chcezw40cskw4@mail.elegosoft.com> FYI ----- Forwarded message from bugs at elego.de ----- Date: Mon, 02 Aug 2010 22:59:36 -0000 From: CM3 Reply-To: CM3 Subject: [CM3] #1147: Runaway recursion in m3cc. To: rodney.m.bates at acm.org, wagner at elego.de #1147: Runaway recursion in m3cc. -------------------------------------+-------------------------------------- Reporter: rodney.m.bates@? | Owner: wagner Type: sw-bug | Status: new Priority: medium | Milestone: CM3 Release 5.9 Component: sys | Version: 5.8-RC3 Severity: serious | Keywords: m3cc, recursion Relnote: | Confidential: no Org: | Estimatedhours: 0 Hours: 0 | Billable: 0 Totalhours: 0 | Internal: 0 -------------------------------------+-------------------------------------- Htr: run command: /usr/local/cm3//bin/cm3cg -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks Test.mc -o Test.ms with file Test.ms present. This file to be supplied. Fix: Env: m3cc from branch cm3-5-8-release, up to date as of 2010-8-1, except for using dbxout.c 1.8, instead of 1.9, which is almost certainly irrelevant -------------------------------------+-------------------------------------- m3cc crashes after runaway recursion in gcc's garbage collector, collecting nodes apparently created in parse.c. There is a linear list of 261924 nodes of kind TS_FIELD_DECL, linked on the 'chain' field. This is rooted in field 'chain' of a TS_FUNCTION_DECL node. These are node types created from parse.c. -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 3 11:36:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Aug 2010 09:36:53 +0000 Subject: [M3devel] rmrec problems Message-ID: There seems to another final problem, or maybe this was the problem all along, or maybe maybe I introduced this with the previous fix (*) stat on a symlink whose target has been deleted, apparently fails. e.g. m3cc/target/gmp/.libs/libgmp.la -> ../libgmp.la *: maybe I introduced it: Well, before it might have been sensitive to directory enumeration order. My change deletes files and then subdirectories, making it no longer sensitive that way. Fix will be to use lstat I believe. And I'll just report symlinks to be regular files. And opening them can fail with file not found... which I'm sure will break something somewhere -- enumerated files no longer necessarily exist... Probably no win. Probably the original interfaces didn't consider symlinks, since they aren't portable. Yet without considering them, and composing rmrec on lower level suppostedly portable interfaces..you can't ignore them. Can't win. ?- Jay From jay.krell at cornell.edu Tue Aug 3 11:50:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Aug 2010 09:50:32 +0000 Subject: [M3devel] m3 mailing lists? Message-ID: Are m3commit or m3devel working? I know there was scheduled maintenance but I figured that'd be under a day. ?- Jay From jay.krell at cornell.edu Wed Aug 4 05:53:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 03:53:47 +0000 Subject: [M3devel] m3override In-Reply-To: <20100730215051.GA23133@topoi.pooq.com> References: , , <20100730215051.GA23133@topoi.pooq.com> Message-ID: > I remember using an override somewhere ... but I don't remember where or > why now. So..it sounds like maybe you don't know what overrides are. That is ok. But you can't then reason about changes to them. Including claiming that all changes are scary or bad. Not that you did, but many people are prone to that way of thinking. > But I'd worry if this change broke something. Sure. You should sorry about anything that breaks anything. But this doesn't break anything. And, if it did, you'd have to apply context-sensitive heuristics. Does it break anything that matters? Matters much? What is the cost of maintaining the code to preserve "everything" "working"? Were the definitions of "working" correct in the first place? Does widespread expectation make something correct? Realize that for nearly any given change, I can tell you something that it breaks. rmrec wasn't working. But I could easily theorize code that depended on it not working. It not working was a way to detect certain characteristics of the filesystem -- presence of symlinks, possible behaviors of readdir+unlink. LONGINT didn't exist, in the base language. But I was using LONGINT as a type already, TYPE LONGINT = ARRAY [0..1] OF INTEGER. (No, I wasn't actually.) Putting it in the language broke such code. Time passing breaks code. Seriously. (Year2000, Year2038). But you can't really stop it. Except by changing the time on your computer to be wrong. In either case, I put the useless warning back and changed our master m3override to ignore it. That is *not* evidence of the utility of the warning, that it made me change code to ignore. There is not actual improvement to the code by avoiding the warning. To understand this stuff, it helps to consider make and make install and chroot. Can I run stuff I haven't run "make install" on? Sometimes. Can I build my own libc.so without chroot? Sometimes. Modula-3 merely reinveints those sorts of things itself. Those things are flawed and Modula-3 fixes some but not all of the flaws. while still leaving major problems present. It is this consistent not fixing all the problems that makes me consider it not worth being so different.. Ultimately chroot is the heavyweight reliable solution. And/or strictly building things -- everything -- from the bottom of the dependency tree and up. In the Modula-3 build system, there is a "package store". e.g. /usr/local/cm3/pkg. That contains packages, e.g. /usr/local/cm3/pkg/m3core. When you say "import(m3core)", it has to find m3core somewhere. The default is package store + package name -- e.g. /usr/local/cm3/pkg/m3core. If you are building package foo, let's say at /usr/src/foo, and you want it to use some custom m3core, which is at /usr/src/m3core then you create /usr/src/foo/src/m3overrides that says override("m3core", "/usr/src") something like that. This is deceptive though. You sort of can't actually do this. Not so easily. You can only really do it if everything in the dependency tree between foo and m3core were also built using the same overrides. You need consistent definitions of types, interfaces, etc. But granted, if you only changed implementation, you can maybe do it. Of course, static linking interferes as well. Are you using stubgen? Should it pickup the new m3core? Then you have to build it too. Which is to say, you can really only use entire alterate package stores. You can't really pick and choice packages from one place or another. Unless you are very careful. And none of our codebases are particularly large anyway. You might as well just make whatever source changes in any package and build it all to alternative package store. Even relying on good albeit buggy incrementality in cm3. Another way to view this, the way we use it in Hudson et. al. is that there are precisely two package stores. /usr/local/cm3/pkg and the "uninstalled" or "unshipped" /usr/cvs/cm3/m3-libs/m3core, /usr/cvs/cm3/m3-sys/m3quake etc. The m3overrides file points into the CVS checkout, which, regrettably, also contains all of our outputs. (see also: "read only source tree", which we sort of have, sort of are/were ahead of everyone else, but not really..) cm3 -x uses the m3overrides files. Cm3 without -x does not. And we use it as I described -- not to pick and chose packages from one place or another. But to pick and chose all packages from one overall tree or another. And then you run into the potential problem that the two directories have a different layout. So stuff like rpath $ORIGIN/../lib doesn't work. Ultimately, often people want binaries to work without running make install. And they often do. Ultimately chroot is how you really build custom stuff. But it seems onerous. I have almost never done it. We can cheat, because we don't build ld.so, libc.so. We only need "chroot" from a certain point and on up. I suggest instead of overrides, instead: 1) have the "intermediate" (not installed) files go into a layout like the current install, not next to the source as currently This is the .a/.so/.exe files, not the .o/.obj/.mo/.io files. .o/.obj/.mo/.io belong somewhere else. 2) "install" is merely deleting one root and copying or renaming the other over it 3) no more notion of overrides If you don't want to build "everything", you can instead copy or hardlink-tree the original. (symlinks won't do, not used with $ORIGIN; though maybe we should abandon $ORIGIN? So many systems don't support it, it turns out). There are tradeoffs either way. In this scheme, rpath $ORIGIN/../lib works without install. You would no longer have executables in the package store, only in cm3root/bin. We could stop statically linking anything. However you do lose "hierarchical naming". Well, maybe. Maybe executables in the package store would use rpath $ORIGIN/../../lib. Heck, maybe the model is everything is in the package store and bin and lib only contain symlinks? (the warning still hasn't been explained, or maybe I'm behind on email) - Jay > Date: Fri, 30 Jul 2010 17:50:51 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > On Fri, Jul 30, 2010 at 01:58:45AM +0000, Jay K wrote: > > > > Randy, Without reading the code, what does it mean? > > > > My first guess was I believe wrong and based on reading the code I think it is even more pointless than I previously thought. > > > > It gets printed *all the time*, when using overrides. Look at any of the Hudson logs. > > > > It wouldn't be printed so much in the older way of doing things, where overrides were applied haphazardly and incompletely. Now that they are used fairly consistently/correctly, it always triggers. I hope to eventually replace the overrides mechanism -- if we just put files into a designated root directory, with the same structure as "the install", then "override" is just setting that directory, optionally prepopulating with an entire copy of the current install -- depending on if you want to build up from scratch or selectively override. You could use hardlinks to speed it up, as long as our copy is delete + copy and not just copy (sometimes a copy will share with the original link(s), sometimes it will unshare, depending on the open flags (I think) or if you first delete). And "install" becomes just moving the install root, if the new one is complete. > > I remember using an override somewhere ... but I don't remember where or > why now. But I'd worry if this change broke something. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Aug 4 08:21:54 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 08:21:54 +0200 Subject: [M3devel] trac ticket 1147, additional info In-Reply-To: <4C575000.5000208@lcwb.coop> References: <4C575000.5000208@lcwb.coop> Message-ID: <20100804082154.isv1z0fvwoow084o@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I couldn't find any place to attach these files directly to a ticket. They > are definitely relevant. The file Test.mc, needed to rerun the error, is > 906386 bytes. Ask if you want it. Are you logged in? Probably trac doesn't allow attachments to anonymous tickets. What about this link: https://projects.elego.de/cm3/attachment/ticket/1147/?action=new ? Hope this helps, 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 Wed Aug 4 08:49:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 08:49:30 +0200 Subject: [M3devel] m3override In-Reply-To: References: , , <20100730215051.GA23133@topoi.pooq.com> Message-ID: <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com> I wouldn't worry much about the warning Jay removed. It only said that an override wasn't used, which is the default behaviour of cm3 (without -x or -override option). One could argue that if one wanted this warning, one should use an option like -warn=overrides or -warn=all (which don't actually exist (yet)). However, I'd still like others to think about the two perspectives one can take here, and what should be the direction we are tweaking our build system. Traditionally, the focus was on the package view, i.e. the view of one developer, and not a whole system. The builder was designed to work well in this setup (more or less). For one notable exception, which others have noticed (who were involved with the original design): linking has never been tried implement portably in a general way. With this focus, overrides are the sole responsibility of the developer, and one could argue that he should know exactly what he does if he uses them. In the CM3 distribution, I used the override feature to allow building the whole set of package in the workspace, which can be seen equivalent to use a completely different package pool. The scripts (which originally were only meant as a tool for the distribution maintainer) distinguish between build(local) and buildglobal (or buildship). In the first case, the global package store isn't involved at all. Jay has suggested to optimize towards building the whole distribution, but I'm not sure yet if that's the correct direction. Obviously, we need to support both perspectives. Much of the charm of the M3 build system for large projects is based on the way the work of the single developers can be split up and isolated. And in large projects there are of course more developers than build or release engineers. But then, there seems to have been no real use of CM3 for this kind of development for many years; most (all?) active users seem to work on their projects alone. So perhaps Jay is right after all? 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 Wed Aug 4 11:21:57 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 11:21:57 +0200 Subject: [M3devel] rmrec problems In-Reply-To: References: Message-ID: <20100804112157.d3anktcy5ck40gso@mail.elegosoft.com> Quoting Jay K : > There seems to another final problem, or maybe this was the problem > all along, or maybe maybe I introduced this with the previous fix (*) > stat on a symlink whose target has been deleted, apparently fails. > e.g. m3cc/target/gmp/.libs/libgmp.la -> ../libgmp.la > > *: maybe I introduced it: Well, before it might have been sensitive > to directory enumeration order. > My change deletes files and then subdirectories, making it no longer > sensitive that way. > > Fix will be to use lstat I believe. > > And I'll just report symlinks to be regular files. Treating symbolic links as files for the simple needs of the FSUtils module sounds OK, but the rm should of course only remove the link. I assume that's what you've done though, as removing the real file would require computing the real path. > And opening them can fail with file not found... which I'm sure will > break something somewhere -- enumerated files no longer necessarily > exist... Sounds OK, too. > Probably no win. > > Probably the original interfaces didn't consider symlinks, since > they aren't portable. > Yet without considering them, and composing rmrec on lower level > suppostedly portable interfaces..you can't ignore them. > Can't win. Yes, the old interface are portable, but not really sufficient for more sophisticated file systems which are more or less standard these days. Perhaps a careful review/redesign of this area would be a good idea, too. 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 Wed Aug 4 12:42:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 10:42:42 +0000 Subject: [M3devel] rmrec problems In-Reply-To: <20100804112157.d3anktcy5ck40gso@mail.elegosoft.com> References: , <20100804112157.d3anktcy5ck40gso@mail.elegosoft.com> Message-ID: > Treating symbolic links as files for the simple needs of the FSUtils > module sounds OK, but the rm should of course only remove the link. Right: my understanding and intent is that just the link, not the link target, is deleted. I can't guarantee at this point, but that was my understanding and intent. There was already *some* existing behavior. If you just delete the link, it'd do something. What didn't work is enumerating/stat'ing a link whose target doesn't exist, en route to deleting the link. (In our actual use, we do delete the target, because what we are enumerating and deleting both of the link and its target.) > for more sophisticated file systems which are more or less standard > these days. Perhaps a careful review/redesign of this area would be > a good idea, too. Even if they aren't "standard" -- even if not every host has them -- certainly many hosts do. I have done so much programming in the absence of symbolic links..I'm very uncertain how to reason about them. They allow for infinite loops in the namespace. Hardlinks too add additional confusion/meaning. Possible problem is that historically a symlink to an existing directory was reported as a directory. Now it is reported as a file. We could, expensively, first try stat, and if it fails for file/path not found, lstat instead. That might work. But I'd rather leave it as is. Maybe add another bit to the file status to indicate it is a symlink. Or possibly return the type as a new type, symlink, but no existing caller would know how to handle that. Probably adding another bit is reasonable, and update the Trestle file open dialogs to use a different icon. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Aug 4 12:56:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 10:56:13 +0000 Subject: [M3devel] m3override In-Reply-To: <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com> References: , , , , <20100730215051.GA23133@topoi.pooq.com>, , <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com> Message-ID: Specifically it is a warning about overriding the package you are building. The thing is, isn't the "bits and pieces overridden" model prone to just not work? Which pieces do you build vs. which do you leave alone? You need "everything" to be "fairly" consistent, for some definition of "everything" and "fairly". There is a larger unsolved problem here -- which parts of a system can you change independently of which parts? There are two extremes: one thing at a time, or everything at a time. The truth is generally in between: some things at a time. Which? "Everything" at a time is more difficult the larger you define "everything". "one" thing at a time, and again "one" possibly varies -- maybe you distribute .o files? "one" thing at at time leads to a combinatorial explosion of combination of "things" that are "supposed" to work. With some (enough?) runtime checking that a valid composition has been made. (Certainly Modula-3 tries much harder here than C.) I kind of espouse a model of "everything at time", but you can "pre-seed" the new package store/install with a copy/link of the original (as long you delete before writing over links). > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. Do you mean like, regarding $ORIGIN? Or something else? I'm too blame for giving us $ORIGIN, and I'm now very ambivalent about it. libtool + relink upon install seems the better approach and is widely used in practise. e.g. OpenBSD. This has a side benefit that uninstalled/unshipped dynamic binaries do work. I do suspect $ORIGIN was an improvement, since we don't relink upon install. There is also a hybrid suggestion of what I have suggested and the current model. You can still "build" into a new empty directory, with a hierarchy matching the install, leaving open either later install in-place or "reroot". I think, really, I have to back down from $ORIGIN, which restores "pick and chose" to work when it can, we can still, as I said, build into an install-like structure, and install by "reroot" or "delete and copy". I think the key is doing relink upon install. Along with, no longer distributing fully built binaries. There is a big task here but I think we have seen enough real problems and discussed enough the theory, to end up at a conclusion -- no $ORIGIN, no binaries, distribute C source, assembly source (or maybe .o files), and do final link on the target. We can distribute some common binaries, like with hardcoded install location. The hudon builds might be tricky, since if we build binaries to install to /usr/local/cm3, we can't then install and test them. Unless maybe chroot is possible as non-root?? Possibly Hudson builds would install to $HOME/... and just the final distribution wouldn't. Probably. I kind of..can't think of the word...really don't like this conclusion. Am nervous. How many people install binaries vs. compile/link? This would be signing up for much additional headache all around? Compile/link would fail for lots of people and we'd have to help them a lot more? Or it's not that bad and we just have to do it? - Jay > Date: Wed, 4 Aug 2010 08:49:30 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3override > > I wouldn't worry much about the warning Jay removed. > It only said that an override wasn't used, which is the default > behaviour of cm3 (without -x or -override option). One could argue > that if one wanted this warning, one should use an option like > -warn=overrides or -warn=all (which don't actually exist (yet)). > > However, I'd still like others to think about the two perspectives > one can take here, and what should be the direction we are tweaking > our build system. > > Traditionally, the focus was on the package view, i.e. the view of > one developer, and not a whole system. The builder was designed to > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. > With this focus, overrides are the sole responsibility of the > developer, and one could argue that he should know exactly what > he does if he uses them. > > In the CM3 distribution, I used the override feature to allow > building the whole set of package in the workspace, which can be > seen equivalent to use a completely different package pool. > The scripts (which originally were only meant as a tool for the > distribution maintainer) distinguish between build(local) and > buildglobal (or buildship). In the first case, the global package > store isn't involved at all. > > Jay has suggested to optimize towards building the whole distribution, > but I'm not sure yet if that's the correct direction. Obviously, > we need to support both perspectives. Much of the charm of the > M3 build system for large projects is based on the way the work > of the single developers can be split up and isolated. And in large > projects there are of course more developers than build or release > engineers. But then, there seems to have been no real use of CM3 for this > kind of development for many years; most (all?) active users seem to > work on their projects alone. So perhaps Jay is right after all? > > 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 Wed Aug 4 13:31:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 11:31:56 +0000 Subject: [M3devel] m3override In-Reply-To: References: , ,,, , , <20100730215051.GA23133@topoi.pooq.com>, , , , <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com>, Message-ID: ps: another suggestion here: Don't use overrides in Hudson or package building. Instead either build from scratch or with a new install that is a copy of the current (ie. of m3core/libm3). I alread automated this in make-dist.py, which is a based on some other *.sh. And then copy/swap at the end, or after some testing. Except, er, um, either this is with $ORIGIN, or with relink upon install -- not just copy/swap. The central sticking point in "all" this, in software configuration in general -- is "run path". And then, delete all the m3overrides files in the tree. And then optionally remove the entire mechanism, or leave it alone, unused, to bitrot. To some extent this is: don't bother implementing a mechanism in cm3, just do it in scripts. > M3 build system for large projects is based on the way the work > of the single developers can be split up and isolated. And in large Imagine a system composed of five pieces: bottom, almost bottom, middle, almost top, top. The developer of "top" has it easy, he uses the "existing" bottom, almost bottom, middle, almost top. What are the developers of any other piece to do? There are at least two factors to consider: run path public interfaces Even if public interfaces are unchanged, developer building a new "almost top", must either put it where "top" expects, or rebuild top to get it from the new location. It has been said that LD_LIBRARY_PATH is for development scenarios. So maybe that is the answer. To whatever extent systems are composed of just bottom and top and nobody changes bottom, which I think is actually pretty common, no problem, and people don't even understand the potential problem (I theorize). But that seems..wrong. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 4 Aug 2010 10:56:13 +0000 Subject: Re: [M3devel] m3override Specifically it is a warning about overriding the package you are building. The thing is, isn't the "bits and pieces overridden" model prone to just not work? Which pieces do you build vs. which do you leave alone? You need "everything" to be "fairly" consistent, for some definition of "everything" and "fairly". There is a larger unsolved problem here -- which parts of a system can you change independently of which parts? There are two extremes: one thing at a time, or everything at a time. The truth is generally in between: some things at a time. Which? "Everything" at a time is more difficult the larger you define "everything". "one" thing at a time, and again "one" possibly varies -- maybe you distribute .o files? "one" thing at at time leads to a combinatorial explosion of combination of "things" that are "supposed" to work. With some (enough?) runtime checking that a valid composition has been made. (Certainly Modula-3 tries much harder here than C.) I kind of espouse a model of "everything at time", but you can "pre-seed" the new package store/install with a copy/link of the original (as long you delete before writing over links). > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. Do you mean like, regarding $ORIGIN? Or something else? I'm too blame for giving us $ORIGIN, and I'm now very ambivalent about it. libtool + relink upon install seems the better approach and is widely used in practise. e.g. OpenBSD. This has a side benefit that uninstalled/unshipped dynamic binaries do work. I do suspect $ORIGIN was an improvement, since we don't relink upon install. There is also a hybrid suggestion of what I have suggested and the current model. You can still "build" into a new empty directory, with a hierarchy matching the install, leaving open either later install in-place or "reroot". I think, really, I have to back down from $ORIGIN, which restores "pick and chose" to work when it can, we can still, as I said, build into an install-like structure, and install by "reroot" or "delete and copy". I think the key is doing relink upon install. Along with, no longer distributing fully built binaries. There is a big task here but I think we have seen enough real problems and discussed enough the theory, to end up at a conclusion -- no $ORIGIN, no binaries, distribute C source, assembly source (or maybe .o files), and do final link on the target. We can distribute some common binaries, like with hardcoded install location. The hudon builds might be tricky, since if we build binaries to install to /usr/local/cm3, we can't then install and test them. Unless maybe chroot is possible as non-root?? Possibly Hudson builds would install to $HOME/... and just the final distribution wouldn't. Probably. I kind of..can't think of the word...really don't like this conclusion. Am nervous. How many people install binaries vs. compile/link? This would be signing up for much additional headache all around? Compile/link would fail for lots of people and we'd have to help them a lot more? Or it's not that bad and we just have to do it? - Jay > Date: Wed, 4 Aug 2010 08:49:30 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3override > > I wouldn't worry much about the warning Jay removed. > It only said that an override wasn't used, which is the default > behaviour of cm3 (without -x or -override option). One could argue > that if one wanted this warning, one should use an option like > -warn=overrides or -warn=all (which don't actually exist (yet)). > > However, I'd still like others to think about the two perspectives > one can take here, and what should be the direction we are tweaking > our build system. > > Traditionally, the focus was on the package view, i.e. the view of > one developer, and not a whole system. The builder was designed to > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. > With this focus, overrides are the sole responsibility of the > developer, and one could argue that he should know exactly what > he does if he uses them. > > In the CM3 distribution, I used the override feature to allow > building the whole set of package in the workspace, which can be > seen equivalent to use a completely different package pool. > The scripts (which originally were only meant as a tool for the > distribution maintainer) distinguish between build(local) and > buildglobal (or buildship). In the first case, the global package > store isn't involved at all. > > Jay has suggested to optimize towards building the whole distribution, > but I'm not sure yet if that's the correct direction. Obviously, > we need to support both perspectives. Much of the charm of the > M3 build system for large projects is based on the way the work > of the single developers can be split up and isolated. And in large > projects there are of course more developers than build or release > engineers. But then, there seems to have been no real use of CM3 for this > kind of development for many years; most (all?) active users seem to > work on their projects alone. So perhaps Jay is right after all? > > 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 wagner at elegosoft.com Wed Aug 4 14:58:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 14:58:30 +0200 Subject: [M3devel] m3override Message-ID: <20100804145830.yz17as1yo04sgc0s@mail.elegosoft.com> Quoting Jay K : > ps: another suggestion here: > Don't use overrides in Hudson or package building. > Instead either build from scratch or with a new install that is a > copy of the current (ie. of m3core/libm3). I alread automated this > in make-dist.py, which is a based on some other *.sh. > And then copy/swap at the end, or after some testing. > Except, er, um, either this is with $ORIGIN, or with relink upon > install -- not just copy/swap. > > The central sticking point in "all" this, in software configuration > in general -- is "run path". > > And then, delete all the m3overrides files in the tree. And then > optionally remove the entire mechanism, or leave it alone, unused, > to bitrot. > > To some extent this is: don't bother implementing a mechanism in > cm3, just do it in scripts. I've got no time for large changes, so we'll see if anybody cares to implement anything. >> M3 build system for large projects is based on the way the work >> of the single developers can be split up and isolated. And in large > > Imagine a system composed of five pieces: bottom, almost bottom, > middle, almost top, top. > The developer of "top" has it easy, he uses the "existing" bottom, > almost bottom, middle, almost top. > What are the developers of any other piece to do? > There are at least two factors to consider: > run path > public interfaces > > Even if public interfaces are unchanged, developer building a new > "almost top", must either put it where "top" expects, or rebuild top > to get it from the new location. > > It has been said that LD_LIBRARY_PATH is for development scenarios. > So maybe that is the answer. > > To whatever extent systems are composed of just bottom and top and > nobody changes bottom, which I think is actually pretty common, no > problem, and people don't even understand the potential problem (I > theorize). But that seems..wrong. Well, you see I've got the view of somebody building very large systems (much larger than the CM3 distribution) for commerical use. I've been working in such projects for the recent years; they're programmed in C/C++ and Java (and make and ClearCase and Perl scripts and ...), and build management and correct dependency tracking and use is always a nightmare. M3 with its powerful abstractions would be a great improvement there, but of course that's completely out of the question. But nonetheless it's still interesting to think about how M3 would actually compete in this domain. From a manager and user point of view, there are business functions which may be attached to some real or virtual machine or to some computing farm. From an architects view there are software layers, components with interfaces and implementations, containers for running processes and threads etc. And of course there are large external systems that are used or with which data must be exchanged. From a build and release engineers point of view, there are hundred thousands of files most of which exist in several hundred versions of which about a dozen or more are part of valid and still supported or actively developed configurations, that must build and play together consistently. And these must be unit tested, integration tested, system tested and performance tested. Everything (more or less) changes continually, starting with the requirements :-) Nobody has a complete overview, but the developers must be isolated and given a usable working configuration and setup to accomplish their tasks. This is where abstraction and information hiding show the biggest benefits. No developer here is able to build the whole system; most are even not allowed to read most of the code (if by accident or on purpose isn't always clear). And of course development teams are distributed to several sites around the world. So I'm not thinking about minor technical issues like $ORIGIN or LD_LIBRARY_PATH or about how we are best able to distribute the cm3 packages, but rather about M3 and its package and other abstraction mechanisms would stand its ground in such a project. And if we should really consider that or just be satisfied with our small CM3 community and use cases. 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 Wed Aug 4 15:37:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 13:37:48 +0000 Subject: [M3devel] m3cc package failures ignored? Message-ID: There's some problem, I've been noticing a while on my machine(s) where failure to build m3cc isn't noticed. e.g.: http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/21/console ??? ... -rw-r--r-- 1 hudson hudson??? 6872 2010-07-28 13:47 xstrerror.o -rw-r--r-- 1 hudson hudson??? 6736 2010-07-28 13:47 xstrndup.o ./libiberty/testsuite: total 4 -rw-r--r-- 1 hudson hudson 2722 2010-07-28 13:44 Makefile Fatal Error: package build failed ?==> m3-sys/m3cc done -- and then it keeps going -- === package m3-libs/m3core === ?+++ cm3 -build -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3' $RARGS? && cm3 -ship $RARGS -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3'? +++ From wagner at elegosoft.com Wed Aug 4 17:26:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 17:26:34 +0200 Subject: [M3devel] m3cc package failures ignored? In-Reply-To: References: Message-ID: <20100804172634.tt8y73lcwk8k40cg@mail.elegosoft.com> Quoting Jay K : > There's some problem, I've been noticing a while on my machine(s) > where failure to build m3cc isn't noticed. > > e.g.: > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/21/console > ... > -rw-r--r-- 1 hudson hudson??? 6872 2010-07-28 13:47 xstrerror.o > -rw-r--r-- 1 hudson hudson??? 6736 2010-07-28 13:47 xstrndup.o > > ./libiberty/testsuite: > total 4 > -rw-r--r-- 1 hudson hudson 2722 2010-07-28 13:44 Makefile > Fatal Error: package build failed > ?==> m3-sys/m3cc done > > -- and then it keeps going -- > > === package m3-libs/m3core === > ?+++ cm3 -build > -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3' $RARGS? && cm3 -ship $RARGS -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3'? > +++ That's probably due to a typo in the pkgmap script: Index: scripts/pkgmap.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/pkgmap.sh,v retrieving revision 1.58 diff -u -u -r1.58 pkgmap.sh --- scripts/pkgmap.sh 23 Jul 2010 16:08:08 -0000 1.58 +++ scripts/pkgmap.sh 4 Aug 2010 15:23:58 -0000 @@ -532,4 +532,4 @@ fi fi -[ -n "${OK}" ] || exit `printf "{$REDPKGS}" | wc | awk '{print $1}'` +[ -n "${OK}" ] || exit `printf "${REDPKGS}" | wc | awk '{print $1}'` Let me know when you see that again, 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 Aug 5 14:43:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 12:43:15 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? Message-ID: Olaf, this looks maybe like over aggressive manual cleanup on your part?? http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console S=/Volumes/maxstore1/home/hudson/workspace/cm3-current-build-PPC_DARWIN LASTREL=5.4.0 INSTROOT_REL=/Users/hudson/work/cm3-inst/apple/rel-5.4.0 INSTROOT_POK=/Users/hudson/work/cm3-inst/apple/prev-ok INSTROOT_LOK=/Users/hudson/work/cm3-inst/apple/last-ok INSTROOT_CUR=/Users/hudson/work/cm3-inst/apple/current CM3_OSTYPE=POSIX CM3_TARGET=PPC_DARWIN BINDISTMIN=/Users/hudson/work/cm3-min-POSIX-PPC_DARWIN-5.4.0.tgz CM3CVSSERVER=birch.elegosoft.com CM3CVSROOT=birch.elegosoft.com:/usr/cvs BINDISTMIN_NAME=cm3-min-POSIX-PPC_DARWIN-5.4.0.tgz BINDISTMIN=/Users/hudson/work/cm3-min-POSIX-PPC_DARWIN-5.4.0.tgz CM3CVSUSER= testing ssh birch.elegosoft.com.. ssh birch.elegosoft.com ok deleting outdated packages cache /Volumes/maxstore1/home/hudson/workspace/cm3-current-build-PPC_DARWIN/cm3/scripts/PKGS cp: /Users/hudson/work/cm3-inst/apple/last-ok: No such file or directory Finished: FAILURE ?- Jay From wagner at elegosoft.com Thu Aug 5 15:06:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 05 Aug 2010 15:06:13 +0200 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: Message-ID: <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com> Quoting Jay K : > Olaf, this looks maybe like over aggressive manual cleanup on your part?? > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console Well, kind of auto-cleanup actually :-) The external disk of that machine failed several days ago. I haven't got round to buy a new one, but tried to set up NFS access to my FreeBSD machine in a hurry this morning. That went well, but all the cm3 data are lost, so I had to install a compiler from release 5.8.6 (succeeded) and then boot the regression testing setup again (failed), see: http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console It's the gcc -m 32 issue again; I don't know yet if it's using the wrong C compiler, or something has changed in the config again, as I haven't direct access now. Maybe this evening. 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 Aug 5 15:54:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 13:54:24 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com> References: , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com> Message-ID: Ah, can you send the output of gcc -gstabs+ -fPIC -m32 -c -x c /dev/null gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null and try the updated Darwin.common? Thanks, ?- Jay ---------------------------------------- > Date: Thu, 5 Aug 2010 15:06:13 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: PPC_DARWIN failure missing last-ok? > > Quoting Jay K : > > > Olaf, this looks maybe like over aggressive manual cleanup on your part?? > > > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > > Well, kind of auto-cleanup actually :-) > > The external disk of that machine failed several days ago. I haven't > got round to buy a new one, but tried to set up NFS access to my FreeBSD > machine in a hurry this morning. That went well, but all the cm3 data > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > and then boot the regression testing setup again (failed), see: > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > C compiler, or something has changed in the config again, as I haven't > direct access now. Maybe this evening. > > 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 Aug 5 15:58:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 13:58:33 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, Message-ID: (and ssh access would help) ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Thu, 5 Aug 2010 13:54:24 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? > > > Ah, can you send the output of > > gcc -gstabs+ -fPIC -m32 -c -x c /dev/null > gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null > > and try the updated Darwin.common? > > Thanks, > - Jay > > ---------------------------------------- > > Date: Thu, 5 Aug 2010 15:06:13 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: PPC_DARWIN failure missing last-ok? > > > > Quoting Jay K : > > > > > Olaf, this looks maybe like over aggressive manual cleanup on your part?? > > > > > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > > > > Well, kind of auto-cleanup actually :-) > > > > The external disk of that machine failed several days ago. I haven't > > got round to buy a new one, but tried to set up NFS access to my FreeBSD > > machine in a hurry this morning. That went well, but all the cm3 data > > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > > and then boot the regression testing setup again (failed), see: > > > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > > > > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > > C compiler, or something has changed in the config again, as I haven't > > direct access now. Maybe this evening. > > > > 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 Thu Aug 5 16:14:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 05 Aug 2010 16:14:15 +0200 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, Message-ID: <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com> Quoting Jay K : > (and ssh access would help) I just added your gcc lines below to the boot job; I also changed the checkout of the release branch to the trunk (maybe it will work now). The job is still running. See http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/4/console You should be able to access the machine as user hudson from birch (if you can su to hudson there) at port 223 at luthien.dyndns.org if I remember correctly. If you cannot su to hudson, I need to place your public ssh key on the machine, but cannot do that before this evening, too. As usual, only HTTP access from here. Olaf > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> Date: Thu, 5 Aug 2010 13:54:24 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? >> >> >> Ah, can you send the output of >> >> gcc -gstabs+ -fPIC -m32 -c -x c /dev/null >> gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null >> >> and try the updated Darwin.common? >> >> Thanks, >> - Jay >> >> ---------------------------------------- >> > Date: Thu, 5 Aug 2010 15:06:13 +0200 >> > From: wagner at elegosoft.com >> > To: jay.krell at cornell.edu >> > CC: m3devel at elegosoft.com >> > Subject: Re: PPC_DARWIN failure missing last-ok? >> > >> > Quoting Jay K : >> > >> > > Olaf, this looks maybe like over aggressive manual cleanup on >> your part?? >> > > >> > > >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console >> > >> > Well, kind of auto-cleanup actually :-) >> > >> > The external disk of that machine failed several days ago. I haven't >> > got round to buy a new one, but tried to set up NFS access to my FreeBSD >> > machine in a hurry this morning. That went well, but all the cm3 data >> > are lost, so I had to install a compiler from release 5.8.6 (succeeded) >> > and then boot the regression testing setup again (failed), see: >> > >> > >> http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console >> > >> > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong >> > C compiler, or something has changed in the config again, as I haven't >> > direct access now. Maybe this evening. >> > >> > 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 >> > >> > -- 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 Aug 5 16:20:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:20:23 +0000 Subject: [M3devel] linuxlibc6 crashing Message-ID: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-LINUXLIBC6/52/console cm3 is /home/hudson/work/cm3-inst/xlin2/last-ok/bin/cm3 *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 *** ./defs.sh: line 728: 14797 Aborted cm3 -version *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 *** >>> test_m3tests error extract: /usr/bin/find: `LINUXLIBC6': No such file or directory >>> OK test_m3tests 2010-08-05-14-07-28 /home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6 === 2010-08-05 14:07:31 cm3 m3tests run done cp: cannot stat `/home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6/cm3/m3-sys/m3tests/m3tests.html': No such file or directory I'm aware, not sure what the problem is, not sure it is widespread. Seems kind of like struct stat overflow..and the recent change from stat to lstat, but really..seems corect as well... Might have to intervene manually..but I don't know what the fix is yet. ?- Jay From jay.krell at cornell.edu Thu Aug 5 16:19:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:19:13 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com> References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, , , <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com> Message-ID: Cool. I think manually updating the config might be required. We'll see. I'm going to have reduced hours here for about 10 days soon.. Thanks, ?- Jay ---------------------------------------- > Date: Thu, 5 Aug 2010 16:14:15 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] PPC_DARWIN failure missing last-ok? > > Quoting Jay K : > > > (and ssh access would help) > > I just added your gcc lines below to the boot job; I also changed > the checkout of the release branch to the trunk (maybe it will work > now). The job is still running. See > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/4/console > > You should be able to access the machine as user hudson from birch > (if you can su to hudson there) at port 223 at luthien.dyndns.org > if I remember correctly. > > If you cannot su to hudson, I need to place your public ssh key on > the machine, but cannot do that before this evening, too. As usual, > only HTTP access from here. > > Olaf > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: wagner at elegosoft.com > >> Date: Thu, 5 Aug 2010 13:54:24 +0000 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? > >> > >> > >> Ah, can you send the output of > >> > >> gcc -gstabs+ -fPIC -m32 -c -x c /dev/null > >> gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null > >> > >> and try the updated Darwin.common? > >> > >> Thanks, > >> - Jay > >> > >> ---------------------------------------- > >> > Date: Thu, 5 Aug 2010 15:06:13 +0200 > >> > From: wagner at elegosoft.com > >> > To: jay.krell at cornell.edu > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: PPC_DARWIN failure missing last-ok? > >> > > >> > Quoting Jay K : > >> > > >> > > Olaf, this looks maybe like over aggressive manual cleanup on > >> your part?? > >> > > > >> > > > >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > >> > > >> > Well, kind of auto-cleanup actually :-) > >> > > >> > The external disk of that machine failed several days ago. I haven't > >> > got round to buy a new one, but tried to set up NFS access to my FreeBSD > >> > machine in a hurry this morning. That went well, but all the cm3 data > >> > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > >> > and then boot the regression testing setup again (failed), see: > >> > > >> > > >> http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > >> > > >> > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > >> > C compiler, or something has changed in the config again, as I haven't > >> > direct access now. Maybe this evening. > >> > > >> > 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 > >> > > >> > > > > > > -- > 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 Aug 5 16:41:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:41:37 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, , , <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com>, Message-ID: ok I manually fixed it up. pwd /Users/hudson/work/cm3-inst/apple/rel-5.8.6/bin/config mv Darwin.common Darwin.common.1 vi Darwin.common diff Darwin.common.1 Darwin.common Something like: released 5.8.6 doesn't work on PPC_DARWIN 10.3, needs slight config edit. Fixed perhaps in head. We'll see. gcc_select 4.0 as root would fix it. Given that -arch is supported, probably no point to -m32/64. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] PPC_DARWIN failure missing last-ok? > Date: Thu, 5 Aug 2010 14:19:13 +0000 > > > Cool. I think manually updating the config might be required. We'll see. > I'm going to have reduced hours here for about 10 days soon.. > > Thanks, > - Jay > > ---------------------------------------- > > Date: Thu, 5 Aug 2010 16:14:15 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] PPC_DARWIN failure missing last-ok? > > > > Quoting Jay K : > > > > > (and ssh access would help) > > > > I just added your gcc lines below to the boot job; I also changed > > the checkout of the release branch to the trunk (maybe it will work > > now). The job is still running. See > > > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/4/console > > > > You should be able to access the machine as user hudson from birch > > (if you can su to hudson there) at port 223 at luthien.dyndns.org > > if I remember correctly. > > > > If you cannot su to hudson, I need to place your public ssh key on > > the machine, but cannot do that before this evening, too. As usual, > > only HTTP access from here. > > > > Olaf > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: wagner at elegosoft.com > > >> Date: Thu, 5 Aug 2010 13:54:24 +0000 > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? > > >> > > >> > > >> Ah, can you send the output of > > >> > > >> gcc -gstabs+ -fPIC -m32 -c -x c /dev/null > > >> gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null > > >> > > >> and try the updated Darwin.common? > > >> > > >> Thanks, > > >> - Jay > > >> > > >> ---------------------------------------- > > >> > Date: Thu, 5 Aug 2010 15:06:13 +0200 > > >> > From: wagner at elegosoft.com > > >> > To: jay.krell at cornell.edu > > >> > CC: m3devel at elegosoft.com > > >> > Subject: Re: PPC_DARWIN failure missing last-ok? > > >> > > > >> > Quoting Jay K : > > >> > > > >> > > Olaf, this looks maybe like over aggressive manual cleanup on > > >> your part?? > > >> > > > > >> > > > > >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > > >> > > > >> > Well, kind of auto-cleanup actually :-) > > >> > > > >> > The external disk of that machine failed several days ago. I haven't > > >> > got round to buy a new one, but tried to set up NFS access to my FreeBSD > > >> > machine in a hurry this morning. That went well, but all the cm3 data > > >> > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > > >> > and then boot the regression testing setup again (failed), see: > > >> > > > >> > > > >> http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > > >> > > > >> > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > > >> > C compiler, or something has changed in the config again, as I haven't > > >> > direct access now. Maybe this evening. > > >> > > > >> > 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 > > >> > > > >> > > > > > > > > > > > -- > > 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 Aug 5 16:48:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:48:08 +0000 Subject: [M3devel] linuxlibc6 crashing In-Reply-To: References: Message-ID: (manual intervention) I cross built cm3 and copied that over the crashing one. We'll see. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Thu, 5 Aug 2010 14:20:23 +0000 > Subject: [M3devel] linuxlibc6 crashing > > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-LINUXLIBC6/52/console > > cm3 is /home/hudson/work/cm3-inst/xlin2/last-ok/bin/cm3 > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > *** > > ./defs.sh: line 728: 14797 Aborted cm3 -version > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > *** > > >>> test_m3tests error extract: > /usr/bin/find: `LINUXLIBC6': No such file or directory > >>> OK test_m3tests 2010-08-05-14-07-28 /home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6 > === 2010-08-05 14:07:31 cm3 m3tests run done > cp: cannot stat `/home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6/cm3/m3-sys/m3tests/m3tests.html': No such file or directory > > > I'm aware, not sure what the problem is, not sure it is widespread. > > Seems kind of like struct stat overflow..and the recent change from stat to lstat, but really..seems corect as well... > Might have to intervene manually..but I don't know what the fix is yet. > > - Jay > > > > > From jay.krell at cornell.edu Fri Aug 6 11:23:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 6 Aug 2010 09:23:16 +0000 Subject: [M3devel] Hudson/PPC_DARWIN Message-ID: http://hudson.modula3.com:8080/job/cm3-current-m3cc-PPC_DARWIN/19/console config.status: linking ../../gcc/gmp/mpn/generic/gmp-mparam.h to gmp-mparam.h make[1]: Entering directory `/Volumes/luthien/home/hudson2/workspace/cm3-m3cc-PPC_DARWIN/cm3/m3-sys/m3cc/PPC_DARWIN/gmp' gcc `test -f 'gen-fac_ui.c' || echo '../../gcc/gmp/'`gen-fac_ui.c -o gen-fac_ui /var/tmp//ccZolN95.s:unknown:FATAL:can't write output file $TMPDIR not placed well? ? - Jay From jay.krell at cornell.edu Fri Aug 6 11:24:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 6 Aug 2010 09:24:36 +0000 Subject: [M3devel] Hudson/NT386 Message-ID: NT386 node offline? Then again, it is in good shape: http://hudson.modula3.com:8080/job/cm3-current-build-NT386/25/console still need to clean this up: P m3-sys/cminstall/src/config-no-install/MIPS64EL_OPENBSD cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' on a few machines. ?- Jay From wagner at elegosoft.com Fri Aug 6 12:04:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 06 Aug 2010 12:04:59 +0200 Subject: [M3devel] Hudson/PPC_DARWIN In-Reply-To: References: Message-ID: <20100806120459.edxuddkg000sksos@mail.elegosoft.com> Quoting Jay K : > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-PPC_DARWIN/19/console > > config.status: linking ../../gcc/gmp/mpn/generic/gmp-mparam.h to gmp-mparam.h > make[1]: Entering directory > `/Volumes/luthien/home/hudson2/workspace/cm3-m3cc-PPC_DARWIN/cm3/m3-sys/m3cc/PPC_DARWIN/gmp' > gcc `test -f 'gen-fac_ui.c' || echo '../../gcc/gmp/'`gen-fac_ui.c -o > gen-fac_ui > /var/tmp//ccZolN95.s:unknown:FATAL:can't write output file > > > $TMPDIR not placed well? No, Hudson had a wrong root path configured, which was now accidentally on the root disk with the external mount missing, so it didn't really use the space on the NFS. I've fixed it now. 1.5 GB are free again on root and should stay so. 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 Aug 6 12:11:01 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 06 Aug 2010 12:11:01 +0200 Subject: [M3devel] Hudson/NT386 In-Reply-To: References: Message-ID: <20100806121101.ikn8jhkxs0cgo088@mail.elegosoft.com> Quoting Jay K : > NT386 node offline? The connection to this machine is still unstable, it goes offline whenever I turn my eyes. I'm afraid Elego won't be able to provide something better here, so other resources for continous integration on Windows would still be welcome. 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 Fri Aug 6 12:20:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 6 Aug 2010 10:20:07 +0000 Subject: [M3devel] hudson nodes Message-ID: most/all of my Hudson nodes will be down August 6 - 15. I'll probably leave just Linux/x86. They will all be back late August 15. - Jay From jay.krell at cornell.edu Sat Aug 7 08:21:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 06:21:44 +0000 Subject: [M3devel] Hudson/CVS/Tag release Message-ID: We should delete these checkouts/workspaces to remove any doubt about targeting head? (just the last two, mainly, but the timestamps being back in July is a bit off) I was looking into the: cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' stuff, which I've been cleaning up just by deleting. % ls -l? */cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21? 7 Aug 08:03 cm3-current-build-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21 18 Jul 22:46 cm3-current-m3cc-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21? 6 Aug 20:40 cm3-current-test-all-pkgs-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21 19 Jul 23:28 cm3-current-test-m3tests-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 19? 8 Jul 17:34 cm3-makedist-FreeBSD4/cm3/CVS/Tag -rw-rw----? 1 hudson? Ghudson? 24? 9 Jul 12:22 cm3-test-all-pkgs-FreeBSD4/cm3/CVS/Tag new.elego.de [~/workspace] hudson % cat */cm3/CVS/Tag D2010.08.07.05.59.47 D2010.07.18.20.45.58 D2010.08.06.18.37.22 D2010.07.19.21.28.10 Nrelease_CM3_5_8_6 Trelease_branch_cm3_5_8 new.elego.de [~/workspace] hudson % hostname new.elego.de new.elego.de [~/workspace] hudson % pwd /pub/users/hudson/workspace new.elego.de [~/workspace] hudson % uname -a FreeBSD new.elego.de 6.4-RELEASE-p5 FreeBSD 6.4-RELEASE-p5 #1: Sun Jun 14 14:03:37 CEST 2009???? root at new.elego.de:/usr/obj/usr/src/sys/GENERIC? i386 new.elego.de [~/workspace] hudson From jay.krell at cornell.edu Sat Aug 7 08:27:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 06:27:07 +0000 Subject: [M3devel] linuxlibc6 crashing In-Reply-To: References: , Message-ID: same thing here: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/15/consoleFull but it went away: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/16/consoleFull ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] linuxlibc6 crashing > Date: Thu, 5 Aug 2010 14:48:08 +0000 > > > (manual intervention) > I cross built cm3 and copied that over the crashing one. We'll see. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Thu, 5 Aug 2010 14:20:23 +0000 > > Subject: [M3devel] linuxlibc6 crashing > > > > > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-LINUXLIBC6/52/console > > > > cm3 is /home/hudson/work/cm3-inst/xlin2/last-ok/bin/cm3 > > > > > > *** > > *** runtime error: > > *** Segmentation violation - possible attempt to dereference NIL > > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > > *** > > > > ./defs.sh: line 728: 14797 Aborted cm3 -version > > > > > > *** > > *** runtime error: > > *** Segmentation violation - possible attempt to dereference NIL > > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > > *** > > > > >>> test_m3tests error extract: > > /usr/bin/find: `LINUXLIBC6': No such file or directory > > >>> OK test_m3tests 2010-08-05-14-07-28 /home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6 > > === 2010-08-05 14:07:31 cm3 m3tests run done > > cp: cannot stat `/home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6/cm3/m3-sys/m3tests/m3tests.html': No such file or directory > > > > > > I'm aware, not sure what the problem is, not sure it is widespread. > > > > Seems kind of like struct stat overflow..and the recent change from stat to lstat, but really..seems corect as well... > > Might have to intervene manually..but I don't know what the fix is yet. > > > > - Jay > > > > > > > > > > > From wagner at elegosoft.com Sat Aug 7 09:05:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 07 Aug 2010 09:05:26 +0200 Subject: [M3devel] Hudson/CVS/Tag release In-Reply-To: References: Message-ID: <20100807090526.9a6odj4lwsowkc8s@mail.elegosoft.com> Quoting Jay K : > We should delete these checkouts/workspaces to remove any doubt > about targeting head? The last 2 were last used to build on the release branch. Those for the trunk all have the -current- in the name. You may remove them if you need space. The last contains some HTML results that might be worth to preserve though. Why is there any doubt which jobs follow head and which don't? Olaf > (just the last two, mainly, but the timestamps being back in July is > a bit off) > I was looking into the: > > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for > `m3-sys/m3cc/gcc/fixincludes' > > stuff, which I've been cleaning up just by deleting. > > % ls -l? */cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21? 7 Aug 08:03 > cm3-current-build-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21 18 Jul 22:46 > cm3-current-m3cc-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21? 6 Aug 20:40 > cm3-current-test-all-pkgs-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21 19 Jul 23:28 > cm3-current-test-m3tests-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 19? 8 Jul 17:34 > cm3-makedist-FreeBSD4/cm3/CVS/Tag > -rw-rw----? 1 hudson? Ghudson? 24? 9 Jul 12:22 > cm3-test-all-pkgs-FreeBSD4/cm3/CVS/Tag > new.elego.de [~/workspace] hudson > % cat */cm3/CVS/Tag > D2010.08.07.05.59.47 > D2010.07.18.20.45.58 > D2010.08.06.18.37.22 > D2010.07.19.21.28.10 > Nrelease_CM3_5_8_6 > Trelease_branch_cm3_5_8 > new.elego.de [~/workspace] hudson > % hostname > new.elego.de > new.elego.de [~/workspace] hudson > % pwd > /pub/users/hudson/workspace > new.elego.de [~/workspace] hudson > % uname -a > FreeBSD new.elego.de 6.4-RELEASE-p5 FreeBSD 6.4-RELEASE-p5 #1: Sun > Jun 14 14:03:37 CEST 2009???? > root at new.elego.de:/usr/obj/usr/src/sys/GENERIC? i386 > new.elego.de [~/workspace] hudson > > -- 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 Sat Aug 7 16:30:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 14:30:19 +0000 Subject: [M3devel] more Hudson nodes? more help in general? Message-ID: Hey, I'm hoping we can get more people helping more. Coding, features, fixing bugs, etc. However one of the easiest things I'd like to see is a few more Hudson nodes. Is anyone out there running e.g. NetBSD on x86 or AMD64? ? They would be the easiest, sort of, to setup. I will help anyone. ? Or Solaris on SPARC (replace mine) or x86? (Yes I know about opencsw, but the network ? topology is seemingly difficult.) Or heck, Linux or OpenBSD on x86? (replace mine) x86/AMD64 in particular has better availability of Java VMs, which we need. Or, Linux now has good across the board Java support. And can setup dynamic DNS or has static IP? We could use NT386 but I know the setup might not be so easy. There are other viable machines, e.g. one of the new or old Linux/mips. Or likely some of the obscure systems like HP-UX, AIX, Irix. If anyone here is actively running one of these, keeps machine on, speak up. (At some point, I'd like to have Hudson wake-on-lan the machines, or have the machines scheduled to wake up daily check for work, and then back to sleep after completing any queued work; the second option doesn't require Hudson support.) The machine can be quite low end. Many of mine are old laptops, or very old either way. Around $200, years ago. Any other projects in the system people are interested in helping out on, with ? time/coding, please speak up if you need help. If you need ideas, or assistance, etc. Thanks, ?- Jay From jay.krell at cornell.edu Sat Aug 7 16:53:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 14:53:12 +0000 Subject: [M3devel] build_platform in archive names In-Reply-To: <20100807105849.2B48724740EC@birch.elegosoft.com> References: <20100807105849.2B48724740EC@birch.elegosoft.com> Message-ID: Thanks! I want something slightly different for NT platforms. NT doesn't have the binary incompatibility and cross-build problem of Unix, at the OS level. ? (and commercial Unix isn't so bad either I think these days) However it does sort of have it at the C runtime level. i.e. There is no need to say e.g. XP/Vista/Win7/NT5.1/6.0/6.1, but there is a need to say e.g. msvc70/71/80/90/100. And there probably is a need for Cygwin-1.5 vs. Cygwin-1.7 (ie. exactly what you have). You can see in pylib.py: def FormInstallRoot(PackageSetName): ??? AltConfig = {"NT386":"x86"}.get(Config, Config) ??? a = os.path.join(GetStage(), "cm3-" + PackageSetName + "-" + AltConfig + "-" + CM3VERSION) ??? if Config == "NT386" or Config == "I386_NT": ??????? a = a + "-VC" + GetVisualCPlusPlusVersion() ??? else: ??????? b = os.popen("uname -sr").read() ??????? b = re.sub("Linux 2.4\..+$", "Linux2.4", b) ??????? b = re.sub("Linux 2.6\..+$", "", b) ??????? b = re.sub("-.+$", "", b) ??????? b = re.sub("SunOS", "Solaris", b) ??????? b = re.sub("[ \r\n]", "", b) ??????? a = a + "-" + b ??? a = a + "-" + time.strftime("%Y%m%d") ??? return a uname -p redundant with $(TARGET), er..the other way around.. config.guess/uname maybe is the preferable way. I guess that's a bigger leap right now, and it isn't entirely true, e.g. on "biarch" systems, e.g. AMD64_{DARWIN,SOLARIS}, SPARC64_SOLARIS, PPC64_DARWIN, etc.. def GetVisualCPlusPlusVersion(): ??? a = os.popen("cl 2>&1 >nul").read().lower() ??? if a.find("9.00") != -1: ??????? return "20" ??? if a.find("10.00") != -1: ??????? return "40" ??? if a.find("10.10") != -1: ??????? return "41" ??? if a.find("10.20") != -1: ??????? return "42" ??? if a.find("11.00") != -1: ??????? return "50" ??? if a.find("12.00") != -1: ??????? return "60" ??? if a.find("13.00") != -1: ??????? return "70" ??? if a.find("13.10") != -1: ??????? return "71" ??? if a.find("14.00") != -1: ??????? return "80" ??? if a.find("15.00") != -1: ??????? return "90" ??? if a.find("16.00") != -1: ??????? return "100" ??? FatalError("unable to detect Visual C++ version, maybe cl is not in %PATH%?") but I'm just talking..need to try to work it in to your *.sh. ?- Jay ---------------------------------------- > Date: Sat, 7 Aug 2010 12:58:48 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 10/08/07 12:58:48 > > Modified files: > cm3/scripts/: make-bin-dist-min.sh make-dist.sh sysinfo.sh > cm3/scripts/regression/: update_snapshot_status.sh > > Log message: > fix snapshot support and add build_platform > From wagner at elegosoft.com Sat Aug 7 16:59:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 07 Aug 2010 16:59:43 +0200 Subject: [M3devel] build_platform in archive names In-Reply-To: References: <20100807105849.2B48724740EC@birch.elegosoft.com> Message-ID: <20100807165943.ygl506lqo80kokok@mail.elegosoft.com> I've left out Windows, because I wasn't sure what exactly was needed there. Feel free to add an appropriate string for all Windows-based target platforms! Olaf Quoting Jay K : > Thanks! > I want something slightly different for NT platforms. > NT doesn't have the binary incompatibility and cross-build problem > of Unix, at the OS level. > ? (and commercial Unix isn't so bad either I think these days) > However it does sort of have it at the C runtime level. > i.e. There is no need to say e.g. XP/Vista/Win7/NT5.1/6.0/6.1, but > there is a need to say e.g. msvc70/71/80/90/100. > And there probably is a need for Cygwin-1.5 vs. Cygwin-1.7 (ie. > exactly what you have). > > You can see in pylib.py: > > def FormInstallRoot(PackageSetName): > ??? AltConfig = {"NT386":"x86"}.get(Config, Config) > ??? a = os.path.join(GetStage(), "cm3-" + PackageSetName + "-" + > AltConfig + "-" + CM3VERSION) > ??? if Config == "NT386" or Config == "I386_NT": > ??????? a = a + "-VC" + GetVisualCPlusPlusVersion() > ??? else: > ??????? b = os.popen("uname -sr").read() > ??????? b = re.sub("Linux 2.4\..+$", "Linux2.4", b) > ??????? b = re.sub("Linux 2.6\..+$", "", b) > ??????? b = re.sub("-.+$", "", b) > ??????? b = re.sub("SunOS", "Solaris", b) > ??????? b = re.sub("[ \r\n]", "", b) > ??????? a = a + "-" + b > ??? a = a + "-" + time.strftime("%Y%m%d") > ??? return a > > > uname -p redundant with $(TARGET), er..the other way around.. > config.guess/uname maybe is the preferable way. > I guess that's a bigger leap right now, and it isn't entirely true, > e.g. on "biarch" systems, e.g. AMD64_{DARWIN,SOLARIS}, > SPARC64_SOLARIS, PPC64_DARWIN, etc.. > > > def GetVisualCPlusPlusVersion(): > ??? a = os.popen("cl 2>&1 >nul").read().lower() > ??? if a.find("9.00") != -1: > ??????? return "20" > ??? if a.find("10.00") != -1: > ??????? return "40" > ??? if a.find("10.10") != -1: > ??????? return "41" > ??? if a.find("10.20") != -1: > ??????? return "42" > ??? if a.find("11.00") != -1: > ??????? return "50" > ??? if a.find("12.00") != -1: > ??????? return "60" > ??? if a.find("13.00") != -1: > ??????? return "70" > ??? if a.find("13.10") != -1: > ??????? return "71" > ??? if a.find("14.00") != -1: > ??????? return "80" > ??? if a.find("15.00") != -1: > ??????? return "90" > ??? if a.find("16.00") != -1: > ??????? return "100" > ??? FatalError("unable to detect Visual C++ version, maybe cl is not > in %PATH%?") > > > but I'm just talking..need to try to work it in to your *.sh. > > > ?- Jay > > ---------------------------------------- >> Date: Sat, 7 Aug 2010 12:58:48 +0000 >> To: m3commit at elegosoft.com >> From: wagner at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: wagner at birch. 10/08/07 12:58:48 >> >> Modified files: >> cm3/scripts/: make-bin-dist-min.sh make-dist.sh sysinfo.sh >> cm3/scripts/regression/: update_snapshot_status.sh >> >> Log message: >> fix snapshot support and add build_platform >> > -- 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 Sat Aug 7 21:51:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 19:51:26 +0000 Subject: [M3devel] elego compact In-Reply-To: <20100807161924.5CA4924740DC@birch.elegosoft.com> References: <20100807161924.5CA4924740DC@birch.elegosoft.com> Message-ID: Cool. Notice the derived files (directory AMD64_FREEBSD) got imported. - Jay ---------------------------------------- > Date: Sat, 7 Aug 2010 18:19:23 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 10/08/07 18:19:23 > > cm3/elego > > Update of /usr/cvs/cm3/elego > In directory birch:/tmp/cvs-serv13035 > > Log Message: > Stripped-down version of Elego ComPact; software developed and used > at Elego years ago. I put it under the same copyright as the other > Modula-3 sources from DEC and Critical Mass. > > Included is package version management based on CVS and build and > version management for sets of packages, called `project management' > in ComPact. > > Not included is the general package manager for C/C++/Java/M3, and the > ComPact GUI. > > It is contributed in the hope that it may be useful in whole or parts > for the CM3 project or any other users. > > The command line interface consists of the programs pkgvm and prjm, > which include complete manuals as well as short usage help: > > pkgvm -help | -man > prjm -help | -man > > The sources have been successfully compiled with a current cm3 (d5.9.0) > by prjm with > > prjm -D ROOT=$HOME/work/cm3 -buildglobal > > The project definition is contained in the file elego/PrjDesc. > > To compile everything with the CM3 srcipts, use > > ~/work/cm3/scripts/do-pkg.sh buildship langutils graphicutils tuple depgraph miniscan fsfind fileinfo filepool pkgversions compact-copyright rsrcservice compact-client compactrc pkg_base pkg_vc m3makefile m3dep m3dir m3err m3msh m3ovr pkgvm prjbase prjm > > Several things may still be wrong and need to be adapted for use with > the current CM3, but the ComPact tools should be quite flexible and > configurable. > > As all free software, this comes without any guarantee that it will > be useful in any way. Use at your own risk. > > Olaf Wagner / Elego Software Solutions GmbH, Berlin, Germany, 2010-08-07 > > > Status: > > Vendor Tag: elego-compact-free-1-0 > Release Tags: rel-compact-free-1-0 > > N cm3/elego/DepGraph > N cm3/elego/quake.elego > N cm3/elego/PrjDesc > N cm3/elego/srcs > N cm3/elego/compact-copyright/PkgTags > N cm3/elego/compact-copyright/PkgErr > N cm3/elego/compact-copyright/src/Copyright.m3 > N cm3/elego/compact-copyright/src/Release.m3 > N cm3/elego/compact-copyright/src/m3overrides > N cm3/elego/compact-copyright/src/ProgramVersion.i3 > N cm3/elego/compact-copyright/src/Version.i3 > N cm3/elego/compact-copyright/src/Release.i3 > N cm3/elego/compact-copyright/src/compact-copyrights.txt > N cm3/elego/compact-copyright/src/m3makefile > N cm3/elego/compact-copyright/src/Copyright.i3 > N cm3/elego/compact-copyright/src/ProgramVersion.m3 > N cm3/elego/compact-copyright/src/get-licences > N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.io > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.io > N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.so.5 > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.i3 > N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.io > N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3SHIP > N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.mo > N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.m3x > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.m3 > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.mo > N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3WEB > N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.mo > N cm3/elego/filepool/PkgTags > N cm3/elego/filepool/PkgErr > N cm3/elego/filepool/src/m3overrides > N cm3/elego/filepool/src/FilePool.m3 > N cm3/elego/filepool/src/m3makefile > N cm3/elego/filepool/src/FilePool.i3 > N cm3/elego/filepool/test/src/Main.m3 > N cm3/elego/filepool/test/src/m3makefile > N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.so.5 > N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.m3x > N cm3/elego/filepool/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/filepool/AMD64_FREEBSD/.M3SHIP > N cm3/elego/filepool/AMD64_FREEBSD/FilePool.io > N cm3/elego/filepool/AMD64_FREEBSD/.M3WEB > N cm3/elego/filepool/AMD64_FREEBSD/FilePool.mo > N cm3/elego/m3err/PkgTags > N cm3/elego/m3err/m3err.gmon > N cm3/elego/m3err/PkgErr > N cm3/elego/m3err/src/m3overrides > N cm3/elego/m3err/src/m3err.m3 > N cm3/elego/m3err/src/m3makefile > N cm3/elego/m3err/AMD64_FREEBSD/m3err > N cm3/elego/m3err/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3err/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3err/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3err/AMD64_FREEBSD/m3err.mo > N cm3/elego/m3err/AMD64_FREEBSD/m3err.mx > N cm3/elego/m3err/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3err/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3err/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3err/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3err/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3err/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3err/AMD64_FREEBSD/Creation.io > N cm3/elego/prjbase/PkgTags > N cm3/elego/prjbase/PkgErr > N cm3/elego/prjbase/snaps/snaps.idx > N cm3/elego/prjbase/src/PrjDesc.i3 > N cm3/elego/prjbase/src/ChangeSet.i3 > N cm3/elego/prjbase/src/Checkpoint.i3 > N cm3/elego/prjbase/src/PrjDesc.m3 > N cm3/elego/prjbase/src/Snapshots.i3 > N cm3/elego/prjbase/src/Snapshots.m3 > N cm3/elego/prjbase/src/ChangeSet.m3 > N cm3/elego/prjbase/src/m3overrides > N cm3/elego/prjbase/src/RCS_Date.i3 > N cm3/elego/prjbase/src/PoolSet.i3 > N cm3/elego/prjbase/src/RCS_Date.m3 > N cm3/elego/prjbase/src/PoolSet.m3 > N cm3/elego/prjbase/src/Checkpoint.m3 > N cm3/elego/prjbase/src/rcsdate.patch > N cm3/elego/prjbase/src/m3makefile > N cm3/elego/prjbase/src/m3browser.html > N cm3/elego/prjbase/test/src/PrjDesc1 > N cm3/elego/prjbase/test/src/PrjDesc2 > N cm3/elego/prjbase/test/src/Main.m3 > N cm3/elego/prjbase/test/src/m3makefile > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.io > N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.mo > N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.io > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.m3x > N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.io > N cm3/elego/prjbase/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/.M3SHIP > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.so.5 > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.io > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/.M3WEB > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.io > N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.i3 > N cm3/elego/tuple/PkgTags > N cm3/elego/tuple/PkgErr > N cm3/elego/tuple/src/TextTuple.m3 > N cm3/elego/tuple/src/TextTuple.i3 > N cm3/elego/tuple/src/Dummy.i3 > N cm3/elego/tuple/src/m3overrides > N cm3/elego/tuple/src/Tuple.mg > N cm3/elego/tuple/src/Tuple.ig > N cm3/elego/tuple/src/m3makefile > N cm3/elego/tuple/src/Dummy.m3 > N cm3/elego/tuple/src/HeteroTuple.mg > N cm3/elego/tuple/src/HeteroTuple.ig > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.i3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.io > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.io > N cm3/elego/tuple/AMD64_FREEBSD/libtuple.so.5 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.i3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.io > N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.mo > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.mo > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.i3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.mo > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.io > N cm3/elego/tuple/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/tuple/AMD64_FREEBSD/.M3SHIP > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.io > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.m3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.m3 > N cm3/elego/tuple/AMD64_FREEBSD/.M3WEB > N cm3/elego/tuple/AMD64_FREEBSD/libtuple.m3x > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.i3 > N cm3/elego/langutils/PkgTags > N cm3/elego/langutils/PkgErr > N cm3/elego/langutils/src/m3overrides > N cm3/elego/langutils/src/SimpleValueEnv.m3 > N cm3/elego/langutils/src/SimpleValueEnv.i3 > N cm3/elego/langutils/src/m3makefile > N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.m3x > N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.mo > N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.so.5 > N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.io > N cm3/elego/langutils/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/langutils/AMD64_FREEBSD/.M3SHIP > N cm3/elego/langutils/AMD64_FREEBSD/.M3WEB > N cm3/elego/prjm/PkgTags > N cm3/elego/prjm/PrjDesc > N cm3/elego/prjm/stat > N cm3/elego/prjm/PkgErr > N cm3/elego/prjm/src/m3overrides > N cm3/elego/prjm/src/Copyright > N cm3/elego/prjm/src/PrjmGUI.fv > N cm3/elego/prjm/src/m3makefile > N cm3/elego/prjm/src/ProjectManager.m3 > N cm3/elego/prjm/src/ShortUsageHelp > N cm3/elego/prjm/src/UsageHelp > N cm3/elego/prjm/src/compactrc > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.io > N cm3/elego/prjm/AMD64_FREEBSD/prjm.mx > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.i3 > N cm3/elego/prjm/AMD64_FREEBSD/_m3main.mc > N cm3/elego/prjm/AMD64_FREEBSD/Creation.i3 > N cm3/elego/prjm/AMD64_FREEBSD/prjm > N cm3/elego/prjm/AMD64_FREEBSD/Creation.m3 > N cm3/elego/prjm/AMD64_FREEBSD/Creation.mo > N cm3/elego/prjm/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/prjm/AMD64_FREEBSD/.M3SHIP > N cm3/elego/prjm/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManager.mo > N cm3/elego/prjm/AMD64_FREEBSD/.M3WEB > N cm3/elego/prjm/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.mo > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.m3 > N cm3/elego/prjm/AMD64_FREEBSD/Creation.io > N cm3/elego/pkg_vc/PkgTags > N cm3/elego/pkg_vc/TODO > N cm3/elego/pkg_vc/PkgDesc > N cm3/elego/pkg_vc/PkgErr > N cm3/elego/pkg_vc/src/PkgVC.i3 > N cm3/elego/pkg_vc/src/CVS.i3 > N cm3/elego/pkg_vc/src/FileRevision.i3 > N cm3/elego/pkg_vc/src/m3overrides > N cm3/elego/pkg_vc/src/FileObj.i3 > N cm3/elego/pkg_vc/src/ProcessPosixOS2.m3 > N cm3/elego/pkg_vc/src/PkgVCUtils.m3 > N cm3/elego/pkg_vc/src/VCIF.i3 > N cm3/elego/pkg_vc/src/OpResultCache.m3 > N cm3/elego/pkg_vc/src/VCUtils.i3 > N cm3/elego/pkg_vc/src/gnats-commit-check.sh > N cm3/elego/pkg_vc/src/Process2.i3 > N cm3/elego/pkg_vc/src/PkgVCUtils.i3 > N cm3/elego/pkg_vc/src/m3makefile > N cm3/elego/pkg_vc/src/FileObj.m3 > N cm3/elego/pkg_vc/src/PkgVC.m3 > N cm3/elego/pkg_vc/src/VCUtils.m3 > N cm3/elego/pkg_vc/src/CVS_st.m3 > N cm3/elego/pkg_vc/src/CVSLockInfo.i3 > N cm3/elego/pkg_vc/src/OpResultCache.i3 > N cm3/elego/pkg_vc/tests/src/m3overrides > N cm3/elego/pkg_vc/tests/src/Main.m3 > N cm3/elego/pkg_vc/tests/src/m3makefile > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.m3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/VCIF.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.m3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS_st.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.so.5 > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfo.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.m3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.m3x > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevision.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS.io > N cm3/elego/m3ovr/PkgTags > N cm3/elego/m3ovr/PkgErr > N cm3/elego/m3ovr/src/m3overrides > N cm3/elego/m3ovr/src/Main.m3 > N cm3/elego/m3ovr/src/m3makefile > N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr.mx > N cm3/elego/m3ovr/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3ovr/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3ovr/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3ovr/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.io > N cm3/elego/m3ovr/AMD64_FREEBSD/Main.mo > N cm3/elego/compact-client/PkgTags > N cm3/elego/compact-client/PkgErr > N cm3/elego/compact-client/src/m3overrides > N cm3/elego/compact-client/src/CompactClient.m3 > N cm3/elego/compact-client/src/m3makefile > N cm3/elego/compact-client/src/CompactClient.i3 > N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.so.5 > N cm3/elego/compact-client/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/compact-client/AMD64_FREEBSD/.M3SHIP > N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.mo > N cm3/elego/compact-client/AMD64_FREEBSD/.M3WEB > N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.m3x > N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.io > N cm3/elego/fileinfo/PkgTags > N cm3/elego/fileinfo/PkgErr > N cm3/elego/fileinfo/src/FileDir.m3 > N cm3/elego/fileinfo/src/FileStatus.i3 > N cm3/elego/fileinfo/src/DirTree.m3 > N cm3/elego/fileinfo/src/Dummy.i3 > N cm3/elego/fileinfo/src/FileStamp.i3 > N cm3/elego/fileinfo/src/m3overrides > N cm3/elego/fileinfo/src/DirTree.i3 > N cm3/elego/fileinfo/src/APN.i3 > N cm3/elego/fileinfo/src/FileDir.i3 > N cm3/elego/fileinfo/src/FileInfo.i3 > N cm3/elego/fileinfo/src/PathnameStatusTable.i3 > N cm3/elego/fileinfo/src/FileStatus.m3 > N cm3/elego/fileinfo/src/m3makefile > N cm3/elego/fileinfo/src/Dummy.m3 > N cm3/elego/fileinfo/src/FileSystem.m3 > N cm3/elego/fileinfo/src/FileSystem.i3 > N cm3/elego/fileinfo/src/PathnameStatusTable.m3 > N cm3/elego/fileinfo/src/FileInfo.m3 > N cm3/elego/fileinfo/src/APN.m3 > N cm3/elego/fileinfo/src/TreeStamp.i3 > N cm3/elego/fileinfo/src/FileStamp.m3 > N cm3/elego/fileinfo/tests/PkgTags > N cm3/elego/fileinfo/tests/src/m3overrides > N cm3/elego/fileinfo/tests/src/Main.m3 > N cm3/elego/fileinfo/tests/src/m3makefile > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.io > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.m3x > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.so.5 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APN.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.io > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/.M3SHIP > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APN.io > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/.M3WEB > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.io > N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.io > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.io > N cm3/elego/pkgvm/PkgTags > N cm3/elego/pkgvm/PkgErr > N cm3/elego/pkgvm/src/m3overrides > N cm3/elego/pkgvm/src/Main.m3 > N cm3/elego/pkgvm/src/pkgvm.desc > N cm3/elego/pkgvm/src/m3makefile > N cm3/elego/pkgvm/src/pkgvm.help > N cm3/elego/pkgvm/src/compactrc > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.i3 > N cm3/elego/pkgvm/AMD64_FREEBSD/_m3main.mc > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.i3 > N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm.mx > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.m3 > N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.io > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.m3 > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.mo > N cm3/elego/pkgvm/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkgvm/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/pkgvm/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.io > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.mo > N cm3/elego/pkgvm/AMD64_FREEBSD/Main.mo > N cm3/elego/graphicutils/PkgTags > N cm3/elego/graphicutils/PkgErr > N cm3/elego/graphicutils/src/RsrcUtils.i3 > N cm3/elego/graphicutils/src/m3overrides > N cm3/elego/graphicutils/src/RsrcUtils.m3 > N cm3/elego/graphicutils/src/RsrcFilter.m3 > N cm3/elego/graphicutils/src/StdFontsX.m3 > N cm3/elego/graphicutils/src/StdFonts.m3 > N cm3/elego/graphicutils/src/m3makefile > N cm3/elego/graphicutils/src/RsrcFilter.i3 > N cm3/elego/graphicutils/src/StdFontsWin32.m3 > N cm3/elego/graphicutils/src/StdFonts.i3 > N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.m3x > N cm3/elego/graphicutils/AMD64_FREEBSD/StdFonts.io > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.mo > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.mo > N cm3/elego/graphicutils/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/graphicutils/AMD64_FREEBSD/StdFontsX.mo > N cm3/elego/graphicutils/AMD64_FREEBSD/.M3SHIP > N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.so.5 > N cm3/elego/graphicutils/AMD64_FREEBSD/.M3WEB > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.io > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.io > N cm3/elego/m3dep/PkgTags > N cm3/elego/m3dep/PkgErr > N cm3/elego/m3dep/src/m3overrides > N cm3/elego/m3dep/src/Main.m3 > N cm3/elego/m3dep/src/m3makefile > N cm3/elego/m3dep/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3dep/AMD64_FREEBSD/m3dep > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3dep/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3dep/AMD64_FREEBSD/m3dep.mx > N cm3/elego/m3dep/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3dep/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.io > N cm3/elego/m3dep/AMD64_FREEBSD/Main.mo > N cm3/elego/pkgversions/PkgTags > N cm3/elego/pkgversions/PkgErr > N cm3/elego/pkgversions/src/TagSort.m3 > N cm3/elego/pkgversions/src/Version.m3 > N cm3/elego/pkgversions/src/m3overrides > N cm3/elego/pkgversions/src/TagSort.i3 > N cm3/elego/pkgversions/src/Version.i3 > N cm3/elego/pkgversions/src/m3makefile > N cm3/elego/pkgversions/src/Tag.m3 > N cm3/elego/pkgversions/src/Tag.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/Version.io > N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.m3 > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.io > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.m3x > N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.so.5 > N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.io > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.io > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.io > N cm3/elego/pkgversions/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkgversions/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.io > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.io > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.m3 > N cm3/elego/pkgversions/AMD64_FREEBSD/Version.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.i3 > N cm3/elego/m3makefile/PkgTags > N cm3/elego/m3makefile/PkgErr > N cm3/elego/m3makefile/src/m3overrides > N cm3/elego/m3makefile/src/QCompiler.i3 > N cm3/elego/m3makefile/src/QCompiler.m3 > N cm3/elego/m3makefile/src/m3makefile > N cm3/elego/m3makefile/src/M3makefile.m3 > N cm3/elego/m3makefile/src/M3makefile.i3 > N cm3/elego/m3makefile/test/src/Main.m3 > N cm3/elego/m3makefile/test/src/m3makefile > N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.m3x > N cm3/elego/m3makefile/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.mo > N cm3/elego/m3makefile/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.so.5 > N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.io > N cm3/elego/m3makefile/AMD64_FREEBSD/.M3WEB > N cm3/elego/rsrcservice/PkgTags > N cm3/elego/rsrcservice/PkgErr > N cm3/elego/rsrcservice/src/RsrcService.i3 > N cm3/elego/rsrcservice/src/m3overrides > N cm3/elego/rsrcservice/src/m3makefile > N cm3/elego/rsrcservice/src/ConfigRsrcService.m3 > N cm3/elego/rsrcservice/src/ConfigRsrcService.i3 > N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.mo > N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.so.5 > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.mo > N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.io > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.io > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3IMPTAB > N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.m3x > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3SHIP > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService.io > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3WEB > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.m3 > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.i3 > N cm3/elego/pkg_base/PkgTags > N cm3/elego/pkg_base/TODO > N cm3/elego/pkg_base/PkgDesc > N cm3/elego/pkg_base/PkgErr > N cm3/elego/pkg_base/src/m3overrides > N cm3/elego/pkg_base/src/PkgKindData.i3 > N cm3/elego/pkg_base/src/PkgBase.DefaultData > N cm3/elego/pkg_base/src/PkgBase.i3 > N cm3/elego/pkg_base/src/m3makefile > N cm3/elego/pkg_base/src/PkgKindData.m3 > N cm3/elego/pkg_base/src/PkgBase.m3 > N cm3/elego/pkg_base/src/PkgError.i3 > N cm3/elego/pkg_base/test0/src/Main.m3 > N cm3/elego/pkg_base/test0/src/kinds > N cm3/elego/pkg_base/test0/src/m3makefile > N cm3/elego/pkg_base/test0/src/dummy/bla > N cm3/elego/pkg_base/test0/src/dummy/dummy-a/hugo > N cm3/elego/pkg_base/test0/src/dummy/dummy-a/susi > N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.m3x > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.i3 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.i3 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgError.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.m3 > N cm3/elego/pkg_base/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkg_base/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.m3 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.so.5 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.io > N cm3/elego/fsfind/PkgTags > N cm3/elego/fsfind/PkgErr > N cm3/elego/fsfind/src/FSFind.i3 > N cm3/elego/fsfind/src/m3overrides > N cm3/elego/fsfind/src/FileClassification.m3 > N cm3/elego/fsfind/src/FindExecRec.m3 > N cm3/elego/fsfind/src/FindExpr.i3 > N cm3/elego/fsfind/src/FSFind.m3 > N cm3/elego/fsfind/src/FindExecRec.i3 > N cm3/elego/fsfind/src/FileClassification.i3 > N cm3/elego/fsfind/src/FindExpr.m3 > N cm3/elego/fsfind/src/FSFindError.i3 > N cm3/elego/fsfind/src/m3makefile > N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.m3 > N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FSFindError.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.i3 > N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.m3x > N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.io > N cm3/elego/fsfind/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/fsfind/AMD64_FREEBSD/.M3SHIP > N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.io > N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.so.5 > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.mo > N cm3/elego/fsfind/AMD64_FREEBSD/.M3WEB > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.i3 > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.io > N cm3/elego/m3msh/PkgTags > N cm3/elego/m3msh/PkgErr > N cm3/elego/m3msh/src/m3overrides > N cm3/elego/m3msh/src/m3msh.desc > N cm3/elego/m3msh/src/m3makefile > N cm3/elego/m3msh/src/m3msh.help > N cm3/elego/m3msh/src/M3MiniShell.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.mo > N cm3/elego/m3msh/AMD64_FREEBSD/m3msh.mx > N cm3/elego/m3msh/AMD64_FREEBSD/M3MiniShell.mo > N cm3/elego/m3msh/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.io > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3msh/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3msh/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/m3msh > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.i3 > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.io > N cm3/elego/m3dir/PkgTags > N cm3/elego/m3dir/PkgErr > N cm3/elego/m3dir/src/m3overrides > N cm3/elego/m3dir/src/M3Dir.m3 > N cm3/elego/m3dir/src/m3makefile > N cm3/elego/m3dir/AMD64_FREEBSD/m3dir.mx > N cm3/elego/m3dir/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3dir/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3dir/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3dir/AMD64_FREEBSD/M3Dir.mo > N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3dir/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.io > N cm3/elego/m3dir/AMD64_FREEBSD/m3dir > N cm3/elego/miniscan/PkgTags > N cm3/elego/miniscan/PkgErr > N cm3/elego/miniscan/src/m3overrides > N cm3/elego/miniscan/src/ScanToken.i3 > N cm3/elego/miniscan/src/m3makefile > N cm3/elego/miniscan/src/SimpleScanner.i3 > N cm3/elego/miniscan/src/SimpleScanner.m3 > N cm3/elego/miniscan/src/ScanToken.m3 > N cm3/elego/miniscan/test/src/m3overrides > N cm3/elego/miniscan/test/src/Main.m3 > N cm3/elego/miniscan/test/src/m3makefile > N cm3/elego/miniscan/test/src/otto > N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.io > N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.mo > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.io > N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.mo > N cm3/elego/miniscan/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/miniscan/AMD64_FREEBSD/.M3SHIP > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.i3 > N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.io > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.io > N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.so.5 > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.i3 > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.m3 > N cm3/elego/miniscan/AMD64_FREEBSD/.M3WEB > N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.m3x > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.mo > N cm3/elego/compactrc/PkgTags > N cm3/elego/compactrc/PkgErr > N cm3/elego/compactrc/src/m3overrides > N cm3/elego/compactrc/src/CompactRC.m3 > N cm3/elego/compactrc/src/CompactRC.i3 > N cm3/elego/compactrc/src/compactrc.README > N cm3/elego/compactrc/src/MiniEnv.i3 > N cm3/elego/compactrc/src/compactrc.default > N cm3/elego/compactrc/src/m3makefile > N cm3/elego/compactrc/src/CompactEnvName.i3 > N cm3/elego/compactrc/src/MiniEnv.m3 > N cm3/elego/compactrc/src/compactrc.cd > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.mo > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.io > N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.io > N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.io > N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.so.5 > N cm3/elego/compactrc/AMD64_FREEBSD/CompactEnvName.io > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.m3 > N cm3/elego/compactrc/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/compactrc/AMD64_FREEBSD/.M3SHIP > N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.m3x > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.i3 > N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.mo > N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.mo > N cm3/elego/compactrc/AMD64_FREEBSD/.M3WEB > N cm3/elego/depgraph/PkgTags > N cm3/elego/depgraph/PkgErr > N cm3/elego/depgraph/src/StdDepGraph.m3 > N cm3/elego/depgraph/src/DependencyGraph.i3 > N cm3/elego/depgraph/src/StdDepGraphNode.m3 > N cm3/elego/depgraph/src/m3overrides > N cm3/elego/depgraph/src/StdDepGraph.i3 > N cm3/elego/depgraph/src/StdDepGraphEdge.i3 > N cm3/elego/depgraph/src/DependencyGraph.m3 > N cm3/elego/depgraph/src/m3makefile > N cm3/elego/depgraph/src/StdDepGraphNode.i3 > N cm3/elego/depgraph/src/StdDepGraphEdge.m3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.mo > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.mo > N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.m3x > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.m3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.mo > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.m3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.i3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.io > N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.so.5 > N cm3/elego/depgraph/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/depgraph/AMD64_FREEBSD/.M3SHIP > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.mo > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.i3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.io > N cm3/elego/depgraph/AMD64_FREEBSD/.M3WEB > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.mo > N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.mo > N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.i3 > > No conflicts created by this import > From wagner at elegosoft.com Sat Aug 7 22:16:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 07 Aug 2010 22:16:39 +0200 Subject: [M3devel] elego compact In-Reply-To: References: <20100807161924.5CA4924740DC@birch.elegosoft.com> Message-ID: <20100807221639.cfa70r5ttwgos040@mail.elegosoft.com> Quoting Jay K : > Cool. Notice the derived files (directory AMD64_FREEBSD) got imported. Yes. But I immediately removed them again on birch. Stupid pilot error :-/ Actually this project was lying around here for about two years now... I thought today would be a good day to finish it :-) It took me most of the day to make everything compile again (several LONGINT changes, M3Config gone etc.). Olaf > - Jay > > ---------------------------------------- >> Date: Sat, 7 Aug 2010 18:19:23 +0000 >> To: m3commit at elegosoft.com >> From: wagner at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: wagner at birch. 10/08/07 18:19:23 >> >> cm3/elego >> >> Update of /usr/cvs/cm3/elego >> In directory birch:/tmp/cvs-serv13035 >> >> Log Message: >> Stripped-down version of Elego ComPact; software developed and used >> at Elego years ago. I put it under the same copyright as the other >> Modula-3 sources from DEC and Critical Mass. >> >> Included is package version management based on CVS and build and >> version management for sets of packages, called `project management' >> in ComPact. >> >> Not included is the general package manager for C/C++/Java/M3, and the >> ComPact GUI. >> >> It is contributed in the hope that it may be useful in whole or parts >> for the CM3 project or any other users. >> >> The command line interface consists of the programs pkgvm and prjm, >> which include complete manuals as well as short usage help: >> >> pkgvm -help | -man >> prjm -help | -man >> >> The sources have been successfully compiled with a current cm3 (d5.9.0) >> by prjm with >> >> prjm -D ROOT=$HOME/work/cm3 -buildglobal >> >> The project definition is contained in the file elego/PrjDesc. >> >> To compile everything with the CM3 srcipts, use >> >> ~/work/cm3/scripts/do-pkg.sh buildship langutils graphicutils tuple >> depgraph miniscan fsfind fileinfo filepool pkgversions >> compact-copyright rsrcservice compact-client compactrc pkg_base >> pkg_vc m3makefile m3dep m3dir m3err m3msh m3ovr pkgvm prjbase prjm >> >> Several things may still be wrong and need to be adapted for use with >> the current CM3, but the ComPact tools should be quite flexible and >> configurable. >> >> As all free software, this comes without any guarantee that it will >> be useful in any way. Use at your own risk. >> >> Olaf Wagner / Elego Software Solutions GmbH, Berlin, Germany, 2010-08-07 >> >> >> Status: >> >> Vendor Tag: elego-compact-free-1-0 >> Release Tags: rel-compact-free-1-0 >> >> N cm3/elego/DepGraph >> N cm3/elego/quake.elego >> N cm3/elego/PrjDesc >> N cm3/elego/srcs >> N cm3/elego/compact-copyright/PkgTags >> N cm3/elego/compact-copyright/PkgErr >> N cm3/elego/compact-copyright/src/Copyright.m3 >> N cm3/elego/compact-copyright/src/Release.m3 >> N cm3/elego/compact-copyright/src/m3overrides >> N cm3/elego/compact-copyright/src/ProgramVersion.i3 >> N cm3/elego/compact-copyright/src/Version.i3 >> N cm3/elego/compact-copyright/src/Release.i3 >> N cm3/elego/compact-copyright/src/compact-copyrights.txt >> N cm3/elego/compact-copyright/src/m3makefile >> N cm3/elego/compact-copyright/src/Copyright.i3 >> N cm3/elego/compact-copyright/src/ProgramVersion.m3 >> N cm3/elego/compact-copyright/src/get-licences >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.io >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.io >> N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.so.5 >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.i3 >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.io >> N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.mo >> N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.m3x >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.m3 >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.mo >> N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3WEB >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.mo >> N cm3/elego/filepool/PkgTags >> N cm3/elego/filepool/PkgErr >> N cm3/elego/filepool/src/m3overrides >> N cm3/elego/filepool/src/FilePool.m3 >> N cm3/elego/filepool/src/m3makefile >> N cm3/elego/filepool/src/FilePool.i3 >> N cm3/elego/filepool/test/src/Main.m3 >> N cm3/elego/filepool/test/src/m3makefile >> N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.so.5 >> N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.m3x >> N cm3/elego/filepool/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/filepool/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/filepool/AMD64_FREEBSD/FilePool.io >> N cm3/elego/filepool/AMD64_FREEBSD/.M3WEB >> N cm3/elego/filepool/AMD64_FREEBSD/FilePool.mo >> N cm3/elego/m3err/PkgTags >> N cm3/elego/m3err/m3err.gmon >> N cm3/elego/m3err/PkgErr >> N cm3/elego/m3err/src/m3overrides >> N cm3/elego/m3err/src/m3err.m3 >> N cm3/elego/m3err/src/m3makefile >> N cm3/elego/m3err/AMD64_FREEBSD/m3err >> N cm3/elego/m3err/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3err/AMD64_FREEBSD/m3err.mo >> N cm3/elego/m3err/AMD64_FREEBSD/m3err.mx >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3err/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3err/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3err/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3err/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3err/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.io >> N cm3/elego/prjbase/PkgTags >> N cm3/elego/prjbase/PkgErr >> N cm3/elego/prjbase/snaps/snaps.idx >> N cm3/elego/prjbase/src/PrjDesc.i3 >> N cm3/elego/prjbase/src/ChangeSet.i3 >> N cm3/elego/prjbase/src/Checkpoint.i3 >> N cm3/elego/prjbase/src/PrjDesc.m3 >> N cm3/elego/prjbase/src/Snapshots.i3 >> N cm3/elego/prjbase/src/Snapshots.m3 >> N cm3/elego/prjbase/src/ChangeSet.m3 >> N cm3/elego/prjbase/src/m3overrides >> N cm3/elego/prjbase/src/RCS_Date.i3 >> N cm3/elego/prjbase/src/PoolSet.i3 >> N cm3/elego/prjbase/src/RCS_Date.m3 >> N cm3/elego/prjbase/src/PoolSet.m3 >> N cm3/elego/prjbase/src/Checkpoint.m3 >> N cm3/elego/prjbase/src/rcsdate.patch >> N cm3/elego/prjbase/src/m3makefile >> N cm3/elego/prjbase/src/m3browser.html >> N cm3/elego/prjbase/test/src/PrjDesc1 >> N cm3/elego/prjbase/test/src/PrjDesc2 >> N cm3/elego/prjbase/test/src/Main.m3 >> N cm3/elego/prjbase/test/src/m3makefile >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.io >> N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.io >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.m3x >> N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.io >> N cm3/elego/prjbase/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.so.5 >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/.M3WEB >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.io >> N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.i3 >> N cm3/elego/tuple/PkgTags >> N cm3/elego/tuple/PkgErr >> N cm3/elego/tuple/src/TextTuple.m3 >> N cm3/elego/tuple/src/TextTuple.i3 >> N cm3/elego/tuple/src/Dummy.i3 >> N cm3/elego/tuple/src/m3overrides >> N cm3/elego/tuple/src/Tuple.mg >> N cm3/elego/tuple/src/Tuple.ig >> N cm3/elego/tuple/src/m3makefile >> N cm3/elego/tuple/src/Dummy.m3 >> N cm3/elego/tuple/src/HeteroTuple.mg >> N cm3/elego/tuple/src/HeteroTuple.ig >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.i3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.io >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.io >> N cm3/elego/tuple/AMD64_FREEBSD/libtuple.so.5 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.i3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.io >> N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.mo >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.mo >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.i3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.mo >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.io >> N cm3/elego/tuple/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/tuple/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.io >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.m3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.m3 >> N cm3/elego/tuple/AMD64_FREEBSD/.M3WEB >> N cm3/elego/tuple/AMD64_FREEBSD/libtuple.m3x >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.i3 >> N cm3/elego/langutils/PkgTags >> N cm3/elego/langutils/PkgErr >> N cm3/elego/langutils/src/m3overrides >> N cm3/elego/langutils/src/SimpleValueEnv.m3 >> N cm3/elego/langutils/src/SimpleValueEnv.i3 >> N cm3/elego/langutils/src/m3makefile >> N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.m3x >> N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.mo >> N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.so.5 >> N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.io >> N cm3/elego/langutils/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/langutils/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/langutils/AMD64_FREEBSD/.M3WEB >> N cm3/elego/prjm/PkgTags >> N cm3/elego/prjm/PrjDesc >> N cm3/elego/prjm/stat >> N cm3/elego/prjm/PkgErr >> N cm3/elego/prjm/src/m3overrides >> N cm3/elego/prjm/src/Copyright >> N cm3/elego/prjm/src/PrjmGUI.fv >> N cm3/elego/prjm/src/m3makefile >> N cm3/elego/prjm/src/ProjectManager.m3 >> N cm3/elego/prjm/src/ShortUsageHelp >> N cm3/elego/prjm/src/UsageHelp >> N cm3/elego/prjm/src/compactrc >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.io >> N cm3/elego/prjm/AMD64_FREEBSD/prjm.mx >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.i3 >> N cm3/elego/prjm/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/prjm/AMD64_FREEBSD/prjm >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.mo >> N cm3/elego/prjm/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/prjm/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/prjm/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManager.mo >> N cm3/elego/prjm/AMD64_FREEBSD/.M3WEB >> N cm3/elego/prjm/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.mo >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.m3 >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.io >> N cm3/elego/pkg_vc/PkgTags >> N cm3/elego/pkg_vc/TODO >> N cm3/elego/pkg_vc/PkgDesc >> N cm3/elego/pkg_vc/PkgErr >> N cm3/elego/pkg_vc/src/PkgVC.i3 >> N cm3/elego/pkg_vc/src/CVS.i3 >> N cm3/elego/pkg_vc/src/FileRevision.i3 >> N cm3/elego/pkg_vc/src/m3overrides >> N cm3/elego/pkg_vc/src/FileObj.i3 >> N cm3/elego/pkg_vc/src/ProcessPosixOS2.m3 >> N cm3/elego/pkg_vc/src/PkgVCUtils.m3 >> N cm3/elego/pkg_vc/src/VCIF.i3 >> N cm3/elego/pkg_vc/src/OpResultCache.m3 >> N cm3/elego/pkg_vc/src/VCUtils.i3 >> N cm3/elego/pkg_vc/src/gnats-commit-check.sh >> N cm3/elego/pkg_vc/src/Process2.i3 >> N cm3/elego/pkg_vc/src/PkgVCUtils.i3 >> N cm3/elego/pkg_vc/src/m3makefile >> N cm3/elego/pkg_vc/src/FileObj.m3 >> N cm3/elego/pkg_vc/src/PkgVC.m3 >> N cm3/elego/pkg_vc/src/VCUtils.m3 >> N cm3/elego/pkg_vc/src/CVS_st.m3 >> N cm3/elego/pkg_vc/src/CVSLockInfo.i3 >> N cm3/elego/pkg_vc/src/OpResultCache.i3 >> N cm3/elego/pkg_vc/tests/src/m3overrides >> N cm3/elego/pkg_vc/tests/src/Main.m3 >> N cm3/elego/pkg_vc/tests/src/m3makefile >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.m3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/VCIF.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.m3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS_st.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.so.5 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfo.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.m3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.m3x >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevision.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS.io >> N cm3/elego/m3ovr/PkgTags >> N cm3/elego/m3ovr/PkgErr >> N cm3/elego/m3ovr/src/m3overrides >> N cm3/elego/m3ovr/src/Main.m3 >> N cm3/elego/m3ovr/src/m3makefile >> N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr.mx >> N cm3/elego/m3ovr/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3ovr/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3ovr/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3ovr/AMD64_FREEBSD/Main.mo >> N cm3/elego/compact-client/PkgTags >> N cm3/elego/compact-client/PkgErr >> N cm3/elego/compact-client/src/m3overrides >> N cm3/elego/compact-client/src/CompactClient.m3 >> N cm3/elego/compact-client/src/m3makefile >> N cm3/elego/compact-client/src/CompactClient.i3 >> N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.so.5 >> N cm3/elego/compact-client/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/compact-client/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.mo >> N cm3/elego/compact-client/AMD64_FREEBSD/.M3WEB >> N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.m3x >> N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.io >> N cm3/elego/fileinfo/PkgTags >> N cm3/elego/fileinfo/PkgErr >> N cm3/elego/fileinfo/src/FileDir.m3 >> N cm3/elego/fileinfo/src/FileStatus.i3 >> N cm3/elego/fileinfo/src/DirTree.m3 >> N cm3/elego/fileinfo/src/Dummy.i3 >> N cm3/elego/fileinfo/src/FileStamp.i3 >> N cm3/elego/fileinfo/src/m3overrides >> N cm3/elego/fileinfo/src/DirTree.i3 >> N cm3/elego/fileinfo/src/APN.i3 >> N cm3/elego/fileinfo/src/FileDir.i3 >> N cm3/elego/fileinfo/src/FileInfo.i3 >> N cm3/elego/fileinfo/src/PathnameStatusTable.i3 >> N cm3/elego/fileinfo/src/FileStatus.m3 >> N cm3/elego/fileinfo/src/m3makefile >> N cm3/elego/fileinfo/src/Dummy.m3 >> N cm3/elego/fileinfo/src/FileSystem.m3 >> N cm3/elego/fileinfo/src/FileSystem.i3 >> N cm3/elego/fileinfo/src/PathnameStatusTable.m3 >> N cm3/elego/fileinfo/src/FileInfo.m3 >> N cm3/elego/fileinfo/src/APN.m3 >> N cm3/elego/fileinfo/src/TreeStamp.i3 >> N cm3/elego/fileinfo/src/FileStamp.m3 >> N cm3/elego/fileinfo/tests/PkgTags >> N cm3/elego/fileinfo/tests/src/m3overrides >> N cm3/elego/fileinfo/tests/src/Main.m3 >> N cm3/elego/fileinfo/tests/src/m3makefile >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.m3x >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.so.5 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APN.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APN.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/.M3WEB >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.io >> N cm3/elego/pkgvm/PkgTags >> N cm3/elego/pkgvm/PkgErr >> N cm3/elego/pkgvm/src/m3overrides >> N cm3/elego/pkgvm/src/Main.m3 >> N cm3/elego/pkgvm/src/pkgvm.desc >> N cm3/elego/pkgvm/src/m3makefile >> N cm3/elego/pkgvm/src/pkgvm.help >> N cm3/elego/pkgvm/src/compactrc >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.i3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm.mx >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.io >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.m3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.mo >> N cm3/elego/pkgvm/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkgvm/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.io >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.mo >> N cm3/elego/pkgvm/AMD64_FREEBSD/Main.mo >> N cm3/elego/graphicutils/PkgTags >> N cm3/elego/graphicutils/PkgErr >> N cm3/elego/graphicutils/src/RsrcUtils.i3 >> N cm3/elego/graphicutils/src/m3overrides >> N cm3/elego/graphicutils/src/RsrcUtils.m3 >> N cm3/elego/graphicutils/src/RsrcFilter.m3 >> N cm3/elego/graphicutils/src/StdFontsX.m3 >> N cm3/elego/graphicutils/src/StdFonts.m3 >> N cm3/elego/graphicutils/src/m3makefile >> N cm3/elego/graphicutils/src/RsrcFilter.i3 >> N cm3/elego/graphicutils/src/StdFontsWin32.m3 >> N cm3/elego/graphicutils/src/StdFonts.i3 >> N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.m3x >> N cm3/elego/graphicutils/AMD64_FREEBSD/StdFonts.io >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.mo >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.mo >> N cm3/elego/graphicutils/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/graphicutils/AMD64_FREEBSD/StdFontsX.mo >> N cm3/elego/graphicutils/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.so.5 >> N cm3/elego/graphicutils/AMD64_FREEBSD/.M3WEB >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.io >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.io >> N cm3/elego/m3dep/PkgTags >> N cm3/elego/m3dep/PkgErr >> N cm3/elego/m3dep/src/m3overrides >> N cm3/elego/m3dep/src/Main.m3 >> N cm3/elego/m3dep/src/m3makefile >> N cm3/elego/m3dep/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3dep/AMD64_FREEBSD/m3dep >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3dep/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3dep/AMD64_FREEBSD/m3dep.mx >> N cm3/elego/m3dep/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3dep/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3dep/AMD64_FREEBSD/Main.mo >> N cm3/elego/pkgversions/PkgTags >> N cm3/elego/pkgversions/PkgErr >> N cm3/elego/pkgversions/src/TagSort.m3 >> N cm3/elego/pkgversions/src/Version.m3 >> N cm3/elego/pkgversions/src/m3overrides >> N cm3/elego/pkgversions/src/TagSort.i3 >> N cm3/elego/pkgversions/src/Version.i3 >> N cm3/elego/pkgversions/src/m3makefile >> N cm3/elego/pkgversions/src/Tag.m3 >> N cm3/elego/pkgversions/src/Tag.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/Version.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.m3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.m3x >> N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.so.5 >> N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkgversions/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.m3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/Version.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.i3 >> N cm3/elego/m3makefile/PkgTags >> N cm3/elego/m3makefile/PkgErr >> N cm3/elego/m3makefile/src/m3overrides >> N cm3/elego/m3makefile/src/QCompiler.i3 >> N cm3/elego/m3makefile/src/QCompiler.m3 >> N cm3/elego/m3makefile/src/m3makefile >> N cm3/elego/m3makefile/src/M3makefile.m3 >> N cm3/elego/m3makefile/src/M3makefile.i3 >> N cm3/elego/m3makefile/test/src/Main.m3 >> N cm3/elego/m3makefile/test/src/m3makefile >> N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.m3x >> N cm3/elego/m3makefile/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.mo >> N cm3/elego/m3makefile/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.so.5 >> N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.io >> N cm3/elego/m3makefile/AMD64_FREEBSD/.M3WEB >> N cm3/elego/rsrcservice/PkgTags >> N cm3/elego/rsrcservice/PkgErr >> N cm3/elego/rsrcservice/src/RsrcService.i3 >> N cm3/elego/rsrcservice/src/m3overrides >> N cm3/elego/rsrcservice/src/m3makefile >> N cm3/elego/rsrcservice/src/ConfigRsrcService.m3 >> N cm3/elego/rsrcservice/src/ConfigRsrcService.i3 >> N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.mo >> N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.so.5 >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.mo >> N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.io >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.io >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3IMPTAB >> N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.m3x >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService.io >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3WEB >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.m3 >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.i3 >> N cm3/elego/pkg_base/PkgTags >> N cm3/elego/pkg_base/TODO >> N cm3/elego/pkg_base/PkgDesc >> N cm3/elego/pkg_base/PkgErr >> N cm3/elego/pkg_base/src/m3overrides >> N cm3/elego/pkg_base/src/PkgKindData.i3 >> N cm3/elego/pkg_base/src/PkgBase.DefaultData >> N cm3/elego/pkg_base/src/PkgBase.i3 >> N cm3/elego/pkg_base/src/m3makefile >> N cm3/elego/pkg_base/src/PkgKindData.m3 >> N cm3/elego/pkg_base/src/PkgBase.m3 >> N cm3/elego/pkg_base/src/PkgError.i3 >> N cm3/elego/pkg_base/test0/src/Main.m3 >> N cm3/elego/pkg_base/test0/src/kinds >> N cm3/elego/pkg_base/test0/src/m3makefile >> N cm3/elego/pkg_base/test0/src/dummy/bla >> N cm3/elego/pkg_base/test0/src/dummy/dummy-a/hugo >> N cm3/elego/pkg_base/test0/src/dummy/dummy-a/susi >> N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.m3x >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.i3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.i3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgError.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.m3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkg_base/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.m3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.so.5 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.io >> N cm3/elego/fsfind/PkgTags >> N cm3/elego/fsfind/PkgErr >> N cm3/elego/fsfind/src/FSFind.i3 >> N cm3/elego/fsfind/src/m3overrides >> N cm3/elego/fsfind/src/FileClassification.m3 >> N cm3/elego/fsfind/src/FindExecRec.m3 >> N cm3/elego/fsfind/src/FindExpr.i3 >> N cm3/elego/fsfind/src/FSFind.m3 >> N cm3/elego/fsfind/src/FindExecRec.i3 >> N cm3/elego/fsfind/src/FileClassification.i3 >> N cm3/elego/fsfind/src/FindExpr.m3 >> N cm3/elego/fsfind/src/FSFindError.i3 >> N cm3/elego/fsfind/src/m3makefile >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.m3 >> N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FSFindError.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.i3 >> N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.m3x >> N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.io >> N cm3/elego/fsfind/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/fsfind/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.io >> N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.so.5 >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/.M3WEB >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.i3 >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.io >> N cm3/elego/m3msh/PkgTags >> N cm3/elego/m3msh/PkgErr >> N cm3/elego/m3msh/src/m3overrides >> N cm3/elego/m3msh/src/m3msh.desc >> N cm3/elego/m3msh/src/m3makefile >> N cm3/elego/m3msh/src/m3msh.help >> N cm3/elego/m3msh/src/M3MiniShell.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.mo >> N cm3/elego/m3msh/AMD64_FREEBSD/m3msh.mx >> N cm3/elego/m3msh/AMD64_FREEBSD/M3MiniShell.mo >> N cm3/elego/m3msh/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.io >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3msh/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3msh/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/m3msh >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.i3 >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3dir/PkgTags >> N cm3/elego/m3dir/PkgErr >> N cm3/elego/m3dir/src/m3overrides >> N cm3/elego/m3dir/src/M3Dir.m3 >> N cm3/elego/m3dir/src/m3makefile >> N cm3/elego/m3dir/AMD64_FREEBSD/m3dir.mx >> N cm3/elego/m3dir/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3dir/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3dir/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3dir/AMD64_FREEBSD/M3Dir.mo >> N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3dir/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3dir/AMD64_FREEBSD/m3dir >> N cm3/elego/miniscan/PkgTags >> N cm3/elego/miniscan/PkgErr >> N cm3/elego/miniscan/src/m3overrides >> N cm3/elego/miniscan/src/ScanToken.i3 >> N cm3/elego/miniscan/src/m3makefile >> N cm3/elego/miniscan/src/SimpleScanner.i3 >> N cm3/elego/miniscan/src/SimpleScanner.m3 >> N cm3/elego/miniscan/src/ScanToken.m3 >> N cm3/elego/miniscan/test/src/m3overrides >> N cm3/elego/miniscan/test/src/Main.m3 >> N cm3/elego/miniscan/test/src/m3makefile >> N cm3/elego/miniscan/test/src/otto >> N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.io >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.mo >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.io >> N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.mo >> N cm3/elego/miniscan/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/miniscan/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.i3 >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.io >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.io >> N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.so.5 >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.i3 >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.m3 >> N cm3/elego/miniscan/AMD64_FREEBSD/.M3WEB >> N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.m3x >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.mo >> N cm3/elego/compactrc/PkgTags >> N cm3/elego/compactrc/PkgErr >> N cm3/elego/compactrc/src/m3overrides >> N cm3/elego/compactrc/src/CompactRC.m3 >> N cm3/elego/compactrc/src/CompactRC.i3 >> N cm3/elego/compactrc/src/compactrc.README >> N cm3/elego/compactrc/src/MiniEnv.i3 >> N cm3/elego/compactrc/src/compactrc.default >> N cm3/elego/compactrc/src/m3makefile >> N cm3/elego/compactrc/src/CompactEnvName.i3 >> N cm3/elego/compactrc/src/MiniEnv.m3 >> N cm3/elego/compactrc/src/compactrc.cd >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.mo >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.io >> N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.io >> N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.io >> N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.so.5 >> N cm3/elego/compactrc/AMD64_FREEBSD/CompactEnvName.io >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.m3 >> N cm3/elego/compactrc/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/compactrc/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.m3x >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.i3 >> N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.mo >> N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.mo >> N cm3/elego/compactrc/AMD64_FREEBSD/.M3WEB >> N cm3/elego/depgraph/PkgTags >> N cm3/elego/depgraph/PkgErr >> N cm3/elego/depgraph/src/StdDepGraph.m3 >> N cm3/elego/depgraph/src/DependencyGraph.i3 >> N cm3/elego/depgraph/src/StdDepGraphNode.m3 >> N cm3/elego/depgraph/src/m3overrides >> N cm3/elego/depgraph/src/StdDepGraph.i3 >> N cm3/elego/depgraph/src/StdDepGraphEdge.i3 >> N cm3/elego/depgraph/src/DependencyGraph.m3 >> N cm3/elego/depgraph/src/m3makefile >> N cm3/elego/depgraph/src/StdDepGraphNode.i3 >> N cm3/elego/depgraph/src/StdDepGraphEdge.m3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.m3x >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.m3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.m3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.i3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.io >> N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.so.5 >> N cm3/elego/depgraph/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/depgraph/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.i3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.io >> N cm3/elego/depgraph/AMD64_FREEBSD/.M3WEB >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.i3 >> >> No conflicts created by this import >> > -- 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 mika at async.async.caltech.edu Sun Aug 8 00:32:16 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 07 Aug 2010 15:32:16 -0700 Subject: [M3devel] more problems upgrading Message-ID: <20100807223216.78F951A20AD@async.async.caltech.edu> Hello m3devel, I'm running into problems again. Now I'm trying to upgrade CM3 on a FreeBSD 5 machine (248)rover:~/cm3/scripts>uname -a FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #0: Sat May 24 10:13:58 PDT 2008 root at rover:/usr/src/sys/i386/compile/ROVERSMP i386 (250)rover:~/cm3/scripts>cm3 -version Critical Mass Modula-3 version d5.8.1 last updated: 2009-05-16 compiled: 2009-06-16 20:34:18 configuration: /usr/local/cm3/bin/cm3.cfg target: FreeBSD4 upgrade.sh runs for a while then dies at: === package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3 === +++ cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' +++ --- building in FreeBSD4 --- ignoring ../src/m3overrides Fatal Error: duplicate link info: M3Path.i3 *** execution of cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' failed *** The reason I'm doing this, by the way, is that I'm having trouble sharing pickles between an amd64 and i386 system and wanted to ensure I have recent CM3 distributions on both systems before starting to debug the problem. It appears I can write pickles on i386 and read them on amd64 without trouble, but not the other way around (and I am not using any out-of-range values, I don't think). Mika From mika at async.async.caltech.edu Sun Aug 8 01:01:11 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 07 Aug 2010 16:01:11 -0700 Subject: [M3devel] more problems upgrading In-Reply-To: <20100807223216.78F951A20AD@async.async.caltech.edu> References: <20100807223216.78F951A20AD@async.async.caltech.edu> Message-ID: <20100807230111.66FC31A20AF@async.async.caltech.edu> Sorry to spam the list, this was user error. Mika Nystrom writes: >Hello m3devel, > >I'm running into problems again. Now I'm trying to upgrade CM3 on >a FreeBSD 5 machine > >(248)rover:~/cm3/scripts>uname -a >FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #0: Sat May 24 10:13:58 PDT 2008 > root at rover:/usr/src/sys/i386/compile/ROVERSMP i386 >(250)rover:~/cm3/scripts>cm3 -version >Critical Mass Modula-3 version d5.8.1 > last updated: 2009-05-16 > compiled: 2009-06-16 20:34:18 > configuration: /usr/local/cm3/bin/cm3.cfg > target: FreeBSD4 > >upgrade.sh runs for a while then dies at: > >=== package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3 === > +++ cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $R >ARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' +++ >--- building in FreeBSD4 --- > >ignoring ../src/m3overrides > > >Fatal Error: duplicate link info: M3Path.i3 > > *** execution of cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && > cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' failed *** > > >The reason I'm doing this, by the way, is that I'm having trouble >sharing pickles between an amd64 and i386 system and wanted to ensure I >have recent CM3 distributions on both systems before starting to debug >the problem. > >It appears I can write pickles on i386 and read them on amd64 without >trouble, but not the other way around (and I am not using any out-of-range >values, I don't think). > > Mika From jay.krell at cornell.edu Sun Aug 8 01:30:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 23:30:17 +0000 Subject: [M3devel] more problems upgrading In-Reply-To: <20100807230111.66FC31A20AF@async.async.caltech.edu> References: <20100807223216.78F951A20AD@async.async.caltech.edu>, <20100807230111.66FC31A20AF@async.async.caltech.edu> Message-ID: I believe I moved M3Path.*, like from cm3 to m3quake. There is a bug; this requires clean. I don't know if upgrade.sh gets any use these days. I use upgrade.py often. Note that upgrade.py does not rebuild entire system, just compiler. E.g. . /upgrade.py skipgcc && ./do-cm3-all.py skipgcc realclean && ./do-cm3-all.py skipgcc buildship - Jay/phone > To: m3devel at elegosoft.com > Date: Sat, 7 Aug 2010 16:01:11 -0700 > From: mika at async.async.caltech.edu > Subject: Re: [M3devel] more problems upgrading > > Sorry to spam the list, this was user error. > > Mika Nystrom writes: > >Hello m3devel, > > > >I'm running into problems again. Now I'm trying to upgrade CM3 on > >a FreeBSD 5 machine > > > >(248)rover:~/cm3/scripts>uname -a > >FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #0: Sat May 24 10:13:58 PDT 2008 > > root at rover:/usr/src/sys/i386/compile/ROVERSMP i386 > >(250)rover:~/cm3/scripts>cm3 -version > >Critical Mass Modula-3 version d5.8.1 > > last updated: 2009-05-16 > > compiled: 2009-06-16 20:34:18 > > configuration: /usr/local/cm3/bin/cm3.cfg > > target: FreeBSD4 > > > >upgrade.sh runs for a while then dies at: > > > >=== package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3 === > > +++ cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $R > >ARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' +++ > >--- building in FreeBSD4 --- > > > >ignoring ../src/m3overrides > > > > > >Fatal Error: duplicate link info: M3Path.i3 > > > > *** execution of cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && > > cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' failed *** > > > > > >The reason I'm doing this, by the way, is that I'm having trouble > >sharing pickles between an amd64 and i386 system and wanted to ensure I > >have recent CM3 distributions on both systems before starting to debug > >the problem. > > > >It appears I can write pickles on i386 and read them on amd64 without > >trouble, but not the other way around (and I am not using any out-of-range > >values, I don't think). > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 8 01:44:57 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 7 Aug 2010 19:44:57 -0400 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: References: Message-ID: <15EA2A2D-8D4F-4749-9FA1-0C58BC2690FE@cs.purdue.edu> I can add a few Hudson nodes sometime. Both AMD64 Linux and Solaris Sparc. 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 7 Aug 2010, at 10:30, Jay K wrote: > > Hey, I'm hoping we can get more people helping more. > > Coding, features, fixing bugs, etc. > > > However one of the easiest things I'd like to see is a few more Hudson nodes. > > > Is anyone out there running e.g. NetBSD on x86 or AMD64? > They would be the easiest, sort of, to setup. I will help anyone. > Or Solaris on SPARC (replace mine) or x86? (Yes I know about opencsw, but the network > topology is seemingly difficult.) > > > Or heck, Linux or OpenBSD on x86? (replace mine) > > > x86/AMD64 in particular has better availability of Java VMs, which we need. > Or, Linux now has good across the board Java support. > > > And can setup dynamic DNS or has static IP? > > > We could use NT386 but I know the setup might not be so easy. > > > There are other viable machines, e.g. one of the new or old Linux/mips. > Or likely some of the obscure systems like HP-UX, AIX, Irix. > If anyone here is actively running one of these, keeps machine on, speak up. > (At some point, I'd like to have Hudson wake-on-lan the machines, > or have the machines scheduled to wake up daily check for work, and then > back to sleep after completing any queued work; the second option > doesn't require Hudson support.) > > > The machine can be quite low end. > Many of mine are old laptops, or very old either way. > Around $200, years ago. > > > Any other projects in the system people are interested in helping out on, with > time/coding, please speak up if you need help. If you need ideas, or assistance, etc. > > > Thanks, > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Aug 8 04:51:30 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 07 Aug 2010 19:51:30 -0700 Subject: [M3devel] CM3 problems Message-ID: <20100808025130.354B71A20BC@async.async.caltech.edu> With what I found in CVS today, I see the following for a program of mine I'm trying to compile: new source -> compiling Main.m3 "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr 3 warnings encountered ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:225: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:225: error: this is the insn: (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ (set (reg:SI 112) (const_int 0 [0x0])) (set (reg:SI 110) (plus:SI (ashift:SI (reg:SI 112) (const_int 2 [0x2])) (reg:SI 110))) (set (reg:SI 111) (plus:SI (ashift:SI (reg:SI 112) (const_int 2 [0x2])) (reg:SI 111))) (set (mem/s/c:BLK (reg:SI 110) [0 M3_A91vEE_trade+0 S24 A64]) (mem/s/c:BLK (reg:SI 111) [0 M3_A91vEE_trade+0 S24 A32])) (use (reg:SI 112)) ]) 586 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 112) (expr_list:REG_UNUSED (reg:SI 111) (expr_list:REG_UNUSED (reg:SI 110) (nil))))) ../src/Main.m3:225: confused by earlier errors, bailing out m3_backend => 4 m3cc (aka cm3cg) failed compiling: Main.mc compilation failed => not building program "ximport" Fatal Error: package build failed Any hints as to how to deal with this? I have optimization turned off. Mika From jay.krell at cornell.edu Sun Aug 8 05:09:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 8 Aug 2010 03:09:07 +0000 Subject: [M3devel] CM3 problems In-Reply-To: <20100808025130.354B71A20BC@async.async.caltech.edu> References: <20100808025130.354B71A20BC@async.async.caltech.edu> Message-ID: Not very useful of me, but standard questions: Is this your code? Can we see it? Is cm3cg current? Can you try with optimization? ?-O1, -O2, -O3 cheating perhaps to use optimization? ?? They should all generally work..though you should also generally never see such errors.. Tony might ask to see the IR via ? rm -rf FreeBSD4? ? cm3 -keep ? ordinarily the *.mc files are deleted? ? cm3cg -y FreeBSD4/Main.mc?? (it goes to stderr not stdout)? ?or more accurately (at least for other purposes)? ? rm -rf FreeBSD4? ? cm3 -keep -commands? ? find the cm3cg command? ? cd FreBSD4 ? rerun cm3cg command but with -y added? though I probably won't be able to glean anything from it. Is cm3cg 4.3.0 or 4.3.5? I'm curious. I upgraded is recently to 4.3.5. ? I don't know of any problems it fixed or caused. cm3cg -v will tell you. This is FreeBSD5/x86, right? Can you try on any other machines? e.g. your Alpha? eh. that's probably changing too much. x86 is by far the register-poorest. Search the web for this error? Maybe it occurs using C as well with "similar" code? ?- Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Sat, 7 Aug 2010 19:51:30 -0700 > From: mika at async.async.caltech.edu > Subject: [M3devel] CM3 problems > > With what I found in CVS today, I see the following for a program > of mine I'm trying to compile: > > > new source -> compiling Main.m3 > "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr > 3 warnings encountered > ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': > ../src/Main.m3:225: error: unable to find a register to spill in class 'CREG' > ../src/Main.m3:225: error: this is the insn: > (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ > (set (reg:SI 112) > (const_int 0 [0x0])) > (set (reg:SI 110) > (plus:SI (ashift:SI (reg:SI 112) > (const_int 2 [0x2])) > (reg:SI 110))) > (set (reg:SI 111) > (plus:SI (ashift:SI (reg:SI 112) > (const_int 2 [0x2])) > (reg:SI 111))) > (set (mem/s/c:BLK (reg:SI 110) [0 M3_A91vEE_trade+0 S24 A64]) > (mem/s/c:BLK (reg:SI 111) [0 M3_A91vEE_trade+0 S24 A32])) > (use (reg:SI 112)) > ]) 586 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 112) > (expr_list:REG_UNUSED (reg:SI 111) > (expr_list:REG_UNUSED (reg:SI 110) > (nil))))) > ../src/Main.m3:225: confused by earlier errors, bailing out > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: Main.mc > compilation failed => not building program "ximport" > Fatal Error: package build failed > > Any hints as to how to deal with this? I have optimization turned off. > > Mika > > From mika at async.async.caltech.edu Sun Aug 8 16:58:57 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 08 Aug 2010 07:58:57 -0700 Subject: [M3devel] CM3 problems In-Reply-To: References: <20100808025130.354B71A20BC@async.async.caltech.edu> Message-ID: <20100808145857.3D7D41A20AF@async.async.caltech.edu> I ran upgrade.sh before compiling, so everything should be up to date. I'd be happy to give you the code (yes it's mine) but I'm not sure how many libraries it depends on. Same thing happens with optimization (-O2). (133)rover:~/u/calarm/regress/ximport/FreeBSD4>/usr/local/cm3//bin/cm3cg -march=i586 -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m32 -O3 -Wuninitialized -gstabs+ Main.mc -o Main.ms ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:225: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:225: error: this is the insn: (insn:HI 5 4 6 2 ../src/Main.m3:204 (parallel [ (set (reg:SI 0 ax [69]) (const_int 0 [0x0])) (set (reg:SI 5 di [67]) (plus:SI (ashift:SI (reg:SI 0 ax [69]) (const_int 2 [0x2])) (reg:SI 5 di [67]))) (set (reg/f:SI 4 si [68]) (plus:SI (ashift:SI (reg:SI 0 ax [69]) (const_int 2 [0x2])) (reg/f:SI 16 argp))) (set (mem/s/c:BLK (reg:SI 5 di [67]) [0 M3_A91vEE_trade+0 S24 A64]) (mem/s/c:BLK (reg/f:SI 16 argp) [0 M3_A91vEE_trade+0 S24 A32])) (use (reg:SI 0 ax [69])) ]) 586 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [69]) (expr_list:REG_UNUSED (reg/f:SI 4 si [68]) (expr_list:REG_UNUSED (reg:SI 5 di [67]) (nil))))) ../src/Main.m3:225: confused by earlier errors, bailing out I copied the derived directory (after running cm3 -x -keep) to http://rover.gcapltd.com/~mika/ximport-bug-FreeBSD4/ in case anyone wants to peek at it. I also put Main.m3 in there so you can see what's going on. Nested procedures... but nothing that looks too weird to me. Mika Jay K writes: > >Not very useful of me=2C but standard questions: > > >Is this your code? >Can we see it? >Is cm3cg current? >Can you try with optimization? >=A0-O1=2C -O2=2C -O3 cheating perhaps to use optimization=A0=20 >=A0=A0 They should all generally work..though you should also generally nev= >er see such errors.. >Tony might ask to see the IR via=20 >=A0 rm -rf FreeBSD4=A0=20 >=A0 cm3 -keep =A0 ordinarily the *.mc files are deleted=A0=20 >=A0 cm3cg -y FreeBSD4/Main.mc=A0=A0 (it goes to stderr not stdout)=A0=20 >=A0or more accurately (at least for other purposes)=A0=20 >=A0 rm -rf FreeBSD4=A0=20 > >=A0 cm3 -keep -commands=A0=20 >=A0 find the cm3cg command=A0=20 >=A0 cd FreBSD4=20 >=A0 rerun cm3cg command but with -y added=A0=20 From wagner at elegosoft.com Mon Aug 9 10:21:36 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 10:21:36 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Message-ID: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> After several weeks (months?) of little activity I was able to setup some more build and regression test jobs on the opencsw.org machines. There are now sets of jobs for SOLsun built on Solaris 10 (works) run on current10s.opencsw.org SOLsun built on Solaris 9 (seems now to work, too) run on current9s I386_SOLARIS built on Solaris 10 (still several problems) run on current10x For the instruction and exhilaration of those willing to read on I'll give some details. One of the problems was entirely my own fault. In the regression defs.sh script, about a dozen error messages were written to 1>2 instead of 1>&2. The second correct form redirects stdout to stderr, while the first just writes the contents to a file named 2 :-/ It's not that I haven't got enough experience with writing shell scripts (in fact I've done that hundreds of times), but I must have made a typo in one place in the original file version and copied that to many other locations. It is interesting that I didn't notice that for years, though I've looked at it all the time. I was getting desparate about unexplained stops in the scripts tonight when finally a veil seems to have been removed from my eyes. Currently I know of two other problems running our builds and tests on the opencsw machines. 1. cvs update does not work on current10x (Solaris on x86) when run from Hudson. It does work on current10s and current9s. It does work if I disable compression (but can do that only for all jobs, which would be a bad pessimization). It does work if I run it from the command line. cvs co in Hudson works OK, too. All attempts to update workspaces by Hudson fail with [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 8:59:46 PM UTC" ... cvs [update aborted]: end of file from server (consult above messages if any) FATAL: CVS failed. exit code=1 Obviously, there are no above messages to consult. If anybody has any ideas what could be causing this, I'd like to hear it. Without update, all the jobs will run rather long on that machine. All machines run exactly the same version of CVS. 2. Copying any archive files out again via ssh and scp has not worked yet. I still need to investigate this, but have hope that I can make this work. Builds for more target platforms should be setup on those machines, but it's tedious work. If anybody wants to take a try, that will be appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 9 11:36:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 9 Aug 2010 09:36:39 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: Very nice. Copying & cvs could be separate tasks, run on login? ("login" being a machine, not a "time"). In fact these all share one filesystem & could share workspaces, albeit with serialization? The problem isn't sharing without serialization? The other interesting platforms are AMD64_SOLARIS and SPARC64_SOLARIS. Should consider SPARC32_SOLARIS & drop SOLgnu & SOLsun. It is already implemented. Thanks, - Jay/phone > Date: Mon, 9 Aug 2010 10:21:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > After several weeks (months?) of little activity I was able to setup > some more build and regression test jobs on the opencsw.org machines. > > There are now sets of jobs for > > SOLsun built on Solaris 10 (works) run on current10s.opencsw.org > SOLsun built on Solaris 9 (seems now to work, too) run on current9s > I386_SOLARIS built on Solaris 10 (still several problems) run on current10x > > For the instruction and exhilaration of those willing to read on I'll > give some details. > > One of the problems was entirely my own fault. In the regression defs.sh > script, about a dozen error messages were written to 1>2 instead of 1>&2. > The second correct form redirects stdout to stderr, while the first just > writes the contents to a file named 2 :-/ It's not that I haven't got > enough experience with writing shell scripts (in fact I've done that > hundreds of times), but I must have made a typo in one place in the > original file version and copied that to many other locations. It is > interesting that I didn't notice that for years, though I've looked > at it all the time. I was getting desparate about unexplained stops > in the scripts tonight when finally a veil seems to have been removed > from my eyes. > > Currently I know of two other problems running our builds and tests > on the opencsw machines. > > 1. cvs update does not work on current10x (Solaris on x86) when run from > Hudson. > It does work on current10s and current9s. > It does work if I disable compression (but can do that only for all jobs, > which would be a bad pessimization). > It does work if I run it from the command line. > cvs co in Hudson works OK, too. > > All attempts to update workspaces by Hudson fail with > > [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 8:59:46 PM UTC" > ... > cvs [update aborted]: end of file from server (consult above > messages if any) > FATAL: CVS failed. exit code=1 > > Obviously, there are no above messages to consult. > If anybody has any ideas what could be causing this, I'd like to > hear it. Without update, all the jobs will run rather long on that > machine. > All machines run exactly the same version of CVS. > > 2. Copying any archive files out again via ssh and scp has not worked > yet. I still need to investigate this, but have hope that I can make > this work. > > Builds for more target platforms should be setup on those machines, > but it's tedious work. If anybody wants to take a try, that will be > appreciated. > > 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 wagner at elegosoft.com Mon Aug 9 12:28:56 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 12:28:56 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: <20100809122856.m94sq8ulss4scwgo@mail.elegosoft.com> Quoting Jay K : > Very nice. > > Copying & cvs could be separate tasks, run on login? ("login" being > a machine, not a "time"). Copying out will probably be no problem, but CVS is tightly integrated into Hudson and needs to be (for impact tracking). I already considered running cvs on login.opencsw.org, but don't know how to configure that. > In fact these all share one filesystem & could share workspaces, > albeit with serialization? The problem isn't sharing without > serialization? No, the workspaces are different (hostname in paths). That would be an imaginable setup, too. But Hudson likes to keep jobs separate and isolated, so it would be even more work I think. > The other interesting platforms are AMD64_SOLARIS and > SPARC64_SOLARIS. Should consider SPARC32_SOLARIS & drop SOLgnu & > SOLsun. It is already implemented. Yes, I should have used SPARC32_SOLARIS instead of SOLsun; will change that at the next opportunity. Do I just need to set the TARGET to compile for those platforms (including AMD64/SPARC64) on those machines? Olaf >> Date: Mon, 9 Aug 2010 10:21:36 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] Short status of CM3 Hudson regression testing >> on opencsw.org machines >> >> After several weeks (months?) of little activity I was able to setup >> some more build and regression test jobs on the opencsw.org machines. >> >> There are now sets of jobs for >> >> SOLsun built on Solaris 10 (works) run on current10s.opencsw.org >> SOLsun built on Solaris 9 (seems now to work, too) run on current9s >> I386_SOLARIS built on Solaris 10 (still several problems) run on >> current10x >> >> For the instruction and exhilaration of those willing to read on I'll >> give some details. >> >> One of the problems was entirely my own fault. In the regression defs.sh >> script, about a dozen error messages were written to 1>2 instead of 1>&2. >> The second correct form redirects stdout to stderr, while the first just >> writes the contents to a file named 2 :-/ It's not that I haven't got >> enough experience with writing shell scripts (in fact I've done that >> hundreds of times), but I must have made a typo in one place in the >> original file version and copied that to many other locations. It is >> interesting that I didn't notice that for years, though I've looked >> at it all the time. I was getting desparate about unexplained stops >> in the scripts tonight when finally a veil seems to have been removed >> from my eyes. >> >> Currently I know of two other problems running our builds and tests >> on the opencsw machines. >> >> 1. cvs update does not work on current10x (Solaris on x86) when run from >> Hudson. >> It does work on current10s and current9s. >> It does work if I disable compression (but can do that only for >> all jobs, >> which would be a bad pessimization). >> It does work if I run it from the command line. >> cvs co in Hudson works OK, too. >> >> All attempts to update workspaces by Hudson fail with >> >> [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 >> 8:59:46 PM UTC" >> ... >> cvs [update aborted]: end of file from server (consult above >> messages if any) >> FATAL: CVS failed. exit code=1 >> >> Obviously, there are no above messages to consult. >> If anybody has any ideas what could be causing this, I'd like to >> hear it. Without update, all the jobs will run rather long on that >> machine. >> All machines run exactly the same version of CVS. >> >> 2. Copying any archive files out again via ssh and scp has not worked >> yet. I still need to investigate this, but have hope that I can make >> this work. >> >> Builds for more target platforms should be setup on those machines, >> but it's tedious work. If anybody wants to take a try, that will be >> appreciated. >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 9 12:48:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 9 Aug 2010 10:48:31 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809122856.m94sq8ulss4scwgo@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com>, , <20100809122856.m94sq8ulss4scwgo@mail.elegosoft.com> Message-ID: Do I just need to set the TARGET to compile for those platforms (including AMD64/SPARC64) on those machines? Um, yes, should just work? (famous lie..). Should even be able to use the same cm3cg. - Jay > Date: Mon, 9 Aug 2010 12:28:56 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting Jay K : > > > Very nice. > > > > Copying & cvs could be separate tasks, run on login? ("login" being > > a machine, not a "time"). > Copying out will probably be no problem, but CVS is tightly integrated > into Hudson and needs to be (for impact tracking). I already considered > running cvs on login.opencsw.org, but don't know how to configure that. > > > In fact these all share one filesystem & could share workspaces, > > albeit with serialization? The problem isn't sharing without > > serialization? > > No, the workspaces are different (hostname in paths). > > That would be an imaginable setup, too. But Hudson likes to keep > jobs separate and isolated, so it would be even more work I think. > > > The other interesting platforms are AMD64_SOLARIS and > > SPARC64_SOLARIS. Should consider SPARC32_SOLARIS & drop SOLgnu & > > SOLsun. It is already implemented. > > Yes, I should have used SPARC32_SOLARIS instead of SOLsun; will change > that at the next opportunity. > > Do I just need to set the TARGET to compile for those platforms (including > AMD64/SPARC64) on those machines? > > Olaf > > >> Date: Mon, 9 Aug 2010 10:21:36 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> > >> After several weeks (months?) of little activity I was able to setup > >> some more build and regression test jobs on the opencsw.org machines. > >> > >> There are now sets of jobs for > >> > >> SOLsun built on Solaris 10 (works) run on current10s.opencsw.org > >> SOLsun built on Solaris 9 (seems now to work, too) run on current9s > >> I386_SOLARIS built on Solaris 10 (still several problems) run on > >> current10x > >> > >> For the instruction and exhilaration of those willing to read on I'll > >> give some details. > >> > >> One of the problems was entirely my own fault. In the regression defs.sh > >> script, about a dozen error messages were written to 1>2 instead of 1>&2. > >> The second correct form redirects stdout to stderr, while the first just > >> writes the contents to a file named 2 :-/ It's not that I haven't got > >> enough experience with writing shell scripts (in fact I've done that > >> hundreds of times), but I must have made a typo in one place in the > >> original file version and copied that to many other locations. It is > >> interesting that I didn't notice that for years, though I've looked > >> at it all the time. I was getting desparate about unexplained stops > >> in the scripts tonight when finally a veil seems to have been removed > >> from my eyes. > >> > >> Currently I know of two other problems running our builds and tests > >> on the opencsw machines. > >> > >> 1. cvs update does not work on current10x (Solaris on x86) when run from > >> Hudson. > >> It does work on current10s and current9s. > >> It does work if I disable compression (but can do that only for > >> all jobs, > >> which would be a bad pessimization). > >> It does work if I run it from the command line. > >> cvs co in Hudson works OK, too. > >> > >> All attempts to update workspaces by Hudson fail with > >> > >> [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 > >> 8:59:46 PM UTC" > >> ... > >> cvs [update aborted]: end of file from server (consult above > >> messages if any) > >> FATAL: CVS failed. exit code=1 > >> > >> Obviously, there are no above messages to consult. > >> If anybody has any ideas what could be causing this, I'd like to > >> hear it. Without update, all the jobs will run rather long on that > >> machine. > >> All machines run exactly the same version of CVS. > >> > >> 2. Copying any archive files out again via ssh and scp has not worked > >> yet. I still need to investigate this, but have hope that I can make > >> this work. > >> > >> Builds for more target platforms should be setup on those machines, > >> but it's tedious work. If anybody wants to take a try, that will be > >> appreciated. > >> > >> 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 dam at opencsw.org Mon Aug 9 13:47:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Aug 2010 13:47:12 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: Hi Olaf, Am 09.08.2010 um 10:21 schrieb Olaf Wagner: > Currently I know of two other problems running our builds and tests > on the opencsw machines. > > 1. cvs update does not work on current10x (Solaris on x86) when run > from > Hudson. > It does work on current10s and current9s. Interesting. current*s are all running on the same physical machine as zones, whereas current*x are located on a vSphere farm. Do you have a specific command sequence which I can try to reproduce the problem? Are you using cvs stable (1.11.23) or feature (1.12.13)? > It does work if I disable compression (but can do that only for > all jobs, > which would be a bad pessimization). > It does work if I run it from the command line. > cvs co in Hudson works OK, too. This sounds like a strange and subtle bug... Best regards -- Dago From rcolebur at SCIRES.COM Mon Aug 9 16:27:24 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 9 Aug 2010 10:27:24 -0400 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: References: Message-ID: Windows is my current platform for Modula-3. I can make available machines for various flavors of Windows. I don't understand much about the current Hudson automation, but I am willing to learn and to do some customization for support on Windows. I also have some old Apple iBook notebooks that I could enlist, if these would help. I also have a very old HP-UX machine that would need some work to get running again. I also have a Sun workstation that hasn't been booted up in a few years. I think it has Solaris 9 on it, but I am pretty sure we could replace the OS with Solaris 10 or something else. Let me know if any of these are needed. Regards, Randy -----Original Message----- From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Saturday, August 07, 2010 10:30 AM To: m3devel Subject: [M3devel] more Hudson nodes? more help in general? Hey, I'm hoping we can get more people helping more. Coding, features, fixing bugs, etc. However one of the easiest things I'd like to see is a few more Hudson nodes. Is anyone out there running e.g. NetBSD on x86 or AMD64? ? They would be the easiest, sort of, to setup. I will help anyone. ? Or Solaris on SPARC (replace mine) or x86? (Yes I know about opencsw, but the network ? topology is seemingly difficult.) Or heck, Linux or OpenBSD on x86? (replace mine) x86/AMD64 in particular has better availability of Java VMs, which we need. Or, Linux now has good across the board Java support. And can setup dynamic DNS or has static IP? We could use NT386 but I know the setup might not be so easy. There are other viable machines, e.g. one of the new or old Linux/mips. Or likely some of the obscure systems like HP-UX, AIX, Irix. If anyone here is actively running one of these, keeps machine on, speak up. (At some point, I'd like to have Hudson wake-on-lan the machines, or have the machines scheduled to wake up daily check for work, and then back to sleep after completing any queued work; the second option doesn't require Hudson support.) The machine can be quite low end. Many of mine are old laptops, or very old either way. Around $200, years ago. Any other projects in the system people are interested in helping out on, with ? time/coding, please speak up if you need help. If you need ideas, or assistance, etc. Thanks, ?- Jay From wagner at elegosoft.com Mon Aug 9 17:01:24 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 17:01:24 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> Quoting Dagobert Michelsen : > Hi Olaf, > > Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >> Currently I know of two other problems running our builds and tests >> on the opencsw machines. >> >> 1. cvs update does not work on current10x (Solaris on x86) when run from >> Hudson. >> It does work on current10s and current9s. > > Interesting. current*s are all running on the same physical machine as zones, > whereas current*x are located on a vSphere farm. Do you have a specific > command sequence which I can try to reproduce the problem? I'm not yet able to reproduce it manually; I only see it in the Hudson jobs (failing right away when computing the changelog). If you want, I can setup a job for test purposes and you can get Hudson access. > Are you using cvs stable (1.11.23) or feature (1.12.13)? Stable. I'll try with 1.12.13, too (haven't seen that around). Is it installed anywhere?? >> It does work if I disable compression (but can do that only for all jobs, >> which would be a bad pessimization). >> It does work if I run it from the command line. >> cvs co in Hudson works OK, too. > > This sounds like a strange and subtle bug... Yep. 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 Mon Aug 9 17:13:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 17:13:30 +0200 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: References: Message-ID: <20100809171330.fe3pc7nwgwosg4wg@mail.elegosoft.com> Quoting "Coleburn, Randy" : > Windows is my current platform for Modula-3. I can make available > machines for various flavors of Windows. > > I don't understand much about the current Hudson automation, but I > am willing to learn and to do some customization for support on > Windows. > > I also have some old Apple iBook notebooks that I could enlist, if > these would help. I also have a very old HP-UX machine that would > need some work to get running again. > > I also have a Sun workstation that hasn't been booted up in a few > years. I think it has Solaris 9 on it, but I am pretty sure we > could replace the OS with Solaris 10 or something else. > > Let me know if any of these are needed. Another (more reliable) Windows client would be great, but be forwarned that it won't be easy to get it running in combination with the existing scripts. We had to get another commercial ssh daemon IIRC, and me and Jay have hunted down failures for weeks. The Apple iBook may also be of interest (if it is not too slow). What version of MacOS is it running? My own old Powerbook (400 MHz) is currently running the PPC_DARWIN tests. Sun should be fairly well covered, if we succeed with all the opencsw.org machines, and Antony Hosking has also a machine currently running the tinderbox tests, IIRC. IMO we could probably do without Tinderbox soon. I'm not sure if anybody is really interested in HPUX. For me this seems to have mostly hostorical value :-) I may be wrong there of course... Olaf > Regards, > Randy > > > -----Original Message----- > From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K > Sent: Saturday, August 07, 2010 10:30 AM > To: m3devel > Subject: [M3devel] more Hudson nodes? more help in general? > > > Hey, I'm hoping we can get more people helping more. > > Coding, features, fixing bugs, etc. > > > However one of the easiest things I'd like to see is a few more Hudson nodes. > > > Is anyone out there running e.g. NetBSD on x86 or AMD64? > ? They would be the easiest, sort of, to setup. I will help anyone. > ? Or Solaris on SPARC (replace mine) or x86? (Yes I know about > opencsw, but the network > ? topology is seemingly difficult.) > > > Or heck, Linux or OpenBSD on x86? (replace mine) > > > x86/AMD64 in particular has better availability of Java VMs, which we need. > Or, Linux now has good across the board Java support. > > > And can setup dynamic DNS or has static IP? > > > We could use NT386 but I know the setup might not be so easy. > > > There are other viable machines, e.g. one of the new or old Linux/mips. > Or likely some of the obscure systems like HP-UX, AIX, Irix. > If anyone here is actively running one of these, keeps machine on, speak up. > (At some point, I'd like to have Hudson wake-on-lan the machines, > or have the machines scheduled to wake up daily check for work, and then > back to sleep after completing any queued work; the second option > doesn't require Hudson support.) > > > The machine can be quite low end. > Many of mine are old laptops, or very old either way. > Around $200, years ago. > > > Any other projects in the system people are interested in helping > out on, with > ? time/coding, please speak up if you need help. If you need ideas, > or assistance, etc. > > > Thanks, > ?- 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 m3 at sol42.com Mon Aug 9 22:17:35 2010 From: m3 at sol42.com (m3 at sol42.com) Date: Mon, 9 Aug 2010 22:17:35 +0200 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: <20100809171330.fe3pc7nwgwosg4wg@mail.elegosoft.com> References: <20100809171330.fe3pc7nwgwosg4wg@mail.elegosoft.com> Message-ID: Hello. I know we are talking about machines that would be running 24/7, but maybe is there a way for a machine to automatically join a Hudson server and do some work when it is booted say twice a week (which I concede is the opposite of continuous integration)? I have some machines that might be of help, but I don't do much with them nowadays and cannot afford to keep them up all the time: - mostly silent: a Mac mini G4, 1,5GHz, 1GB RAM, Mac OS X 10.5.8; - somewhat noisy: a Sun Ultra 60, 2*450 MHz, 2GB RAM, Solaris 10 from some time before Oracle changed Solaris terms (meaning it won't be upgraded, but I keep the JDK current); - like having an airport inside the room: an IRIX machine Hudson will not run on due to lack of a 1.5 JRE :( but if I keep it on in winter then I can turn off heating. Regards. -Daniel From dabenavidesd at yahoo.es Tue Aug 10 01:00:49 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 9 Aug 2010 23:00:49 +0000 (GMT) Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: Message-ID: <573133.51461.qm@web29705.mail.ird.yahoo.com> Hi all: well in that case it would be probably less efficient to have running over and over probably if you are brave enough to virtualize it might be possible to load a good server with some virtual machines which later you can teleport like Vbox over a net and run for testing of the concept like you say twice a week. Tere is one in aprticular probably useful for the Irix the SimOS, which run natevely in the IRIX and others now, also other platforms like DEC Alpha and power PC. I have downloaded an article from computer world library so you can check for details in the efficient virtualization affairs, it requires sign up to grab it (see http://www.vision6.com.au/ch/21104/2d34n3v/1289505/1b836s789.html ) so you can have it from here (just accept secure certificate and agree to add an exception): https://168.176.86.16/~danielb/Virtualization_APC.pdf As for the JVM you can have Loongson JVM for free ( http://debian.printk.org/software-loongson/jvm/jdk15_mips_080103.tar.gz ) in those machines to do the JVM part of the job, though not sure if hat works for your needs and available resources and system implementation. Thanks in advance --- El lun, 9/8/10, m3 at sol42.com escribi?: > De: m3 at sol42.com > Asunto: Re: [M3devel] more Hudson nodes? more help in general? > Para: "m3devel" > Fecha: lunes, 9 de agosto, 2010 15:17 > Hello. I know we are talking > about machines that would be running 24/7, but maybe is > there a way for a machine to automatically join a Hudson > server and do some work when it is booted say twice a week > (which I concede is the opposite of continuous > integration)? > I have some machines that might be of help, but I don't do > much with them nowadays and cannot afford to keep them up > all the time: > - mostly silent: a Mac mini G4, 1,5GHz, 1GB RAM, Mac OS X > 10.5.8; > - somewhat noisy: a Sun Ultra 60, 2*450 MHz, 2GB RAM, > Solaris 10 from some time before Oracle changed Solaris > terms (meaning it won't be upgraded, but I keep the JDK > current); > - like having an airport inside the room: an IRIX machine > Hudson will not run on due to lack of a 1.5 JRE :( but if I > keep it on in winter then I can turn off heating. > Regards. > -Daniel From jay.krell at cornell.edu Tue Aug 10 02:29:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 10 Aug 2010 00:29:20 +0000 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: <573133.51461.qm@web29705.mail.ird.yahoo.com> References: , <573133.51461.qm@web29705.mail.ird.yahoo.com> Message-ID: Virtualization works great for x86, AMD64. Less so for others. There is "gxemul" but it is less widely used, probably harder to use, I haven't tried it yet. It might work for MIPS esp. There was a project to remove the assembly code from Sun's Java. As a result, Java is well available on any architecture on Linux. e.g. we have Linux/powerpc, Linux/sparc, and I expect we'll soon have Linux/mips, in Hudson. But so far it is Linux-only where this work can be used, as far as I know. I was thinking we could move the Elego NT386 VM. Probably should run sysprep /generalize on it first. Sparc, PowerPC do have some sorts of virtualization, but it is kind of more esoteric and I suspect harder to use. e.g. on Solaris, on AIX. I hadn't heard of SimOS and maybe others. More research to do.. Thanks, - Jay > Date: Mon, 9 Aug 2010 23:00:49 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; m3 at sol42.com > Subject: Re: [M3devel] more Hudson nodes? more help in general? > > Hi all: > well in that case it would be probably less efficient to have running over and over probably if you are brave enough to virtualize it might be possible to load a good server with some virtual machines which later you can teleport like Vbox over a net and run for testing of the concept like you say twice a week. Tere is one in aprticular probably useful for the Irix the SimOS, which run natevely in the IRIX and others now, also other platforms like DEC Alpha and power PC. > I have downloaded an article from computer world library so you can check for details in the efficient virtualization affairs, it requires sign up to grab it (see http://www.vision6.com.au/ch/21104/2d34n3v/1289505/1b836s789.html ) so you can have it from here (just accept secure certificate and agree to add an exception): > https://168.176.86.16/~danielb/Virtualization_APC.pdf > As for the JVM you can have Loongson JVM for free ( http://debian.printk.org/software-loongson/jvm/jdk15_mips_080103.tar.gz ) in those machines to do the JVM part of the job, though not sure if hat works for your needs and available resources and system implementation. > > Thanks in advance > > > --- El lun, 9/8/10, m3 at sol42.com escribi?: > > > De: m3 at sol42.com > > Asunto: Re: [M3devel] more Hudson nodes? more help in general? > > Para: "m3devel" > > Fecha: lunes, 9 de agosto, 2010 15:17 > > Hello. I know we are talking > > about machines that would be running 24/7, but maybe is > > there a way for a machine to automatically join a Hudson > > server and do some work when it is booted say twice a week > > (which I concede is the opposite of continuous > > integration)? > > I have some machines that might be of help, but I don't do > > much with them nowadays and cannot afford to keep them up > > all the time: > > - mostly silent: a Mac mini G4, 1,5GHz, 1GB RAM, Mac OS X > > 10.5.8; > > - somewhat noisy: a Sun Ultra 60, 2*450 MHz, 2GB RAM, > > Solaris 10 from some time before Oracle changed Solaris > > terms (meaning it won't be upgraded, but I keep the JDK > > current); > > - like having an airport inside the room: an IRIX machine > > Hudson will not run on due to lack of a 1.5 JRE :( but if I > > keep it on in winter then I can turn off heating. > > Regards. > > -Daniel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Aug 10 07:54:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 10 Aug 2010 07:54:30 +0200 Subject: [M3devel] assembler problems on Solaris 9 Message-ID: <20100810075430.u41viro3q8ksckcw@mail.elegosoft.com> example: assembler failed assembling: RTHeapMap.ms /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: unknown opcode ".hidden" /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: statement syntax assemble => 1 see http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/20/console 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 dam at opencsw.org Tue Aug 10 09:34:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 10 Aug 2010 09:34:23 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> Message-ID: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Hi Olaf, Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > Quoting Dagobert Michelsen : >> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>> Currently I know of two other problems running our builds and tests >>> on the opencsw machines. >>> >>> 1. cvs update does not work on current10x (Solaris on x86) when >>> run from >>> Hudson. >>> It does work on current10s and current9s. >> >> Interesting. current*s are all running on the same physical machine >> as zones, >> whereas current*x are located on a vSphere farm. Do you have a >> specific >> command sequence which I can try to reproduce the problem? > > I'm not yet able to reproduce it manually; I only see it in the > Hudson jobs (failing right away when computing the changelog). > > If you want, I can setup a job for test purposes and you can get > Hudson access. I can't promise I can fix this but if you set something up I may look in the next few days. >> Are you using cvs stable (1.11.23) or feature (1.12.13)? > > Stable. I'll try with 1.12.13, too (haven't seen that around). > Is it installed anywhere?? That is here: /opt/csw/cvs-feature/bin/cvs Best regards -- Dago From wagner at elegosoft.com Tue Aug 10 13:43:49 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 10 Aug 2010 13:43:49 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Message-ID: <20100810134349.5votgjcz48408sow@mail.elegosoft.com> Quoting Dagobert Michelsen : > Hi Olaf, > > Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> Quoting Dagobert Michelsen : >>> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>>> Currently I know of two other problems running our builds and tests >>>> on the opencsw machines. >>>> >>>> 1. cvs update does not work on current10x (Solaris on x86) when run from >>>> Hudson. >>>> It does work on current10s and current9s. >>> >>> Interesting. current*s are all running on the same physical >>> machine as zones, >>> whereas current*x are located on a vSphere farm. Do you have a specific >>> command sequence which I can try to reproduce the problem? >> >> I'm not yet able to reproduce it manually; I only see it in the >> Hudson jobs (failing right away when computing the changelog). >> >> If you want, I can setup a job for test purposes and you can get >> Hudson access. > > I can't promise I can fix this but if you set something up I may look > in the next few days. I finally managed to reproduce the problem in the build step of a Hudson job, and got this after enabling tracing: -> rename(CVS/Entries.Backup,CVS/Entries) -> unlink_file(CVS/Entries.Log) cvs update: inflate: unknown compression method cvs [update aborted]: reading from server: I/O error -> Lock_Cleanup() Finished: FAILURE Is there a different/an older gzip library on current10x? see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >>> Are you using cvs stable (1.11.23) or feature (1.12.13)? >> >> Stable. I'll try with 1.12.13, too (haven't seen that around). >> Is it installed anywhere?? > > That is here: > /opt/csw/cvs-feature/bin/cvs Will it help if I try that, or does it use the same gzip lib? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 10 15:33:04 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 10 Aug 2010 15:33:04 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100810134349.5votgjcz48408sow@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> <20100810134349.5votgjcz48408sow@mail.elegosoft.com> Message-ID: <20100810153304.06vsgq848wcow0ok@mail.elegosoft.com> Quoting Olaf Wagner : > Quoting Dagobert Michelsen : > >> Hi Olaf, >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >>> Quoting Dagobert Michelsen : >>>> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>>>> Currently I know of two other problems running our builds and tests >>>>> on the opencsw machines. >>>>> >>>>> 1. cvs update does not work on current10x (Solaris on x86) when run from >>>>> Hudson. >>>>> It does work on current10s and current9s. >>>> >>>> Interesting. current*s are all running on the same physical >>>> machine as zones, >>>> whereas current*x are located on a vSphere farm. Do you have a specific >>>> command sequence which I can try to reproduce the problem? >>> >>> I'm not yet able to reproduce it manually; I only see it in the >>> Hudson jobs (failing right away when computing the changelog). >>> >>> If you want, I can setup a job for test purposes and you can get >>> Hudson access. >> >> I can't promise I can fix this but if you set something up I may look >> in the next few days. > > I finally managed to reproduce the problem in the build step of > a Hudson job, and got this after enabling tracing: > > -> rename(CVS/Entries.Backup,CVS/Entries) > -> unlink_file(CVS/Entries.Log) > cvs update: inflate: unknown compression method > cvs [update aborted]: reading from server: I/O error > -> Lock_Cleanup() > Finished: FAILURE > > Is there a different/an older gzip library on current10x? > > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >>>> Are you using cvs stable (1.11.23) or feature (1.12.13)? >>> >>> Stable. I'll try with 1.12.13, too (haven't seen that around). >>> Is it installed anywhere?? >> >> That is here: >> /opt/csw/cvs-feature/bin/cvs 1.12.13 says cvs update: inflate: invalid distance too far back cvs [update aborted]: reading from server: I/O error Finished: FAILURE Any ideas? 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 dabenavidesd at yahoo.es Tue Aug 10 23:04:39 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 10 Aug 2010 21:04:39 +0000 (GMT) Subject: [M3devel] assembler problems on Solaris 9 In-Reply-To: <20100810075430.u41viro3q8ksckcw@mail.elegosoft.com> Message-ID: <755920.39660.qm@web29709.mail.ird.yahoo.com> Hi all: not sure what the message meant but it seems like the code generator is broken putting labels in assembly code body. What is the assembler's version number, if it is natively generated (self-hosted not cross-assembled even from a previous other m3cg cross-assembler), assuming so, where are supposed to be placed labels to match system's assembly? Probably useful to print m3-sys/m3cgcat comparing with repository working correspondent and/or m3-tools/hexdump. Though compiler is enabled to do such a cross assembly process I wonder how that might be the result of compiling it with a different m3cg if that fails too, it might be a problem in the assembly emitting, what do you think? Thanks in advance --- El mar, 10/8/10, Olaf Wagner escribi?: > De: Olaf Wagner > Asunto: [M3devel] assembler problems on Solaris 9 > Para: m3devel at elegosoft.com > Fecha: martes, 10 de agosto, 2010 00:54 > example: > > assembler failed assembling: RTHeapMap.ms > /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: unknown > opcode ".hidden" > /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: > statement syntax > assemble => 1 > > see http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/20/console > > 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 dabenavidesd at yahoo.es Tue Aug 10 23:54:47 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 10 Aug 2010 21:54:47 +0000 (GMT) Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100810153304.06vsgq848wcow0ok@mail.elegosoft.com> Message-ID: <542991.69565.qm@web29701.mail.ird.yahoo.com> Hi all: I was rethinking but it seems you caught a bug either inside opencsw.org or elego system (incompatible versions). Probably will be a lot easier with some special techniques like this ones I assume you're not able to do that but just in case you do sshfs: http://www.linux-mag.com/id/7820 How critical is this process for it? see suggestions for it see pages 34 and 42 about centralizing control over files in contrast of distributed and the efficiency in I/O transmission and suggestions for improving it in a white "paper" book of "The Shortcut guide to Eliminating Insecure and Unreliable File Transfer Methods" if that might help (again just accept the security domain error and add the security exception) https://168.176.86.16/~danielb/SGEIU-complete.pdf downloaded from http://nexus.realtimepublishers.com/sgeiu.php you will need an account and take a survey on the topic if you might In such a case where you are allowed sshfs might be an interesting option it requires user space file system but if the performance is not critical perhaps we can think about it, can we, might be interesting for a windows setting, etc? Thanks in advance, hope it helps --- El mar, 10/8/10, Olaf Wagner escribi?: > De: Olaf Wagner > Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > Para: m3devel at elegosoft.com > Fecha: martes, 10 de agosto, 2010 08:33 > Quoting Olaf Wagner : > > > Quoting Dagobert Michelsen : > > > >> Hi Olaf, > >> > >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >>> Quoting Dagobert Michelsen : > >>>> Am 09.08.2010 um 10:21 schrieb Olaf > Wagner: > >>>>> Currently I know of two other problems > running our builds and tests > >>>>> on the opencsw machines. > >>>>> > >>>>> 1. cvs update does not work on > current10x (Solaris on x86) when run from > >>>>> Hudson. > >>>>> It does work on current10s and > current9s. > >>>> > >>>> Interesting. current*s are all running on > the same physical > >>>> machine as zones, > >>>> whereas current*x are located on a vSphere > farm. Do you have a specific > >>>> command sequence which I can try to > reproduce the problem? > >>> > >>> I'm not yet able to reproduce it manually; I > only see it in the > >>> Hudson jobs (failing right away when computing > the changelog). > >>> > >>> If you want, I can setup a job for test > purposes and you can get > >>> Hudson access. > >> > >> I can't promise I can fix this but if you set > something up I may look > >> in the next few days. > > > > I finally managed to reproduce the problem in the > build step of > > a Hudson job, and got this after enabling tracing: > > > > -> rename(CVS/Entries.Backup,CVS/Entries) > > -> unlink_file(CVS/Entries.Log) > > cvs update: inflate: unknown compression method > > cvs [update aborted]: reading from server: I/O error > > -> Lock_Cleanup() > > Finished: FAILURE > > > > Is there a different/an older gzip library on > current10x? > > > > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > > > >>>> Are you using cvs stable (1.11.23) or > feature (1.12.13)? > >>> > >>> Stable. I'll try with 1.12.13, too (haven't > seen that around). > >>> Is it installed anywhere?? > >> > >> That is here: > >> /opt/csw/cvs-feature/bin/cvs > > 1.12.13 says > > cvs update: inflate: invalid distance too far back cvs > [update > aborted]: reading from server: I/O error > Finished: FAILURE > > Any ideas? > > 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 Wed Aug 11 09:18:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 11 Aug 2010 09:18:38 +0200 Subject: [M3devel] assembler problems on Solaris 9 In-Reply-To: <755920.39660.qm@web29709.mail.ird.yahoo.com> References: <755920.39660.qm@web29709.mail.ird.yahoo.com> Message-ID: <20100811091838.u9g8wp7oso404cso@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > not sure what the message meant but it seems like the code generator > is broken putting labels in assembly code body. What is the > assembler's version number, if it is natively generated (self-hosted > not cross-assembled even from a previous other m3cg > cross-assembler), assuming so, where are supposed to be placed > labels to match system's assembly? Probably useful to print > m3-sys/m3cgcat comparing with repository working correspondent > and/or m3-tools/hexdump. Though compiler is enabled to do such a > cross assembly process I wonder how that might be the result of > compiling it with a different m3cg if that fails too, it might be a > problem in the assembly emitting, what do you think? It seems to be an incompatibility with the Solaris 9 assembler. The Solaris 10 assembler works fine. We haven't built the system on Solaris 9 for a long time I think. Or have we? Perhaps this is gcc 4.5 related? No, it's using 4.3, but in two different setups: WI=/home/m3hudson/current9s/work/cm3-inst/current9s/solsun + /home/m3hudson/current9s/work/cm3-inst/current9s/solsun/current/bin/cm3cg --version Modula-3 backend (GCC) version 4.3.5 (sparc-sun-solaris2.10) compiled by GNU C version 4.2.0 (gccfss), GMP version 4.2.1, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 + /home/m3hudson/current9s/work/cm3-inst/current9s/solsun/last-ok/bin/cm3cg --version Modula-3 backend (GCC) version 4.3.0 (sparc-sun-solaris2) compiled by GNU C version 3.4.3 (csl-sol210-3_4-branch+sol_rpath), GMP version 4.2.1, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 I guess our current configuration in m3cc/src/m3makefile is wrong for Solaris 9, or that gcc target was broken in the upgrade from 4.3.0 to 4.3.5. Olaf > Thanks in advance > > --- El mar, 10/8/10, Olaf Wagner escribi?: > >> De: Olaf Wagner >> Asunto: [M3devel] assembler problems on Solaris 9 >> Para: m3devel at elegosoft.com >> Fecha: martes, 10 de agosto, 2010 00:54 >> example: >> >> assembler failed assembling: RTHeapMap.ms >> /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: unknown >> opcode ".hidden" >> /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: >> statement syntax >> assemble => 1 >> >> see >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/20/console >> >> 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 >> >> > > > > -- 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 Wed Aug 11 09:26:35 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 11 Aug 2010 09:26:35 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <542991.69565.qm@web29701.mail.ird.yahoo.com> References: <542991.69565.qm@web29701.mail.ird.yahoo.com> Message-ID: <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > I was rethinking but it seems you caught a bug either inside > opencsw.org or elego system (incompatible versions). There are no incompatible CVS versions. Birch is running 1.12.13, and current9s.opencsw.org is running both that and 1.11.23. Should all work fine theoretically. It may be a problem with the proxy we need to use to get out from opencsw.org, too. Olaf PS: I don't think cool user space file systems from Linux will help us on Solaris systems, nor will opencsw.org change their general setup and policies for us. > Probably will be a lot easier with some special techniques like this ones > I assume you're not able to do that but just in case you do sshfs: > http://www.linux-mag.com/id/7820 > How critical is this process for it? see suggestions for it see > pages 34 and 42 about centralizing control over files in contrast of > distributed and the efficiency in I/O transmission and suggestions > for improving it in a white "paper" book of "The Shortcut guide to > Eliminating Insecure > and Unreliable File Transfer Methods" if that might help (again just > accept the security domain error and add the security exception) > https://168.176.86.16/~danielb/SGEIU-complete.pdf > downloaded from > http://nexus.realtimepublishers.com/sgeiu.php > you will need an account and take a survey on the topic if you might > In such a case where you are allowed sshfs might be an interesting > option it requires user space file system but if the performance is > not critical perhaps we can think about it, can we, might be > interesting for a windows setting, etc? > > Thanks in advance, hope it helps > > --- El mar, 10/8/10, Olaf Wagner escribi?: > >> De: Olaf Wagner >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing >> on opencsw.org machines >> Para: m3devel at elegosoft.com >> Fecha: martes, 10 de agosto, 2010 08:33 >> Quoting Olaf Wagner : >> >> > Quoting Dagobert Michelsen : >> > >> >> Hi Olaf, >> >> >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> >>> Quoting Dagobert Michelsen : >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf >> Wagner: >> >>>>> Currently I know of two other problems >> running our builds and tests >> >>>>> on the opencsw machines. >> >>>>> >> >>>>> 1. cvs update does not work on >> current10x (Solaris on x86) when run from >> >>>>> Hudson. >> >>>>> It does work on current10s and >> current9s. >> >>>> >> >>>> Interesting. current*s are all running on >> the same physical >> >>>> machine as zones, >> >>>> whereas current*x are located on a vSphere >> farm. Do you have a specific >> >>>> command sequence which I can try to >> reproduce the problem? >> >>> >> >>> I'm not yet able to reproduce it manually; I >> only see it in the >> >>> Hudson jobs (failing right away when computing >> the changelog). >> >>> >> >>> If you want, I can setup a job for test >> purposes and you can get >> >>> Hudson access. >> >> >> >> I can't promise I can fix this but if you set >> something up I may look >> >> in the next few days. >> > >> > I finally managed to reproduce the problem in the >> build step of >> > a Hudson job, and got this after enabling tracing: >> > >> > -> rename(CVS/Entries.Backup,CVS/Entries) >> > -> unlink_file(CVS/Entries.Log) >> > cvs update: inflate: unknown compression method >> > cvs [update aborted]: reading from server: I/O error >> > -> Lock_Cleanup() >> > Finished: FAILURE >> > >> > Is there a different/an older gzip library on >> current10x? >> > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >> > >> >>>> Are you using cvs stable (1.11.23) or >> feature (1.12.13)? >> >>> >> >>> Stable. I'll try with 1.12.13, too (haven't >> seen that around). >> >>> Is it installed anywhere?? >> >> >> >> That is here: >> >> /opt/csw/cvs-feature/bin/cvs >> >> 1.12.13 says >> >> cvs update: inflate: invalid distance too far back cvs >> [update >> aborted]: reading from server: I/O error >> Finished: FAILURE >> >> Any ideas? >> >> 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 >> >> > > > > -- 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 Wed Aug 11 18:10:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 11 Aug 2010 16:10:24 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> Message-ID: Olaf I think we should do a bit more research here, but I also think we have a few easy options. - build our own cvs, put it in $HOME/bin. - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. - Jay > Date: Wed, 11 Aug 2010 09:26:35 +0200 > From: wagner at elegosoft.com > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting "Daniel Alejandro Benavides D." : > > > Hi all: > > I was rethinking but it seems you caught a bug either inside > > opencsw.org or elego system (incompatible versions). > > There are no incompatible CVS versions. Birch is running 1.12.13, > and current9s.opencsw.org is running both that and 1.11.23. Should > all work fine theoretically. > > It may be a problem with the proxy we need to use to get out from > opencsw.org, too. > > Olaf > > PS: I don't think cool user space file systems from Linux will help > us on Solaris systems, nor will opencsw.org change their general > setup and policies for us. > > > Probably will be a lot easier with some special techniques like this ones > > I assume you're not able to do that but just in case you do sshfs: > > http://www.linux-mag.com/id/7820 > > How critical is this process for it? see suggestions for it see > > pages 34 and 42 about centralizing control over files in contrast of > > distributed and the efficiency in I/O transmission and suggestions > > for improving it in a white "paper" book of "The Shortcut guide to > > Eliminating Insecure > > and Unreliable File Transfer Methods" if that might help (again just > > accept the security domain error and add the security exception) > > https://168.176.86.16/~danielb/SGEIU-complete.pdf > > downloaded from > > http://nexus.realtimepublishers.com/sgeiu.php > > you will need an account and take a survey on the topic if you might > > In such a case where you are allowed sshfs might be an interesting > > option it requires user space file system but if the performance is > > not critical perhaps we can think about it, can we, might be > > interesting for a windows setting, etc? > > > > Thanks in advance, hope it helps > > > > --- El mar, 10/8/10, Olaf Wagner escribi?: > > > >> De: Olaf Wagner > >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> Para: m3devel at elegosoft.com > >> Fecha: martes, 10 de agosto, 2010 08:33 > >> Quoting Olaf Wagner : > >> > >> > Quoting Dagobert Michelsen : > >> > > >> >> Hi Olaf, > >> >> > >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >> >>> Quoting Dagobert Michelsen : > >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf > >> Wagner: > >> >>>>> Currently I know of two other problems > >> running our builds and tests > >> >>>>> on the opencsw machines. > >> >>>>> > >> >>>>> 1. cvs update does not work on > >> current10x (Solaris on x86) when run from > >> >>>>> Hudson. > >> >>>>> It does work on current10s and > >> current9s. > >> >>>> > >> >>>> Interesting. current*s are all running on > >> the same physical > >> >>>> machine as zones, > >> >>>> whereas current*x are located on a vSphere > >> farm. Do you have a specific > >> >>>> command sequence which I can try to > >> reproduce the problem? > >> >>> > >> >>> I'm not yet able to reproduce it manually; I > >> only see it in the > >> >>> Hudson jobs (failing right away when computing > >> the changelog). > >> >>> > >> >>> If you want, I can setup a job for test > >> purposes and you can get > >> >>> Hudson access. > >> >> > >> >> I can't promise I can fix this but if you set > >> something up I may look > >> >> in the next few days. > >> > > >> > I finally managed to reproduce the problem in the > >> build step of > >> > a Hudson job, and got this after enabling tracing: > >> > > >> > -> rename(CVS/Entries.Backup,CVS/Entries) > >> > -> unlink_file(CVS/Entries.Log) > >> > cvs update: inflate: unknown compression method > >> > cvs [update aborted]: reading from server: I/O error > >> > -> Lock_Cleanup() > >> > Finished: FAILURE > >> > > >> > Is there a different/an older gzip library on > >> current10x? > >> > > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >> > > >> >>>> Are you using cvs stable (1.11.23) or > >> feature (1.12.13)? > >> >>> > >> >>> Stable. I'll try with 1.12.13, too (haven't > >> seen that around). > >> >>> Is it installed anywhere?? > >> >> > >> >> That is here: > >> >> /opt/csw/cvs-feature/bin/cvs > >> > >> 1.12.13 says > >> > >> cvs update: inflate: invalid distance too far back cvs > >> [update > >> aborted]: reading from server: I/O error > >> Finished: FAILURE > >> > >> Any ideas? > >> > >> 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 > >> > >> > > > > > > > > > > > > -- > 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 Thu Aug 12 01:42:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 11 Aug 2010 23:42:39 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, , <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com>, Message-ID: Hm, that this means by the way, I think, is the compressed data is not recognized as valid. e.g. it isn't -z3 being rejected, but the data from the server. Maybe the network is flaky and corrupting the data? That aside, I wonder if we could try -z1, -z2, -z4, -z5, etc. ay at xlin2:~/src/cvs-1.12.13/cvs-1.12.13$ grep "unknown compre" */* zlib/inflate.c: strm->msg = (char *)"unknown compression method"; zlib/inflate.c: strm->msg = (char *)"unknown compression method"; if (BITS(4) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } ... #ifdef GUNZIP case FLAGS: NEEDBITS(16); state->flags = (int)(hold); if ((state->flags & 0xff) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dabenavidesd at yahoo.es Date: Wed, 11 Aug 2010 16:10:24 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Olaf I think we should do a bit more research here, but I also think we have a few easy options. - build our own cvs, put it in $HOME/bin. - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. - Jay > Date: Wed, 11 Aug 2010 09:26:35 +0200 > From: wagner at elegosoft.com > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting "Daniel Alejandro Benavides D." : > > > Hi all: > > I was rethinking but it seems you caught a bug either inside > > opencsw.org or elego system (incompatible versions). > > There are no incompatible CVS versions. Birch is running 1.12.13, > and current9s.opencsw.org is running both that and 1.11.23. Should > all work fine theoretically. > > It may be a problem with the proxy we need to use to get out from > opencsw.org, too. > > Olaf > > PS: I don't think cool user space file systems from Linux will help > us on Solaris systems, nor will opencsw.org change their general > setup and policies for us. > > > Probably will be a lot easier with some special techniques like this ones > > I assume you're not able to do that but just in case you do sshfs: > > http://www.linux-mag.com/id/7820 > > How critical is this process for it? see suggestions for it see > > pages 34 and 42 about centralizing control over files in contrast of > > distributed and the efficiency in I/O transmission and suggestions > > for improving it in a white "paper" book of "The Shortcut guide to > > Eliminating Insecure > > and Unreliable File Transfer Methods" if that might help (again just > > accept the security domain error and add the security exception) > > https://168.176.86.16/~danielb/SGEIU-complete.pdf > > downloaded from > > http://nexus.realtimepublishers.com/sgeiu.php > > you will need an account and take a survey on the topic if you might > > In such a case where you are allowed sshfs might be an interesting > > option it requires user space file system but if the performance is > > not critical perhaps we can think about it, can we, might be > > interesting for a windows setting, etc? > > > > Thanks in advance, hope it helps > > > > --- El mar, 10/8/10, Olaf Wagner escribi?: > > > >> De: Olaf Wagner > >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> Para: m3devel at elegosoft.com > >> Fecha: martes, 10 de agosto, 2010 08:33 > >> Quoting Olaf Wagner : > >> > >> > Quoting Dagobert Michelsen : > >> > > >> >> Hi Olaf, > >> >> > >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >> >>> Quoting Dagobert Michelsen : > >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf > >> Wagner: > >> >>>>> Currently I know of two other problems > >> running our builds and tests > >> >>>>> on the opencsw machines. > >> >>>>> > >> >>>>> 1. cvs update does not work on > >> current10x (Solaris on x86) when run from > >> >>>>> Hudson. > >> >>>>> It does work on current10s and > >> current9s. > >> >>>> > >> >>>> Interesting. current*s are all running on > >> the same physical > >> >>>> machine as zones, > >> >>>> whereas current*x are located on a vSphere > >> farm. Do you have a specific > >> >>>> command sequence which I can try to > >> reproduce the problem? > >> >>> > >> >>> I'm not yet able to reproduce it manually; I > >> only see it in the > >> >>> Hudson jobs (failing right away when computing > >> the changelog). > >> >>> > >> >>> If you want, I can setup a job for test > >> purposes and you can get > >> >>> Hudson access. > >> >> > >> >> I can't promise I can fix this but if you set > >> something up I may look > >> >> in the next few days. > >> > > >> > I finally managed to reproduce the problem in the > >> build step of > >> > a Hudson job, and got this after enabling tracing: > >> > > >> > -> rename(CVS/Entries.Backup,CVS/Entries) > >> > -> unlink_file(CVS/Entries.Log) > >> > cvs update: inflate: unknown compression method > >> > cvs [update aborted]: reading from server: I/O error > >> > -> Lock_Cleanup() > >> > Finished: FAILURE > >> > > >> > Is there a different/an older gzip library on > >> current10x? > >> > > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >> > > >> >>>> Are you using cvs stable (1.11.23) or > >> feature (1.12.13)? > >> >>> > >> >>> Stable. I'll try with 1.12.13, too (haven't > >> seen that around). > >> >>> Is it installed anywhere?? > >> >> > >> >> That is here: > >> >> /opt/csw/cvs-feature/bin/cvs > >> > >> 1.12.13 says > >> > >> cvs update: inflate: invalid distance too far back cvs > >> [update > >> aborted]: reading from server: I/O error > >> Finished: FAILURE > >> > >> Any ideas? > >> > >> 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 > >> > >> > > > > > > > > > > > > -- > 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 Thu Aug 12 05:27:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 12 Aug 2010 03:27:14 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, , , <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com>, , , Message-ID: I propose this is the next thing to try: - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. thereby removing -z3 from any jobs on this node, leaving all the rest unchanged. I realize $HOME/bin might not be it, but like $HOME/$(uname -n)/bin or such. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dabenavidesd at yahoo.es Date: Wed, 11 Aug 2010 23:42:39 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Hm, that this means by the way, I think, is the compressed data is not recognized as valid. e.g. it isn't -z3 being rejected, but the data from the server. Maybe the network is flaky and corrupting the data? That aside, I wonder if we could try -z1, -z2, -z4, -z5, etc. ay at xlin2:~/src/cvs-1.12.13/cvs-1.12.13$ grep "unknown compre" */* zlib/inflate.c: strm->msg = (char *)"unknown compression method"; zlib/inflate.c: strm->msg = (char *)"unknown compression method"; if (BITS(4) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } ... #ifdef GUNZIP case FLAGS: NEEDBITS(16); state->flags = (int)(hold); if ((state->flags & 0xff) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dabenavidesd at yahoo.es Date: Wed, 11 Aug 2010 16:10:24 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Olaf I think we should do a bit more research here, but I also think we have a few easy options. - build our own cvs, put it in $HOME/bin. - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. - Jay > Date: Wed, 11 Aug 2010 09:26:35 +0200 > From: wagner at elegosoft.com > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting "Daniel Alejandro Benavides D." : > > > Hi all: > > I was rethinking but it seems you caught a bug either inside > > opencsw.org or elego system (incompatible versions). > > There are no incompatible CVS versions. Birch is running 1.12.13, > and current9s.opencsw.org is running both that and 1.11.23. Should > all work fine theoretically. > > It may be a problem with the proxy we need to use to get out from > opencsw.org, too. > > Olaf > > PS: I don't think cool user space file systems from Linux will help > us on Solaris systems, nor will opencsw.org change their general > setup and policies for us. > > > Probably will be a lot easier with some special techniques like this ones > > I assume you're not able to do that but just in case you do sshfs: > > http://www.linux-mag.com/id/7820 > > How critical is this process for it? see suggestions for it see > > pages 34 and 42 about centralizing control over files in contrast of > > distributed and the efficiency in I/O transmission and suggestions > > for improving it in a white "paper" book of "The Shortcut guide to > > Eliminating Insecure > > and Unreliable File Transfer Methods" if that might help (again just > > accept the security domain error and add the security exception) > > https://168.176.86.16/~danielb/SGEIU-complete.pdf > > downloaded from > > http://nexus.realtimepublishers.com/sgeiu.php > > you will need an account and take a survey on the topic if you might > > In such a case where you are allowed sshfs might be an interesting > > option it requires user space file system but if the performance is > > not critical perhaps we can think about it, can we, might be > > interesting for a windows setting, etc? > > > > Thanks in advance, hope it helps > > > > --- El mar, 10/8/10, Olaf Wagner escribi?: > > > >> De: Olaf Wagner > >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> Para: m3devel at elegosoft.com > >> Fecha: martes, 10 de agosto, 2010 08:33 > >> Quoting Olaf Wagner : > >> > >> > Quoting Dagobert Michelsen : > >> > > >> >> Hi Olaf, > >> >> > >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >> >>> Quoting Dagobert Michelsen : > >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf > >> Wagner: > >> >>>>> Currently I know of two other problems > >> running our builds and tests > >> >>>>> on the opencsw machines. > >> >>>>> > >> >>>>> 1. cvs update does not work on > >> current10x (Solaris on x86) when run from > >> >>>>> Hudson. > >> >>>>> It does work on current10s and > >> current9s. > >> >>>> > >> >>>> Interesting. current*s are all running on > >> the same physical > >> >>>> machine as zones, > >> >>>> whereas current*x are located on a vSphere > >> farm. Do you have a specific > >> >>>> command sequence which I can try to > >> reproduce the problem? > >> >>> > >> >>> I'm not yet able to reproduce it manually; I > >> only see it in the > >> >>> Hudson jobs (failing right away when computing > >> the changelog). > >> >>> > >> >>> If you want, I can setup a job for test > >> purposes and you can get > >> >>> Hudson access. > >> >> > >> >> I can't promise I can fix this but if you set > >> something up I may look > >> >> in the next few days. > >> > > >> > I finally managed to reproduce the problem in the > >> build step of > >> > a Hudson job, and got this after enabling tracing: > >> > > >> > -> rename(CVS/Entries.Backup,CVS/Entries) > >> > -> unlink_file(CVS/Entries.Log) > >> > cvs update: inflate: unknown compression method > >> > cvs [update aborted]: reading from server: I/O error > >> > -> Lock_Cleanup() > >> > Finished: FAILURE > >> > > >> > Is there a different/an older gzip library on > >> current10x? > >> > > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >> > > >> >>>> Are you using cvs stable (1.11.23) or > >> feature (1.12.13)? > >> >>> > >> >>> Stable. I'll try with 1.12.13, too (haven't > >> seen that around). > >> >>> Is it installed anywhere?? > >> >> > >> >> That is here: > >> >> /opt/csw/cvs-feature/bin/cvs > >> > >> 1.12.13 says > >> > >> cvs update: inflate: invalid distance too far back cvs > >> [update > >> aborted]: reading from server: I/O error > >> Finished: FAILURE > >> > >> Any ideas? > >> > >> 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 > >> > >> > > > > > > > > > > > > -- > 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 wagner at elegosoft.com Thu Aug 12 09:12:07 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 09:12:07 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> Message-ID: <20100812091207.piy2cdcsiswoowg4@mail.elegosoft.com> Quoting Jay K : > Olaf I think we should do a bit more research here, but I also think > we have a few easy options. > > - build our own cvs, put it in $HOME/bin. > - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin > - drop in a stub cvs in $HOME/bin that remove the -z option and > then execs the "real" cvs, like how > we convince Hudson that our java -version is ok. These are not really easy, as we need to make Hudson running in the Winstone container started by ssh pick up the correct CVS. We don't want to start it explicitly in our jobs. But of course it can be done, I just haven't found the time to try. BTW, it is not evident that our self-built CVS would work better, especially, if the problem is really in the compressen library. I won't have time to do much until the weekend. Olaf > - Jay > >> Date: Wed, 11 Aug 2010 09:26:35 +0200 >> From: wagner at elegosoft.com >> To: dabenavidesd at yahoo.es >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Short status of CM3 Hudson regression >> testing on opencsw.org machines >> >> Quoting "Daniel Alejandro Benavides D." : >> >> > Hi all: >> > I was rethinking but it seems you caught a bug either inside >> > opencsw.org or elego system (incompatible versions). >> >> There are no incompatible CVS versions. Birch is running 1.12.13, >> and current9s.opencsw.org is running both that and 1.11.23. Should >> all work fine theoretically. >> >> It may be a problem with the proxy we need to use to get out from >> opencsw.org, too. >> >> Olaf >> >> PS: I don't think cool user space file systems from Linux will help >> us on Solaris systems, nor will opencsw.org change their general >> setup and policies for us. >> >> > Probably will be a lot easier with some special techniques like this ones >> > I assume you're not able to do that but just in case you do sshfs: >> > http://www.linux-mag.com/id/7820 >> > How critical is this process for it? see suggestions for it see >> > pages 34 and 42 about centralizing control over files in contrast of >> > distributed and the efficiency in I/O transmission and suggestions >> > for improving it in a white "paper" book of "The Shortcut guide to >> > Eliminating Insecure >> > and Unreliable File Transfer Methods" if that might help (again just >> > accept the security domain error and add the security exception) >> > https://168.176.86.16/~danielb/SGEIU-complete.pdf >> > downloaded from >> > http://nexus.realtimepublishers.com/sgeiu.php >> > you will need an account and take a survey on the topic if you might >> > In such a case where you are allowed sshfs might be an interesting >> > option it requires user space file system but if the performance is >> > not critical perhaps we can think about it, can we, might be >> > interesting for a windows setting, etc? >> > >> > Thanks in advance, hope it helps >> > >> > --- El mar, 10/8/10, Olaf Wagner escribi?: >> > >> >> De: Olaf Wagner >> >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing >> >> on opencsw.org machines >> >> Para: m3devel at elegosoft.com >> >> Fecha: martes, 10 de agosto, 2010 08:33 >> >> Quoting Olaf Wagner : >> >> >> >> > Quoting Dagobert Michelsen : >> >> > >> >> >> Hi Olaf, >> >> >> >> >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> >> >>> Quoting Dagobert Michelsen : >> >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf >> >> Wagner: >> >> >>>>> Currently I know of two other problems >> >> running our builds and tests >> >> >>>>> on the opencsw machines. >> >> >>>>> >> >> >>>>> 1. cvs update does not work on >> >> current10x (Solaris on x86) when run from >> >> >>>>> Hudson. >> >> >>>>> It does work on current10s and >> >> current9s. >> >> >>>> >> >> >>>> Interesting. current*s are all running on >> >> the same physical >> >> >>>> machine as zones, >> >> >>>> whereas current*x are located on a vSphere >> >> farm. Do you have a specific >> >> >>>> command sequence which I can try to >> >> reproduce the problem? >> >> >>> >> >> >>> I'm not yet able to reproduce it manually; I >> >> only see it in the >> >> >>> Hudson jobs (failing right away when computing >> >> the changelog). >> >> >>> >> >> >>> If you want, I can setup a job for test >> >> purposes and you can get >> >> >>> Hudson access. >> >> >> >> >> >> I can't promise I can fix this but if you set >> >> something up I may look >> >> >> in the next few days. >> >> > >> >> > I finally managed to reproduce the problem in the >> >> build step of >> >> > a Hudson job, and got this after enabling tracing: >> >> > >> >> > -> rename(CVS/Entries.Backup,CVS/Entries) >> >> > -> unlink_file(CVS/Entries.Log) >> >> > cvs update: inflate: unknown compression method >> >> > cvs [update aborted]: reading from server: I/O error >> >> > -> Lock_Cleanup() >> >> > Finished: FAILURE >> >> > >> >> > Is there a different/an older gzip library on >> >> current10x? >> >> > >> >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console >> >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >> >> > >> >> >>>> Are you using cvs stable (1.11.23) or >> >> feature (1.12.13)? >> >> >>> >> >> >>> Stable. I'll try with 1.12.13, too (haven't >> >> seen that around). >> >> >>> Is it installed anywhere?? >> >> >> >> >> >> That is here: >> >> >> /opt/csw/cvs-feature/bin/cvs >> >> >> >> 1.12.13 says >> >> >> >> cvs update: inflate: invalid distance too far back cvs >> >> [update >> >> aborted]: reading from server: I/O error >> >> Finished: FAILURE >> >> >> >> Any ideas? >> >> >> >> 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 >> >> >> >> >> > >> > >> > >> > >> >> >> >> -- >> 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 >> > -- 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 Thu Aug 12 09:14:19 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 09:14:19 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, , <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com>, Message-ID: <20100812091419.etw0y1yngo0ccosg@mail.elegosoft.com> We can try anything from the command line or via a build step in a Hudson job, but the configuration options for CVS in Hudson are rather limited. At least at this level... Olaf Quoting Jay K : > Hm, that this means by the way, I think, is the compressed data is > not recognized as valid. e.g. it isn't -z3 being rejected, but the > data from the server. > Maybe the network is flaky and corrupting the data? > > That aside, I wonder if we could try -z1, -z2, -z4, -z5, etc. > > ay at xlin2:~/src/cvs-1.12.13/cvs-1.12.13$ grep "unknown compre" */* > zlib/inflate.c: strm->msg = (char *)"unknown > compression method"; > zlib/inflate.c: strm->msg = (char *)"unknown > compression method"; > > > if (BITS(4) != Z_DEFLATED) { > strm->msg = (char *)"unknown compression method"; > state->mode = BAD; > break; > } > ... > #ifdef GUNZIP > case FLAGS: > NEEDBITS(16); > state->flags = (int)(hold); > if ((state->flags & 0xff) != Z_DEFLATED) { > strm->msg = (char *)"unknown compression method"; > state->mode = BAD; > break; > } > > > > - Jay > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; dabenavidesd at yahoo.es > Date: Wed, 11 Aug 2010 16:10:24 +0000 > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing > on opencsw.org machines > > > > > > > > > Olaf I think we should do a bit more research here, but I also think > we have a few easy options. > > - build our own cvs, put it in $HOME/bin. > - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin > - drop in a stub cvs in $HOME/bin that remove the -z option and > then execs the "real" cvs, like how > we convince Hudson that our java -version is ok. > > - Jay > >> Date: Wed, 11 Aug 2010 09:26:35 +0200 >> From: wagner at elegosoft.com >> To: dabenavidesd at yahoo.es >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Short status of CM3 Hudson regression >> testing on opencsw.org machines >> >> Quoting "Daniel Alejandro Benavides D." : >> >> > Hi all: >> > I was rethinking but it seems you caught a bug either inside >> > opencsw.org or elego system (incompatible versions). >> >> There are no incompatible CVS versions. Birch is running 1.12.13, >> and current9s.opencsw.org is running both that and 1.11.23. Should >> all work fine theoretically. >> >> It may be a problem with the proxy we need to use to get out from >> opencsw.org, too. >> >> Olaf >> >> PS: I don't think cool user space file systems from Linux will help >> us on Solaris systems, nor will opencsw.org change their general >> setup and policies for us. >> >> > Probably will be a lot easier with some special techniques like this ones >> > I assume you're not able to do that but just in case you do sshfs: >> > http://www.linux-mag.com/id/7820 >> > How critical is this process for it? see suggestions for it see >> > pages 34 and 42 about centralizing control over files in contrast of >> > distributed and the efficiency in I/O transmission and suggestions >> > for improving it in a white "paper" book of "The Shortcut guide to >> > Eliminating Insecure >> > and Unreliable File Transfer Methods" if that might help (again just >> > accept the security domain error and add the security exception) >> > https://168.176.86.16/~danielb/SGEIU-complete.pdf >> > downloaded from >> > http://nexus.realtimepublishers.com/sgeiu.php >> > you will need an account and take a survey on the topic if you might >> > In such a case where you are allowed sshfs might be an interesting >> > option it requires user space file system but if the performance is >> > not critical perhaps we can think about it, can we, might be >> > interesting for a windows setting, etc? >> > >> > Thanks in advance, hope it helps >> > >> > --- El mar, 10/8/10, Olaf Wagner escribi?: >> > >> >> De: Olaf Wagner >> >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing >> >> on opencsw.org machines >> >> Para: m3devel at elegosoft.com >> >> Fecha: martes, 10 de agosto, 2010 08:33 >> >> Quoting Olaf Wagner : >> >> >> >> > Quoting Dagobert Michelsen : >> >> > >> >> >> Hi Olaf, >> >> >> >> >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> >> >>> Quoting Dagobert Michelsen : >> >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf >> >> Wagner: >> >> >>>>> Currently I know of two other problems >> >> running our builds and tests >> >> >>>>> on the opencsw machines. >> >> >>>>> >> >> >>>>> 1. cvs update does not work on >> >> current10x (Solaris on x86) when run from >> >> >>>>> Hudson. >> >> >>>>> It does work on current10s and >> >> current9s. >> >> >>>> >> >> >>>> Interesting. current*s are all running on >> >> the same physical >> >> >>>> machine as zones, >> >> >>>> whereas current*x are located on a vSphere >> >> farm. Do you have a specific >> >> >>>> command sequence which I can try to >> >> reproduce the problem? >> >> >>> >> >> >>> I'm not yet able to reproduce it manually; I >> >> only see it in the >> >> >>> Hudson jobs (failing right away when computing >> >> the changelog). >> >> >>> >> >> >>> If you want, I can setup a job for test >> >> purposes and you can get >> >> >>> Hudson access. >> >> >> >> >> >> I can't promise I can fix this but if you set >> >> something up I may look >> >> >> in the next few days. >> >> > >> >> > I finally managed to reproduce the problem in the >> >> build step of >> >> > a Hudson job, and got this after enabling tracing: >> >> > >> >> > -> rename(CVS/Entries.Backup,CVS/Entries) >> >> > -> unlink_file(CVS/Entries.Log) >> >> > cvs update: inflate: unknown compression method >> >> > cvs [update aborted]: reading from server: I/O error >> >> > -> Lock_Cleanup() >> >> > Finished: FAILURE >> >> > >> >> > Is there a different/an older gzip library on >> >> current10x? >> >> > >> >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console >> >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >> >> > >> >> >>>> Are you using cvs stable (1.11.23) or >> >> feature (1.12.13)? >> >> >>> >> >> >>> Stable. I'll try with 1.12.13, too (haven't >> >> seen that around). >> >> >>> Is it installed anywhere?? >> >> >> >> >> >> That is here: >> >> >> /opt/csw/cvs-feature/bin/cvs >> >> >> >> 1.12.13 says >> >> >> >> cvs update: inflate: invalid distance too far back cvs >> >> [update >> >> aborted]: reading from server: I/O error >> >> Finished: FAILURE >> >> >> >> Any ideas? >> >> >> >> 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 >> >> >> >> >> > >> > >> > >> > >> >> >> >> -- >> 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 >> > -- 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 Thu Aug 12 10:18:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 10:18:15 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <4DBBF376-84FE-4A02-81C8-347275B2BD62@baltic-online.de> References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> <4DBBF376-84FE-4A02-81C8-347275B2BD62@baltic-online.de> Message-ID: <20100812101815.s0tusa6ji8wwokw0@mail.elegosoft.com> Quoting Dagobert Michelsen : > Hi Jay, > > Am 11.08.2010 um 18:10 schrieb Jay K: >> Olaf I think we should do a bit more research here, but I also >> think we have a few easy options. >> >> - build our own cvs, put it in $HOME/bin. > > I doubt that it would make a difference as the installed OpenCSW package is > build pretty much standard: > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/cvs/trunk/Makefile > >> - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin > > They should be bit-identical as it is the same package installed on > all machines of the same arch. > >> - drop in a stub cvs in $HOME/bin that remove the -z option and >> then execs the "real" cvs, like how >> we convince Hudson that our java -version is ok. > > Have you tried cvs-feature? In contrast to the /opt/csw/bin/cvs it is > linked against > libz explicitly: > > current10x% ldd /opt/csw/bin/cvs > libgss.so.1 => /usr/lib/libgss.so.1 > libkrb5.so.3 => /opt/csw/lib/i386/libkrb5.so.3 > libgen.so.1 => /lib/libgen.so.1 > libk5crypto.so.3 => /opt/csw/lib/i386/libk5crypto.so.3 > libcrypto.so.0.9.8 => /opt/csw/lib/pentium_pro/ libcrypto.so.0.9.8 > libcom_err.so.3 => /opt/csw/lib/i386/libcom_err.so.3 > libxnet.so.1 => /lib/libxnet.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libc.so.1 => /lib/libc.so.1 > libcmd.so.1 => /lib/libcmd.so.1 > libresolv.so.2 => /lib/libresolv.so.2 > libsocket.so.1 => /lib/libsocket.so.1 > libkrb5support.so.0 => /opt/csw/lib/libkrb5support.so.0 > libdl.so.1 => /lib/libdl.so.1 > libmp.so.2 => /lib/libmp.so.2 > libmd.so.1 => /lib/libmd.so.1 > libscf.so.1 => /lib/libscf.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libm.so.2 => /lib/libm.so.2 > > current10x% ldd /opt/csw/cvs-feature/bin/cvs > librt.so.1 => /lib/librt.so.1 > libintl.so.3 => /opt/csw/lib/i386/libintl.so.3 > libiconv.so.2 => /opt/csw/lib/i386/libiconv.so.2 > libc.so.1 => /lib/libc.so.1 > libgssapi_krb5.so.2 => /opt/csw/lib/i386/libgssapi_krb5.so.2 > libkrb5.so.3 => /opt/csw/lib/i386/libkrb5.so.3 > libgen.so.1 => /lib/libgen.so.1 > libk5crypto.so.3 => /opt/csw/lib/i386/libk5crypto.so.3 > libcrypto.so.0.9.8 => /opt/csw/lib/pentium_pro/ libcrypto.so.0.9.8 > libcom_err.so.3 => /opt/csw/lib/i386/libcom_err.so.3 > libnsl.so.1 => /lib/libnsl.so.1 > libsocket.so.1 => /lib/libsocket.so.1 > libz.so => /opt/csw/lib/pentium_pro+mmx/libz.so > libpam.so.1 => /lib/libpam.so.1 > libaio.so.1 => /lib/libaio.so.1 > libmd.so.1 => /lib/libmd.so.1 > libkrb5support.so.0 => /opt/csw/lib/libkrb5support.so.0 > libresolv.so.2 => /lib/libresolv.so.2 > libdl.so.1 => /lib/libdl.so.1 > libmp.so.2 => /lib/libmp.so.2 > libscf.so.1 => /lib/libscf.so.1 > libcmd.so.1 => /lib/libcmd.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libm.so.2 => /lib/libm.so.2 Neither 1.11.23 nor the feature version 1.12.13 work, see http://hudson.modula3.com:8080/view/zzz/job/opencsw10x-test/28/console If there are any more executables to try, we can easily do that via that Hudson job. I'd tend to support the idea of making Hudson use a CVS wrapper which eliminates the -z flag for update for the time being, until we have a better solution. After all, updates should only be small compared to initial checkouts, which work even with compression. All very strange. 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 Thu Aug 12 12:32:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 12:32:23 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Message-ID: <20100812123223.gu47te0g0488gk4c@mail.elegosoft.com> FYI With this change from Jay http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/22/changes we got the first snapshot archive built on Solaris 2.9: http://www.modula3.com/cm3/snaps/cm3-bin-core-SOLsun-d5.9.0-sparc-sun-solaris2.9-2010-08-12-09-40-37.tgz Olaf PS: Tinderbox regression is completely broken currently though, but that must be related to the change of the development line from release branch to trunk as default again. Quoting Dagobert Michelsen : > Hi Olaf, > > Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> Quoting Dagobert Michelsen : >>> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>>> Currently I know of two other problems running our builds and tests >>>> on the opencsw machines. >>>> >>>> 1. cvs update does not work on current10x (Solaris on x86) when run from >>>> Hudson. >>>> It does work on current10s and current9s. >>> >>> Interesting. current*s are all running on the same physical >>> machine as zones, >>> whereas current*x are located on a vSphere farm. Do you have a specific >>> command sequence which I can try to reproduce the problem? >> >> I'm not yet able to reproduce it manually; I only see it in the >> Hudson jobs (failing right away when computing the changelog). >> >> If you want, I can setup a job for test purposes and you can get >> Hudson access. > > I can't promise I can fix this but if you set something up I may look > in the next few days. > >>> Are you using cvs stable (1.11.23) or feature (1.12.13)? >> >> Stable. I'll try with 1.12.13, too (haven't seen that around). >> Is it installed anywhere?? > > That is here: > /opt/csw/cvs-feature/bin/cvs > > > Best regards > > -- Dago -- 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 Thu Aug 12 15:36:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 15:36:42 +0200 Subject: [M3devel] Thread hangs on Solaris 2.9 Message-ID: <20100812153642.vpiofd7vvyssgks4@mail.elegosoft.com> There seems to be a rather extended LongPause in m3tests on Solaris 2.9: [...] --- p037 --- tests Time.LongPause cd ../src/p0/p037 && cm3 -silent -DM3TESTS >SOLsun/stdout.build.raw 2>SOLsun/stderr.build.raw [endless rotation icon here :-)] see http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-SOLsun-opencsw-current9s/8/console 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 Thu Aug 12 20:42:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 20:42:42 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Message-ID: <20100812204242.tk9wlc7f480skw8c@mail.elegosoft.com> I have done that now which seems to work: -bash-4.1$ cat ~/bin/cvs #!/bin/sh CVSEXE=/opt/csw/cvs-feature/bin/cvs if [ ! -x $CVSEXE ]; then CVSEXE=/opt/csw/bin/cvs fi if [ ! -x $CVSEXE ]; then echo "$CVSEXE not executable" 1>&2 exit 1 fi if [ `uname -n` = "current10x" ]; then args=`echo "$@" | sed -e 's/-z3 update/update/'` echo "$CVSEXE $args" exec $CVSEXE $args else echo "$CVSEXE $@" exec $CVSEXE $@ fi 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 Aug 12 23:32:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 12 Aug 2010 21:32:37 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100812204242.tk9wlc7f480skw8c@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com>, , <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com>, <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org>, <20100812204242.tk9wlc7f480skw8c@mail.elegosoft.com> Message-ID: Please check it in where I put the python/java wrapper, thanks. - Jay > Date: Thu, 12 Aug 2010 20:42:42 +0200 > From: wagner at elegosoft.com > To: dam at opencsw.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > I have done that now which seems to work: > > -bash-4.1$ cat ~/bin/cvs > #!/bin/sh > > CVSEXE=/opt/csw/cvs-feature/bin/cvs > > if [ ! -x $CVSEXE ]; then > CVSEXE=/opt/csw/bin/cvs > fi > if [ ! -x $CVSEXE ]; then > echo "$CVSEXE not executable" 1>&2 > exit 1 > fi > if [ `uname -n` = "current10x" ]; then > args=`echo "$@" | sed -e 's/-z3 update/update/'` > echo "$CVSEXE $args" > exec $CVSEXE $args > else > echo "$CVSEXE $@" > exec $CVSEXE $@ > fi > > 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 Sat Aug 14 00:59:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 13 Aug 2010 22:59:02 +0000 Subject: [M3devel] fs_rmrec In-Reply-To: <20100813220727.EAD51CC88D@birch.elegosoft.com> References: <20100813220727.EAD51CC88D@birch.elegosoft.com> Message-ID: Olaf, to be sure/clear -- fs_rmrec works now, right? The original and long-term problem was that deleting, or even, enumerating, stale symlinks would fail. There *may* have been a problem around keeping multiple DIRs open at a time and/or deleting while enumerating. My addressing the later concerns, and using fs_rmrec in m3-sys/m3cc, both exacerbated the problem due to the ordering of enumeration and deletion and the layout of m3-sys/m3cc. In either case, I believe it works now, right? Understood that old cm3 remains broken, and intermediate cm3 remains sort of worse. What I mean by all these "sort ofs" is that we used to enumerate and delete "at the same time". Which made it somewhat indeterminate if the symlink or its target was deleted first. I changed the code to delete files, and then directories. Given a symlink like "bar/foo => ../foo", ./foo would be guaranteeably deleted ahead of the symlink pointing to it. - Jay > Date: Sat, 14 Aug 2010 00:07:27 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 10/08/14 00:07:27 > > Modified files: > cm3/m3-sys/m3tests/src/: m3makefile > > Log message: > wrong again, another attempt: fix rmrec for NT386 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 14 13:10:07 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 14 Aug 2010 13:10:07 +0200 Subject: [M3devel] fs_rmrec In-Reply-To: References: <20100813220727.EAD51CC88D@birch.elegosoft.com> Message-ID: <20100814131007.520xyqx42ok0oo48@mail.elegosoft.com> Quoting Jay K : > Olaf, to be sure/clear -- fs_rmrec works now, right? I thought so, too, but... > The original and long-term problem was that deleting, or even, > enumerating, stale symlinks > would fail. There *may* have been a problem around keeping multiple > DIRs open at a time > and/or deleting while enumerating. My addressing the later concerns, > and using fs_rmrec > in m3-sys/m3cc, both exacerbated the problem due to the ordering of > enumeration and deletion > and the layout of m3-sys/m3cc. > > In either case, I believe it works now, right? I observed several failures in tests. Let's see if I can find some: Here is one: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-I386_SOLARIS-opencsw-current10x/11/console Perhaps the cm3 used there was still too old? I'm sure there were more, but I cannot find them right now. If you're sure it's fixed, we can try it again, no problem. What about the hanging test p037 on Solaris 2.9 though? See http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-SOLsun-opencsw-current9s/8/console Any ideas? Olaf > Understood that old cm3 remains broken, and intermediate cm3 remains > sort of worse. > > > What I mean by all these "sort ofs" is that we used to enumerate and > delete "at the same time". > Which made it somewhat indeterminate if the symlink or its target > was deleted first. > I changed the code to delete files, and then directories. > Given a symlink like "bar/foo => ../foo", ./foo would be > guaranteeably deleted ahead > of the symlink pointing to it. > > - 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 jay.krell at cornell.edu Sat Aug 14 20:51:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 14 Aug 2010 18:51:20 +0000 Subject: [M3devel] fs_rmrec In-Reply-To: <20100814131007.520xyqx42ok0oo48@mail.elegosoft.com> References: <20100813220727.EAD51CC88D@birch.elegosoft.com>, , <20100814131007.520xyqx42ok0oo48@mail.elegosoft.com> Message-ID: > What about the hanging test p037 on Solaris 2.9 though? Oops, right. Perhaps we don't use -lpthread and perhaps we need to. Or perhaps 2.9 uses M:N user:kernel threads and perhaps our code doesn't work with that. Needs some investigation. Tony do you know by chance if the semaphore "parking in signal handler" pthreads code has been used on pre-2.10 Solaris? - Jay > Date: Sat, 14 Aug 2010 13:10:07 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] fs_rmrec > > Quoting Jay K : > > > Olaf, to be sure/clear -- fs_rmrec works now, right? > > I thought so, too, but... > > > The original and long-term problem was that deleting, or even, > > enumerating, stale symlinks > > would fail. There *may* have been a problem around keeping multiple > > DIRs open at a time > > and/or deleting while enumerating. My addressing the later concerns, > > and using fs_rmrec > > in m3-sys/m3cc, both exacerbated the problem due to the ordering of > > enumeration and deletion > > and the layout of m3-sys/m3cc. > > > > In either case, I believe it works now, right? > > I observed several failures in tests. > Let's see if I can find some: > > Here is one: > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-I386_SOLARIS-opencsw-current10x/11/console > > Perhaps the cm3 used there was still too old? > I'm sure there were more, but I cannot find them right now. > > If you're sure it's fixed, we can try it again, no problem. > > What about the hanging test p037 on Solaris 2.9 though? > See > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-SOLsun-opencsw-current9s/8/console > > Any ideas? > > Olaf > > > Understood that old cm3 remains broken, and intermediate cm3 remains > > sort of worse. > > > > > > What I mean by all these "sort ofs" is that we used to enumerate and > > delete "at the same time". > > Which made it somewhat indeterminate if the symlink or its target > > was deleted first. > > I changed the code to delete files, and then directories. > > Given a symlink like "bar/foo => ../foo", ./foo would be > > guaranteeably deleted ahead > > of the symlink pointing to it. > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 15 08:53:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 15 Aug 2010 06:53:25 +0000 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: <7D2B9349-BCBA-46DE-8465-F50EEBB70F22@cs.purdue.edu> References: , <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu>, , <7D2B9349-BCBA-46DE-8465-F50EEBB70F22@cs.purdue.edu> Message-ID: [old, was going through mail for another reason] btw, treelang is gone in later gcc releases, e.g. 4.5. I think I read they didn't want to maintain it any longer. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 29 Jun 2009 12:01:16 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pruning m3cc/gcc? > > Please leave treelang. It is a good model for building gcc IR trees > as done by cm3cg. > > On 29 Jun 2009, at 10:42, Jay wrote: > > > > > Ok, presumably then ok to prune it just partly, like intl, libssp, > > libmudflap, libgomp, treelang, beyond that (fixincludes, libgcc) > > would require some checking/testing. Might even be worthwhile to > > "simplify" the m3makefile and reach a compromise that works only by > > some deletion. > > Really I wish somehow gmp/mpfr built more quickly. I often delete > > their source locally but can't commit that. > > > > - Jay > > > > ________________________________ > >> From: hosking at cs.purdue.edu > >> To: jay.krell at cornell.edu > >> Date: Mon, 29 Jun 2009 09:41:09 -0400 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] pruning m3cc/gcc? > >> > >> I personally like having the ability to build C from the same > >> source tree. It's useful for debugging the backend sometimes > >> (looking at the equivalent code generated from C). > >> > >> On 28 Jun 2009, at 23:38, Jay wrote: > >> > >> > >> I keep thinking of deleting > >> > >> m3-sys/m3cc/gcc/intl > >> m3-sys/m3cc/gcc/libgomp > >> m3-sys/m3cc/gcc/libmudflap > >> m3-sys/m3cc/gcc/libssp > >> m3-sys/m3cc/gcc/fixincludes > >> m3-sys/m3cc/gcc/libgcc > >> > >> > >> We don't use any of it. > >> Some of these deletions would shorten our build command lines. > >> Though some (esp. fixincludes and maybe libgcc) might break the > >> shortest configure + make that the "real" cm3 doesn't use but can > >> be useful. > >> > >> > >> I didn't include them in gcc-interix and gcc-apple. > >> > >> > >> But there are two possible contradictory goals: > >> > >> > >> - just have what we use/change > >> - have a complete merged gcc tree from which you > >> could build gcc/cc1 and not just cm3cg > >> Except we don't have C++, Java, Ada, Fortran, > >> so we don't really have this, but C probably counts for something. > >> > >> > >> If the second is the goal, don't delete. > >> If the first is the goal, delete. > >> > >> > >> There is also "having it all there in case it is needed > >> or somesuch", but that's easy enough to get elsewhere. > >> > >> > >> - Jay > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 15 05:31:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 15 Aug 2010 03:31:19 +0000 Subject: [M3devel] quake and/or "short circuit" Message-ID: It would have been nice for and/or to short circuit in quake like they do in C. Code like: if not defined("TARGET") readonly TARGET = "I386_FREEBSD" else if not equal(TARGET, "FreeBSD4") readonly TARGET = "I386_FREEBSD" end end is better written as: if not defined("TARGET") or not equal(TARGET, "FreeBSD4") readonly TARGET = "I386_FREEBSD" end but that isn't allowed because equal() will complain that TARGET isn't defined. It probably can't fixed though, due to e.g.: if TRUE or DoSomething() ... end would be broken. perhaps OR and AND or short_circuit_and or and_shorted or and_short_circuit or and_early_out or and_early or "&&" or something... Or I should just rewrite so much quake in Modula-3... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 16 09:55:04 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 16 Aug 2010 09:55:04 +0200 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: References: Message-ID: <20100816095504.29pg9d3dsgkwc00o@mail.elegosoft.com> You talk about `conditional and' and `conditional or'... I thought we had that in quake like in M3, but I might be mistaken. It should not be difficult to implement that though. Using it will be difficult until we've had a release which contains it... Olaf Quoting Jay K : > It would have been nice for and/or to short circuit in quake like > they do in C. > > > Code like: > > if not defined("TARGET") > readonly TARGET = "I386_FREEBSD" > else > if not equal(TARGET, "FreeBSD4") > readonly TARGET = "I386_FREEBSD" > end > end > > > is better written as: > if not defined("TARGET") or not equal(TARGET, "FreeBSD4") > readonly TARGET = "I386_FREEBSD" > end > > but that isn't allowed because equal() will complain that TARGET > isn't defined. > > It probably can't fixed though, due to e.g.: > > if TRUE or DoSomething() > ... > end > > > would be broken. > > > perhaps > OR and AND > or short_circuit_and > or and_shorted > or and_short_circuit > or and_early_out > or and_early > or "&&" > or something... > > > Or I should just rewrite so much quake in Modula-3... > > > - 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 jay.krell at cornell.edu Tue Aug 17 21:02:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 19:02:06 +0000 Subject: [M3devel] coverage of -O1, -O2, -O3, etc.? Message-ID: Anyone have ideas on getting coverage of various switches? Lately I use -O3 -Wuninitialized always. But that isn't exhaustive and doesn't get coverage in Hudson. And it isn't cheap for me. The "old" way was that I never used any optimization. I'm very likely paying more time to run the optimizer than that the optimizer saves. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 17 22:44:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 20:44:19 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: ,,, , , ,,, , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu>, , , , , Message-ID: I forgot about this. I never resolved it. Things seem to work though. ? - Jay > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 06:38:05 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > > I don't know. There is so much unknown here. It is frustrating and difficult. > We could use an extensive set of test cases. > Or know more about the test cases we do have. > And it'd be nice to see if anything varies in the 4.3 path if we put the labels on that list or not. > > tangent: > > I'd like automation that compiles the whole system, multiple architectures, and puts all the *s files in one flat > directory per architecture. I guess it's just a matter of a little code. > It should just skip the few errors that are cross problems, which I should fix anyway. > That particular problem makes me a little nervous, but I suppose I can code it to use both INTEGER and Target.Int > if doing a native build, and assert that the results match. > I hit a snag yesterday, can't build any tests (just to assembly) without first shipping m3core/libm3. > Can't ship m3core/libm3 for cross building. > I guess, and I forgot this, I should have used -x for override. Duh. > That's why I tried I386_DARWIN for some current 4.5 problems vs. SOLgnu, to escape cross building. Oops. > > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Mon, 12 Jul 2010 09:43:01 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] barrier labels? > > > > Perhaps we just need FORCED_LABEL for these: > > > > /* In a LABEL_DECL, nonzero means this label had its address taken > > and therefore can never be deleted and is a jump target for > > computed gotos. */ > > > > > > On 11 Jul 2010, at 23:03, Jay K wrote: > > > > > > > > I still don't see it, in the C++ frontend. > > > > > > There is: > > > > > > void > > > expand_label (tree label) > > > { > > > ... > > > if (DECL_NONLOCAL (label)) > > > { > > > ... nonlocal_goto_handler_labels > > > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > > > nonlocal_goto_handler_labels); > > > } > > > > > > but I don't think this works until later. > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sun, 11 Jul 2010 20:52:25 -0400 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] barrier labels? > > >> > > >> No, that code came from 4.x... > > >> > > >> > > >> > > >> > > >> On 11 Jul 2010, at 19:41, Jay K wrote: > > >> > > >>> > > >>> Tony, thanks for the pointer..though I haven't been able to find it yet. > > >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > > >>> > > >>> - Jay > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 > > >>>> To: jay.krell at cornell.edu > > >>>> CC: m3devel at elegosoft.com > > >>>> Subject: Re: [M3devel] barrier labels? > > >>>> > > >>>> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > > >>>> > > >>>> On 11 Jul 2010, at 07:46, Jay K wrote: > > >>>> > > >>>>> > > >>>>> Tony, six years ago you introduce what is now: > > >>>>> > > >>>>> > > >>>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > >>>>> > > >>>>> > > >>>>> static void > > >>>>> m3cg_set_label (void) > > >>>>> { > > >>>>> ... > > >>>>> if (barrier) > > >>>>> { > > >>>>> ... > > >>>>> { > > >>>>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > > >>>>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > > >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > > >>>>> } > > >>>>> ... > > >>>>> > > >>>>> > > >>>>> I'm not sure what to do here for gcc 4.5. > > >>>>> The data has moved around and isn't available this early. I suppose we could hang some information on and > > >>>>> deal with it later in compilation. > > >>>>> > > >>>>> > > >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > > >>>>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > > >>>>> > > >>>>> > > >>>>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > > >>>>> And Juno/mentor/tetris work without optimization, I'll test optimized later. > > >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. > > >>>>> > > >>>>> > > >>>>> Do we have good exception handling tests? > > >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > > >>>>> > > >>>>> > > >>>>> I'll poke around more.. > > >>>>> > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>> > > >>> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 17 22:47:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 20:47:36 +0000 Subject: [M3devel] gcc 4.5 In-Reply-To: References: Message-ID: This is moving along now. I've moved a few targets to 4.5.1 already. Some targets I haven't tested yet. Some have problems and I've held them back pending investigation. In some cases I compromise, e.g. turning off optimization on ALPHA_OSF. Eventually I might move some forward without testing. Generally I cross build, then self build, and startup some GUI apps. Though my X server is presently broken. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: gcc 4.5 > Date: Sun, 11 Jul 2010 23:51:43 +0000 > > > I'm inclined to make gcc 4.5 the default backend very soon. > AMD64_DARWIN, I386_LINUX, SOLgnu are looking ok. > I could also test PPC, like PPC_LINUX. > > SOLgnu leaves everything volatile (same as 4.3) so maybe isn't much validation. > > I doubt there is much value in testing other operating systems, mainly just other processors. > Though there is sometimes, e.g. I think I386_DARWIN uses sse for floating point and other I386 systems don't. > I should also test SPARC_LINUX to get sparc w/o volatile. > > > There are many other targets. OpenBSD, NetBSD, FreeBSD, OSF/1, I386/AMD64_SOLARIS, ARMEL_LINUX, Cygwin, MinGW, etc. > Others can test them? > > > There is some downside, in particular I disable more optimization at -O3 than with gcc 4.3. > One of the additional optimizations perhaps doesn't exist in 4.3 though. > > > The label/barrier thing still isn't resolved. > I haven't run through m3-sys/m3tests. > > > But that the system can build itself is a good sign, though sometimes I overvalue it. > And I tested some gui apps at least unoptimized. > The "man vs. boy" test works. > > > The 4.3 backend will remain available via cm3 -DGCC43 in the m3cc directory. > You have to be careful about cm3cfg.common probing around and finding the intended one, > such as by deleting all others. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 17 23:20:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 21:20:01 +0000 Subject: [M3devel] TimePosix__ComputeGrain Message-ID: I have now often seen cm3 hang starting up. Here: (gdb) bt #0 0x000003ff8010aed8 in gettimeofday64 () from /usr/shlib/libc.so #1 0x00000001205168a4 in TimePosix__Now () at ../src/time/POSIX/TimePosixC.c:41 #2 0x0000000120516924 in ComputeGrainOnce () at ../src/time/POSIX/TimePosixC.c:61 #3 0x0000000120516990 in TimePosix__ComputeGrain () at ../src/time/POSIX/TimePosixC.c:77 #4 0x00000001204ef344 in TimePosix_M3 ( M3_AcxOUs_mode=) at ../src/time/POSIX/TimePosix.m3:18 #5 0x00000001204c94f0 in RTLinker__RunMainBody ( I have adjusted the code to I believe guarantee forward progress. Some versions of mine did not. Ideas? Better portable ways to write it? It hangs a large fraction of the time on Alpha/OSF for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Aug 17 23:56:52 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 17 Aug 2010 23:56:52 +0200 Subject: [M3devel] [M3commit] "change outside commit" In-Reply-To: References: Message-ID: <20100817235652.tbbwe9lcnc44oggc@mail.elegosoft.com> Quoting Jay K : > same thing here: > > http://hudson.modula3.com:8080/job/cm3-current-build-I386_DARWIN/19/console > > - Jay > > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com > Date: Tue, 17 Aug 2010 20:40:37 +0000 > Subject: [M3commit] "change outside commit" > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-AMD64_DARWIN/6/console > > +"/Users/hudson/work/cm3-inst/jbook2/AMD64_DARWIN/last-ok/bin/config/Darwin.common", line 258: quake runtime error: undefined variable: > SYSTEM_CC > > To deal with that, I manually edited > /Users/hudson/work/cm3-inst/jbook2/AMD64_DARWIN/last-ok/bin/config/Darwin.common > to more closely resemble current source. > > I don't know if merely having commited fixes works here. It is OK for now to manually repair installations in ~/work/cm3-inst. Sometimes broken things get installed, though I've tried to improve the scripts; but some things are just too difficult to implement (wrt. atomicity and concurrency). The problem is that it takes too much time to investigate and understand each failure of a CM3 regression run. I can only do that now and then. I'll keep improving things 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 mika at async.async.caltech.edu Wed Aug 18 00:27:04 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 17 Aug 2010 15:27:04 -0700 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: References: Message-ID: <20100817222704.B3ABE1A209B@async.async.caltech.edu> If you really want it, you can always introduce "cand" and "cor" for the short-circuit versions. Dijkstra advises against it, though. Mika Jay K writes: >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >It would have been nice for and/or to short circuit in quake like they do i= >n C. > > >Code like: > >if not defined("TARGET") > readonly TARGET =3D "I386_FREEBSD" >else > if not equal(TARGET=2C "FreeBSD4") > readonly TARGET =3D "I386_FREEBSD" > end >end > > >is better written as: >if not defined("TARGET") or not equal(TARGET=2C "FreeBSD4") > readonly TARGET =3D "I386_FREEBSD" >end > >but that isn't allowed because equal() will complain that TARGET isn't defi= >ned. > >It probably can't fixed though=2C due to e.g.: > >if TRUE or DoSomething() > ... >end > > >would be broken. > > >perhaps >OR and AND >or short_circuit_and >or and_shorted >or and_short_circuit >or and_early_out >or and_early >or "&&" >or something... > > >Or I should just rewrite so much quake in Modula-3... > > > - Jay > = > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >It would have been nice for and/or to short circuit in quake like they do i= >n C.


Code like:

if not defined("TARGET")
 =3B read= >only TARGET =3D "I386_FREEBSD"
else
 =3B if not equal(TARGET=2C "= >FreeBSD4")
 =3B =3B =3B readonly TARGET =3D "I386_FREEBSD"r> =3B end
end


is better written as:
if not defined("T= >ARGET") or not equal(TARGET=2C "FreeBSD4")
 =3B readonly TARGET =3D = >"I386_FREEBSD"
end

but that isn't allowed because equal() will co= >mplain that TARGET isn't defined.

It probably can't fixed though=2C = >due to e.g.:

if TRUE or DoSomething()
 =3B ...
end

= >
would be broken.


perhaps
OR and AND
or short_circuit_a= >nd
or and_shorted
or and_short_circuit
or and_early_out
or and_= >early
or "&=3B&=3B"
or something...


Or I should just= > rewrite so much quake in Modula-3...


 =3B- Jay
> = > >= > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_-- From hendrik at topoi.pooq.com Wed Aug 18 01:59:01 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 17 Aug 2010 19:59:01 -0400 Subject: [M3devel] dbxout_static_chain_decl? In-Reply-To: <20100528220400.GB4904@topoi.pooq.com> References: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu> <4BFF15CE.7060908@lcwb.coop> <20100528220400.GB4904@topoi.pooq.com> Message-ID: <20100817235900.GB29080@topoi.pooq.com> On Fri, May 28, 2010 at 06:04:01PM -0400, hendrik at topoi.pooq.com wrote: > > In Algol 68, when it's implemented using static links, the static chain > doesn't thread *all* the chain of surrounding procedures -- it skips the > ones that don't define any names used in the inner ones. > > This bit of denesting might improve efficiency even in Modula 3, since > some static chains might end up being shorter. Whether it's worth the > effort is another question, of course. I should perhaps have mentioned that this behaviour is *required* by the Alcol 68 language definition. Not required by Modula 3, where what you can do with local procedures is more restricted. -- hendrik From jay.krell at cornell.edu Wed Aug 18 03:19:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 18 Aug 2010 01:19:48 +0000 Subject: [M3devel] FW: clock_getres / Time.Grain. In-Reply-To: <20100817213538.760482474033@birch.elegosoft.com> References: <20100817213538.760482474033@birch.elegosoft.com> Message-ID: This needs a review. Folks need to read Posix, the Modula-3 *.i3 files, possibly the OS man pages. Possibly run the two versions and compare. Possibly only #ifdef it in when the compare similar, e.g. on OSF and leave the rest alone. Possibly only use the timeofday timer and not the highres timer. Thanks, - Jay > Date: Tue, 17 Aug 2010 23:35:38 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/17 23:35:37 > > Modified files: > cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c > > Log message: > Let's try clock_getres if it is available. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Aug 18 03:17:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 18 Aug 2010 01:17:02 +0000 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: <20100817222704.B3ABE1A209B@async.async.caltech.edu> References: , <20100817222704.B3ABE1A209B@async.async.caltech.edu> Message-ID: I don't know what the names should be, I'm pretty comfortable with "&&" and "||". Short circuiting is very useful. > Dijkstra advises against it, though. That makes me question Dijkstra, not short circuiting. Also useful is assignment being an expression. I wish it was in Modula-3. Such things as: if ((f = fopen(..)) && fread(f,...) or if (p && *p) In the first case Modula-3 forces useless verbosity and indentation. In the second case Modula-3 gets it right but Quake fails. Lacking these features you end up contorting your code one way or another, such as duplicating things. I really can't stand code that looks like: result = do something if success(result) do more stuff if success do more stuff if succes do more stuff Modula-3 this wrong. Exceptions help. But basically I want to be able to introduce WITH or VAR anywhere, but not need to "END" them, and therefore no implied need for indentation.. - Jay > To: jay.krell at cornell.edu > Date: Tue, 17 Aug 2010 15:27:04 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] quake and/or "short circuit" > > If you really want it, you can always introduce "cand" and "cor" for > the short-circuit versions. > > Dijkstra advises against it, though. > > Mika > > Jay K writes: > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >It would have been nice for and/or to short circuit in quake like they do i= > >n C. > > > > > >Code like: > > > >if not defined("TARGET") > > readonly TARGET =3D "I386_FREEBSD" > >else > > if not equal(TARGET=2C "FreeBSD4") > > readonly TARGET =3D "I386_FREEBSD" > > end > >end > > > > > >is better written as: > >if not defined("TARGET") or not equal(TARGET=2C "FreeBSD4") > > readonly TARGET =3D "I386_FREEBSD" > >end > > > >but that isn't allowed because equal() will complain that TARGET isn't defi= > >ned. > > > >It probably can't fixed though=2C due to e.g.: > > > >if TRUE or DoSomething() > > ... > >end > > > > > >would be broken. > > > > > >perhaps > >OR and AND > >or short_circuit_and > >or and_shorted > >or and_short_circuit > >or and_early_out > >or and_early > >or "&&" > >or something... > > > > > >Or I should just rewrite so much quake in Modula-3... > > > > > > - Jay > > = > > > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >It would have been nice for and/or to short circuit in quake like they do i= > >n C.


Code like:

if not defined("TARGET")
 =3B read= > >only TARGET =3D "I386_FREEBSD"
else
 =3B if not equal(TARGET=2C "= > >FreeBSD4")
 =3B =3B =3B readonly TARGET =3D "I386_FREEBSD" >r> =3B end
end


is better written as:
if not defined("T= > >ARGET") or not equal(TARGET=2C "FreeBSD4")
 =3B readonly TARGET =3D = > >"I386_FREEBSD"
end

but that isn't allowed because equal() will co= > >mplain that TARGET isn't defined.

It probably can't fixed though=2C = > >due to e.g.:

if TRUE or DoSomething()
 =3B ...
end

= > >
would be broken.


perhaps
OR and AND
or short_circuit_a= > >nd
or and_shorted
or and_short_circuit
or and_early_out
or and_= > >early
or "&=3B&=3B"
or something...


Or I should just= > > rewrite so much quake in Modula-3...


 =3B- Jay
> > = > > > >= > > > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Aug 18 03:53:46 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 17 Aug 2010 21:53:46 -0400 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: References: <20100817222704.B3ABE1A209B@async.async.caltech.edu> Message-ID: <20100818015346.GB29274@topoi.pooq.com> On Wed, Aug 18, 2010 at 01:17:02AM +0000, Jay K wrote: > > I don't know what the names should be, I'm pretty comfortable with "&&" and "||". > Short circuiting is very useful. > > > Dijkstra advises against it, though. > > That makes me question Dijkstra, not short circuiting. He has specific reasons, having to do with programs being part of a logical calculus. In logic, 'and' and 'or' are both commutative, so he thinks it sim0plifies the formal calculus of programming to have them behave the same in programs. > > > Also useful is assignment being an expression. > I wish it was in Modula-3. So do I. > > Such things as: > > > if ((f = fopen(..)) && fread(f,...) > > > or if (p && *p) > > > In the first case Modula-3 forces useless verbosity and indentation. > In the second case Modula-3 gets it right but Quake fails. > > Lacking these features you end up contorting your code one way or another, such as duplicating things. > > > I really can't stand code that looks like: > > > result = do something > if success(result) > do more stuff > if success > do more stuff > if succes > do more stuff > > > Modula-3 this wrong. > Exceptions help. > But basically I want to be able to introduce WITH or VAR anywhere, but not need to "END" them, and therefore no implied need for indentation.. It looks as if you want Modula 3 with Algol 68 syntax. So do I. -- hendrik From jay.krell at cornell.edu Wed Aug 18 09:53:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 18 Aug 2010 07:53:12 +0000 Subject: [M3devel] FW: clock_getres / Time.Grain. In-Reply-To: References: <20100817213538.760482474033@birch.elegosoft.com>, Message-ID: Well, it seems clock_getres is either not available (Darwin) or varies much from the historical code (Linux, Solaris). So this is only for OSF/1 now. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 18 Aug 2010 01:19:48 +0000 Subject: [M3devel] FW: clock_getres / Time.Grain. This needs a review. Folks need to read Posix, the Modula-3 *.i3 files, possibly the OS man pages. Possibly run the two versions and compare. Possibly only #ifdef it in when the compare similar, e.g. on OSF and leave the rest alone. Possibly only use the timeofday timer and not the highres timer. Thanks, - Jay > Date: Tue, 17 Aug 2010 23:35:38 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/17 23:35:37 > > Modified files: > cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c > > Log message: > Let's try clock_getres if it is available. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Aug 18 19:24:39 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 18 Aug 2010 12:24:39 -0500 Subject: [M3devel] dbxout_static_chain_decl? In-Reply-To: <20100817235900.GB29080@topoi.pooq.com> References: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu> <4BFF15CE.7060908@lcwb.coop> <20100528220400.GB4904@topoi.pooq.com> <20100817235900.GB29080@topoi.pooq.com> Message-ID: <4C6C1757.9080005@lcwb.coop> hendrik at topoi.pooq.com wrote: > On Fri, May 28, 2010 at 06:04:01PM -0400, hendrik at topoi.pooq.com wrote: >> In Algol 68, when it's implemented using static links, the static chain >> doesn't thread *all* the chain of surrounding procedures -- it skips the >> ones that don't define any names used in the inner ones. >> >> This bit of denesting might improve efficiency even in Modula 3, since >> some static chains might end up being shorter. Whether it's worth the >> effort is another question, of course. Well, I'm going to keep beating this drum. Except for highly optimized compiles, I want the debugger to give a view that reflects what is declared. Even when a nonlocal variable is not referred do by any nested procedure, a debugger user (specifically, me) often wants to look at or even change such variables, when stopped inside a nested procedure. I do this a lot. Yes, you can always go up the dynamic call chain with debugger commands to get at them, but this sometimes costs a *lot* of extra time, especially if the nested procedure has called itself recursively umpteen times. Then you have to get back to the frame you were in. Then do it all again later. It's also often quite tricky to get right. All this diverts a lot of mental capacity from actually chasing the bug to how to work the debugger, just for a simple variable access that, by language rules, is visible from right were you are. Of course, it you choose a medium or high level of optimization, then using a debugger is already pretty much an exercise in futility anyway, for various other reasons, so in that case, I wouldn't fight it. > > I should perhaps have mentioned that this behaviour is *required* by the > Alcol 68 language definition. Not required by Modula 3, where what you > can do with local procedures is more restricted. > > -- hendrik > From jay.krell at cornell.edu Thu Aug 19 22:15:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 20:15:32 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson Message-ID: New Hudson node. A VM running on MacBook. ? We'll see if it stays on and if the network works. I386_NETBSD ssh -p 227 hudson at jayk.homedns.org To start, it has: ? /usr/pkg/java/openjdk7/bin/java ? /cm3/bin/cm3 ??? Actually a bunch in /cm3, you can get cm3cg, pkg/{m3core,libm3,etc.} there. ? /usr/pkg/bin/bash It is missing some libraries still so some "late" packages will fail. I haven't tested X apps, have to reboot the MacBook. ?And install more X libraries. AMD64_NETBSD later. I made a new node. Copied from openbsd-jkrell. jkrell-xnbsd. http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin ?- Jay ? From jay.krell at cornell.edu Thu Aug 19 22:32:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 20:32:40 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: ok, I put in a /usr/local/bin/java that Hudson likes. I cloned the m3cc/build/tests jobs from I386_OPENBSD. Not sure what is next, gotta run. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Thu, 19 Aug 2010 20:15:32 +0000 > Subject: [M3devel] VM for I386_NETBSD Hudson > > > New Hudson node. > A VM running on MacBook. > We'll see if it stays on and if the network works. > > I386_NETBSD > > ssh -p 227 hudson at jayk.homedns.org > > To start, it has: > /usr/pkg/java/openjdk7/bin/java > /cm3/bin/cm3 > Actually a bunch in /cm3, you can get cm3cg, pkg/{m3core,libm3,etc.} there. > /usr/pkg/bin/bash > > It is missing some libraries still so some "late" packages > will fail. > > I haven't tested X apps, have to reboot the MacBook. > And install more X libraries. > > AMD64_NETBSD later. > > I made a new node. Copied from openbsd-jkrell. > jkrell-xnbsd. > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > - Jay > From jay.krell at cornell.edu Thu Aug 19 22:54:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 20:54:48 +0000 Subject: [M3devel] more failure to propagate error Message-ID: http://hudson.modula3.com:8080/job/boot-i386-netbsd/4/console I understand the actual error, the config files are missing. ?- Jay From jay.krell at cornell.edu Thu Aug 19 23:05:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:05:17 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: , Message-ID: ok, I cloned boot-ppc-linux and this worked: http://hudson.modula3.com:8080/job/boot-i386-netbsd/5/console I had to: ?- remove the branch ?- change my /cm3 to not delegate to CVS (run scripts/python/make-dist-cfg.py) ?- not sure, but the config files still weren't there, maybe I had to rerun it, maybe I had mkdir config and that stopped ? the copying on subsequent run, I deleted the empty dir and reran We'll see how this goes: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/1/console Somewhat tedious point and click and type here but not terrible. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Thu, 19 Aug 2010 20:32:40 +0000 > Subject: Re: [M3devel] VM for I386_NETBSD Hudson > > > ok, I put in a /usr/local/bin/java that Hudson likes. > I cloned the m3cc/build/tests jobs from I386_OPENBSD. > Not sure what is next, gotta run. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com; m3devel at elegosoft.com > > Date: Thu, 19 Aug 2010 20:15:32 +0000 > > Subject: [M3devel] VM for I386_NETBSD Hudson > > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - Jay > > > From jay.krell at cornell.edu Thu Aug 19 23:10:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:10:20 +0000 Subject: [M3devel] SOLgnu/SOlsun broken Message-ID: I'm aware that SPARC32_SOLARIS/SOLsun/SOLgnu are having problems. e.g.: http://hudson.modula3.com:8080/job/cm3-current-build-SOLgnu/55/console cp: /home/hudson/workspace/cm3-current-build-SOLgnu/cm3/m3-sys/cminstall/src/config-no-install/CVS: is a directory Segmentation Fault - core dumped /home/hudson/work/cm3-inst/ssol/current/bin/cm3- is broken compiler upgrade failed I'll try to get to it soon. Usually, for some reason, these are caused by something related to position independence. - Jay From jay.krell at cornell.edu Thu Aug 19 23:12:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:12:00 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: ,,, , , , , , , , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu>, , , , , , Message-ID: As well, SOLgnu/SOLsun/SPARC32_SOLARIS when using the gcc 4.5.1 backend crash just after raising an exception. Ugh. Needs investigation.. ?- Jay ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] barrier labels? > Date: Tue, 17 Aug 2010 20:44:19 +0000 > > I forgot about this. > I never resolved it. > Things seem to work though. > ? > > - Jay > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > Date: Tue, 13 Jul 2010 06:38:05 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] barrier labels? > > > > > > I don't know. There is so much unknown here. It is frustrating and > difficult. > > We could use an extensive set of test cases. > > Or know more about the test cases we do have. > > And it'd be nice to see if anything varies in the 4.3 path if we put > the labels on that list or not. > > > > tangent: > > > > I'd like automation that compiles the whole system, multiple > architectures, and puts all the *s files in one flat > > directory per architecture. I guess it's just a matter of a little code. > > It should just skip the few errors that are cross problems, which > I should fix anyway. > > That particular problem makes me a little nervous, but I suppose > I can code it to use both INTEGER and Target.Int > > if doing a native build, and assert that the results match. > > I hit a snag yesterday, can't build any tests (just to assembly) > without first shipping m3core/libm3. > > Can't ship m3core/libm3 for cross building. > > I guess, and I forgot this, I should have used -x for override. Duh. > > That's why I tried I386_DARWIN for some current 4.5 problems vs. > SOLgnu, to escape cross building. Oops. > > > > > > - Jay > > > > ---------------------------------------- > > > From: hosking at cs.purdue.edu > > > Date: Mon, 12 Jul 2010 09:43:01 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] barrier labels? > > > > > > Perhaps we just need FORCED_LABEL for these: > > > > > > /* In a LABEL_DECL, nonzero means this label had its address taken > > > and therefore can never be deleted and is a jump target for > > > computed gotos. */ > > > > > > > > > On 11 Jul 2010, at 23:03, Jay K wrote: > > > > > > > > > > > I still don't see it, in the C++ frontend. > > > > > > > > There is: > > > > > > > > void > > > > expand_label (tree label) > > > > { > > > > ... > > > > if (DECL_NONLOCAL (label)) > > > > { > > > > ... nonlocal_goto_handler_labels > > > > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > > > > nonlocal_goto_handler_labels); > > > > } > > > > > > > > but I don't think this works until later. > > > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > >> From: hosking at cs.purdue.edu > > > >> Date: Sun, 11 Jul 2010 20:52:25 -0400 > > > >> To: jay.krell at cornell.edu > > > >> CC: m3devel at elegosoft.com > > > >> Subject: Re: [M3devel] barrier labels? > > > >> > > > >> No, that code came from 4.x... > > > >> > > > >> > > > >> > > > >> > > > >> On 11 Jul 2010, at 19:41, Jay K wrote: > > > >> > > > >>> > > > >>> Tony, thanks for the pointer..though I haven't been able to > find it yet. > > > >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 > was current at the time. > > > >>> > > > >>> - Jay > > > >>> > > > >>> ---------------------------------------- > > > >>>> From: hosking at cs.purdue.edu > > > >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 > > > >>>> To: jay.krell at cornell.edu > > > >>>> CC: m3devel at elegosoft.com > > > >>>> Subject: Re: [M3devel] barrier labels? > > > >>>> > > > >>>> I extracted that usage from what C++ was doing for exception > labels. The point is to make sure that flow analysis knows that the > exception handler label targets are important "non-local" label > targets. I do remember that DECL_NONLOCAL was *not* the right thing to > do (that is used for proper non-local outer-scope goto targets for > nested functions) and I remember the SP hacks being used with that > (they need to recover from targeting from an inner-scope function and > clean up the stack accordingly). I suggest poking around in what the > C++ exception handling now does with table-driven exception targets. > > > >>>> > > > >>>> On 11 Jul 2010, at 07:46, Jay K wrote: > > > >>>> > > > >>>>> > > > >>>>> Tony, six years ago you introduce what is now: > > > >>>>> > > > >>>>> > > > >>>>> > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > > >>>>> > > > >>>>> > > > >>>>> static void > > > >>>>> m3cg_set_label (void) > > > >>>>> { > > > >>>>> ... > > > >>>>> if (barrier) > > > >>>>> { > > > >>>>> ... > > > >>>>> { > > > >>>>> rtx list = DECL_STRUCT_FUNCTION > (current_function_decl)->x_nonlocal_goto_handler_labels; > > > >>>>> DECL_STRUCT_FUNCTION > (current_function_decl)->x_nonlocal_goto_handler_labels > > > >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > > > >>>>> } > > > >>>>> ... > > > >>>>> > > > >>>>> > > > >>>>> I'm not sure what to do here for gcc 4.5. > > > >>>>> The data has moved around and isn't available this early. I > suppose we could hang some information on and > > > >>>>> deal with it later in compilation. > > > >>>>> > > > >>>>> > > > >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very > bad code to be produced (incorrect, not inefficient). > > > >>>>> I didn't look into why. The bad code was changing the stack > pointer where it should leave it alone. > > > >>>>> > > > >>>>> > > > >>>>> gcc-4.5 is working for me now (cm3 built with it can built > itself), at least with -O1, AMD64_DARWIN. > > > >>>>> And Juno/mentor/tetris work without optimization, I'll test > optimized later. > > > >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. > > > >>>>> > > > >>>>> > > > >>>>> Do we have good exception handling tests? > > > >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > > > >>>>> > > > >>>>> > > > >>>>> I'll poke around more.. > > > >>>>> > > > >>>>> > > > >>>>> - Jay > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > From jay.krell at cornell.edu Thu Aug 19 23:27:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:27:27 +0000 Subject: [M3devel] cvs commands in Hudson keep complaining about long-ago deleted directories Message-ID: Olaf there's something somehow slightly off. http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console Started by user jkrell Building remotely on jkrell-xnbsd [m3cc] $ cvs -q -z3 update -PdC -D "Thursday, August 19, 2010 9:16:34 PM UTC" ?cvs update: use `cvs add' to create an entry for `gcc/INSTALL'???? <==? ?cvs update: use `cvs add' to create an entry for `gcc/fixincludes' ?? <== This has been happening on all jobs. I manually removed the directories in most/all. But this is a new node/task. It must be related to the branches varying. But cvs upd shouldn't be so difficult. ?- Jay From wagner at elegosoft.com Fri Aug 20 08:03:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 08:03:38 +0200 Subject: [M3devel] cvs commands in Hudson keep complaining about long-ago deleted directories In-Reply-To: References: Message-ID: <20100820080338.42ud2degysww4gsk@mail.elegosoft.com> Quoting Jay K : > Olaf there's something somehow slightly off. > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > Started by user jkrell > Building remotely on jkrell-xnbsd > [m3cc] $ cvs -q -z3 update -PdC -D "Thursday, August 19, 2010 9:16:34 PM UTC" > > ?cvs update: use `cvs add' to create an entry for `gcc/INSTALL'???? > <==? > ?cvs update: use `cvs add' to create an entry for `gcc/fixincludes' ?? <== > > This has been happening on all jobs. > I manually removed the directories in most/all. > But this is a new node/task. > > It must be related to the branches varying. > But cvs upd shouldn't be so difficult. In my working copy from the trunk these directories are there. They get removed by your m3makefile again, but update -d resurrects them. What exactly have you done to `remove' them from CVS? As CVS doesn't handle directories as first class objects, the only ways to remove a directory are (1) delete all files in it recursively and let CVS know. The -p(rune) option will then delete empty directories. (2) remove the complete history on the server. Not allowed for a simple human user in daily operations ;-) Olaf PS: I'm in a hurry now, do I won't have time to read and answer all mails now. There are still several dozens... More later. -- 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 Fri Aug 20 08:33:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 20 Aug 2010 06:33:53 +0000 Subject: [M3devel] cvs commands in Hudson keep complaining about long-ago deleted directories In-Reply-To: <20100820080338.42ud2degysww4gsk@mail.elegosoft.com> References: , <20100820080338.42ud2degysww4gsk@mail.elegosoft.com> Message-ID: > They get removed by your m3makefile again Oops, I didn't realize, don't see, will keep looking. (See next.) > What exactly have you done to `remove' them from CVS? As CVS doesn't > handle directories as first class objects, the only ways to remove > (1) delete all files in it recursively and let CVS know. > The -p(rune) option will then delete empty directories. Oops, I thought I had done that. Apparently not. > (2) remove the complete history on the server. Not allowed for > a simple human user in daily operations ;-) Of course. Sorry for the misdirection! ?- Jay From wagner at elegosoft.com Fri Aug 20 10:31:57 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 10:31:57 +0200 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: <20100820103157.387frltd2cwooccc@mail.elegosoft.com> Quoting Jay K : > ok, I put in a /usr/local/bin/java that Hudson likes. > I cloned the m3cc/build/tests jobs from I386_OPENBSD. > Not sure what is next, gotta run. To simplify matters, new Hudson nodes should contain the last CM3 rlease in $INSTROOT_REL, which usually is something like $HOME/work/$HOST/cm3-inst/rel-5.8.6 BTW, several nodes still lack the latest release there, and/or reference something like LASTREL=d5.7.0 or similar. These may fail as soon as we rely on features in that release (like quake functions etc.). I haven't had time to check everything yet, Olaf > ?- Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Date: Thu, 19 Aug 2010 20:15:32 +0000 >> Subject: [M3devel] VM for I386_NETBSD Hudson >> >> >> New Hudson node. >> A VM running on MacBook. >> We'll see if it stays on and if the network works. >> >> I386_NETBSD >> >> ssh -p 227 hudson at jayk.homedns.org >> >> To start, it has: >> /usr/pkg/java/openjdk7/bin/java >> /cm3/bin/cm3 >> Actually a bunch in /cm3, you can get cm3cg, >> pkg/{m3core,libm3,etc.} there. >> /usr/pkg/bin/bash >> >> It is missing some libraries still so some "late" packages >> will fail. >> >> I haven't tested X apps, have to reboot the MacBook. >> And install more X libraries. >> >> AMD64_NETBSD later. >> >> I made a new node. Copied from openbsd-jkrell. >> jkrell-xnbsd. >> http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ >> >> PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin >> >> - 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 wagner at elegosoft.com Fri Aug 20 14:58:09 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 14:58:09 +0200 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com> The installed cm3 still uses the wrong target platform name: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. Fix config? Olaf Quoting Jay K : > > New Hudson node. > A VM running on MacBook. > ? We'll see if it stays on and if the network works. > > I386_NETBSD > > ssh -p 227 hudson at jayk.homedns.org > > To start, it has: > ? /usr/pkg/java/openjdk7/bin/java > ? /cm3/bin/cm3 > ??? Actually a bunch in /cm3, you can get cm3cg, > pkg/{m3core,libm3,etc.} there. > ? /usr/pkg/bin/bash > > It is missing some libraries still so some "late" packages > will fail. > > I haven't tested X apps, have to reboot the MacBook. > ?And install more X libraries. > > AMD64_NETBSD later. > > I made a new node. Copied from openbsd-jkrell. > jkrell-xnbsd. > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > ?- 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 wagner at elegosoft.com Fri Aug 20 16:15:36 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 16:15:36 +0200 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Quoting Jay K : > New Hudson node. > A VM running on MacBook. > ? We'll see if it stays on and if the network works. For your information It seems we have crossed the acceptable load boundary for our hosted server birch.elegosoft.com recently. The main problem seems to be I/O caused by lots of concurrent CVS checkouts and updates in combination with internal backup, which make other services like HTTP unresponsive and unusable. As far as I can see there is no easy short-time solution. We are going to find a new and more efficient home for our web services anyway in the fall, but it may be that we will have to limit the number of concurrent CVS accesses or Hudson job executions (including clients) for some time. I'm currently also investigating if we can easily move to another (virtual) host or setup a proxy to improve matters. Both will need some migration on client sides. I'll keep you informed what way we choose to resolve this problem. It will help if you don't check in lots of small changes, but complete reasonable change sets. It would also help if we could reduce the size of the repository again, especially in the gcc and gdb structures. If there is dead content that we don't really need, we might move it to another access path for some time. Thanks in advance for your understanding and cooperation. Please stay calm and continue to enjoy the flight ;-) 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 Sat Aug 21 09:38:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 07:38:29 +0000 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> References: , <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Message-ID: All the more reason to use anything besides CVS? What about checkout vs. update? Is update a problem or just checkout? We don't do many checkouts, right? Can/should the pollling interval be changed, like to every hour? And can machines poll at different times, say at a minute within the hour that is a hash of their hostname? Or more aggressive, have some machines only poll a few times a day, once or twice? Only more mainstream machines poll more frequently? I can always run "build now" if I'm eager for a particular build. Repository size is a tough one. Even if I remove files, the repository size is unchanged, right? We have 3 copies of gcc in semi-active use right now. There are others in the repository. But gcc-apple really isn't active -- it is for ARM_DARWIN. Can the Hudson jobs easily exclude that? Between gcc and gcc-4.5 we are stuck for now. gcc-4.5 works a lot and also definitely fails some. In particular SPARC32_SOLARIS/SOLgnu/SOLsun fail right after throwing an exception. SPARC64_SOLARIS has at least a small problem. I'm not sure if there are problems beyond those. Certainly if you want to "cherry pick" off a few files here and there, there is definitely opportunity. I'm not sure if a few files here and there matter though. m3-pkgtools presently isn't built for example. dll2lib or whatever isn't worth anything these days. The old m3gc-simple and m3gc-enhanced are dead. I like a source control to preserve record of deleted stuff though. - Jay > Date: Fri, 20 Aug 2010 16:15:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: m3-support at elego.de > Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson > > Quoting Jay K : > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > For your information > > It seems we have crossed the acceptable load boundary for our hosted > server birch.elegosoft.com recently. The main problem seems to be > I/O caused by lots of concurrent CVS checkouts and updates in combination > with internal backup, which make other services like HTTP unresponsive and > unusable. > > As far as I can see there is no easy short-time solution. We are going > to find a new and more efficient home for our web services anyway in the > fall, but it may be that we will have to limit the number of concurrent > CVS accesses or Hudson job executions (including clients) for some time. > > I'm currently also investigating if we can easily move to another > (virtual) host or setup a proxy to improve matters. Both will need > some migration on client sides. > > I'll keep you informed what way we choose to resolve this problem. > > It will help if you don't check in lots of small changes, but complete > reasonable change sets. > > It would also help if we could reduce the size of the repository again, > especially in the gcc and gdb structures. If there is dead content > that we don't really need, we might move it to another access path for > some time. > > Thanks in advance for your understanding and cooperation. > > Please stay calm and continue to enjoy the flight ;-) > > 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 wagner at elegosoft.com Sat Aug 21 11:24:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 21 Aug 2010 11:24:43 +0200 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: References: , <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Message-ID: <20100821112443.eb5ljfzklc0kk8wc@mail.elegosoft.com> Quoting Jay K : > All the more reason to use anything besides CVS? I'd doubt that other system will improve this situation much. But I don't know. Peter Eiserloh is currently trying out git. > What about checkout vs. update? > Is update a problem or just checkout? > We don't do many checkouts, right? We're doing mostly updates. But they should generate the same i/o load. > Can/should the pollling interval be changed, like to every hour? > And can machines poll at different times, say at a minute within the > hour that is a hash of their hostname? I've already increased the polling interval on several jobs, but may increase still more. > Or more aggressive, have some machines only poll a few times a day, > once or twice? Well yes, we could just poll locally on birch and start the other jobs on completion. I think I'll do that; I'll probably disable all the polling first by script and then add some dependencies. > Only more mainstream machines poll more frequently? > I can always run "build now" if I'm eager for a particular build. Yes. > Repository size is a tough one. > Even if I remove files, the repository size is unchanged, right? I meant we could move a complete sub-tree to another location for some time if it's not needed. There are several versions of gcc IIRC. If we need all of them for at least one target, we cannot do that. > We have 3 copies of gcc in semi-active use right now. > There are others in the repository. > But gcc-apple really isn't active -- it is for ARM_DARWIN. > Can the Hudson jobs easily exclude that? We can add that where possible, too. > Between gcc and gcc-4.5 we are stuck for now. > gcc-4.5 works a lot and also definitely fails some. > In particular SPARC32_SOLARIS/SOLgnu/SOLsun fail right after > throwing an exception. > SPARC64_SOLARIS has at least a small problem. > I'm not sure if there are problems beyond those. > > Certainly if you want to "cherry pick" off a few files here and > there, there is definitely opportunity. > I'm not sure if a few files here and there matter though. Not worth the trouble. > m3-pkgtools presently isn't built for example. > dll2lib or whatever isn't worth anything these days. It's just the gcc and gdb code that's so large. > The old m3gc-simple and m3gc-enhanced are dead. Also not worth to remove. > I like a source control to preserve record of deleted stuff though. I'm not going to delete anything then. Let's try the polling strategy change first. 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 Sat Aug 21 12:13:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 10:13:03 +0000 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: <20100821112443.eb5ljfzklc0kk8wc@mail.elegosoft.com> References: , <20100820161536.xmld5roocgwgggow@mail.elegosoft.com>, , <20100821112443.eb5ljfzklc0kk8wc@mail.elegosoft.com> Message-ID: > I meant we could move a complete sub-tree to another location for some > time if it's not needed. There are several versions of gcc IIRC. > If we need all of them for at least one target, we cannot do that. Aha, I understand better now. You mean to a new CVS root/repository? You can move this: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.1.1/ e.g. /usr/cvs/cm3_m3cc_gcc-4.1.1. My desire for history, worst case, drop a readme.txt in cm3/m3-sys/m3cc/gcc-4.1.1. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-interix. I merged it into m3cc/gcc long ago (and gcc-4.5 more recently) and it has all been deleted. Again, a marker file could be dropped in. Less clear: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-apple. It is for iphone but surely currently unused. stuck with for now: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.5 http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc I actually have some interest in making this situation worse. It appears OpenBSD doesn't like GPL3, so they have moved some targets up to gcc 4.x, but stopped at 4.2.1. Some are on 3.x I think some are on 2.x. It'd be helpful to branch the OpenBSD versions. Or, on the other hand, I'm starting to put time into a C backend! :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Aug 21 14:05:34 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 21 Aug 2010 08:05:34 -0400 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: References: <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Message-ID: <20100821120534.GA8755@topoi.pooq.com> On Sat, Aug 21, 2010 at 07:38:29AM +0000, Jay K wrote: > > All the more reason to use anything besides CVS? Sorry. I meant to work on conversion to monotone, but I haven't had the time to work on it yet. -- hendrik From wagner at elegosoft.com Sat Aug 21 18:21:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 21 Aug 2010 18:21:44 +0200 Subject: [M3devel] changes in CM3 continuous integration setup Message-ID: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com> Due to I/O overload problems on the Hudson/CVS/WWW server birch.elegosoft.com I have now reduced the jobs that perform actual repository polling on the CM3 CVS repository to two, running locally on birch: cm3-current-m3cc-AMD64_LINUX cm3-current-build-AMD64_LINUX The first checks all the m3cc sources, the second the rest; the first runs all 10, the second all 11 minutes. All other jobs are triggered in several cascades by these two. For each target platform, the dependencies are m3cc --> build --> test-m3tests --> test-all-pkgs The m3cc and build jobs for AMD64_LINUX also trigger other target platform builds in this fashion: AMD64_LINUX --> AMD64_DARWIN --> AMD64_FREEBSD --> PPC_DARWIN --> I386_DARWIN --> I386_NETBSD --> I386_OPENBSD --> SOLsun-opencsw-curent9s --> SOLsun-opencsw-curent10s --> I386_SOLARIS-opencsw-curent10x --> FreeBSD4 --> LINUXLIBC6 --> NT386 --> PPC_LINUX --> SPARC32_LINUX --> SOLgnu This scheme reflects the expected availability and maintainability of the machines by me, in case you wonder ;-) I hope that this will help to reduce the load and not lead to further problems due to parallel updates on one cascade level. Of course, jobs can still be started manually via the HTTP GUI. If you do this, please bear in mind that other jobs will be triggered, too, according to the diagrams above. 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 Sun Aug 22 00:42:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 22:42:21 +0000 Subject: [M3devel] record types in backend In-Reply-To: References: <20100821083935.3593B247400C@birch.elegosoft.com>, Message-ID: In debugging this..the gcc code wants to enumerate the fields of a struct. We spend the effort building up most of this information, but we never hook it up to the parameter. The fields are null. From debugging it. Then from reading our code: declare_param: m3_build_type case T_struct: { tree ts = make_node (RECORD_TYPE); TYPE_FIELDS (ts) = NULL_TREE; Seems to me we should have a hash of typeid to tree, and here we should look up the typeid and set the fields appropriately. I'll try that. Besides fixing SPARC64_SOLARIS here, it should dramatically improve debugging with stock gdb. We'll see. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Sat, 21 Aug 2010 21:49:04 +0000 Subject: Re: [M3commit] CVS Update: cm3 It turns out 4.3.5 fails the same way. - Jay > Date: Sat, 21 Aug 2010 10:39:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/21 10:39:34 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > > Log message: > back to gcc 4.3 for SPARC64_SOLARIS, see m3-sys/m3tests/src/p2/p247 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 22 00:43:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 22:43:53 +0000 Subject: [M3devel] record types in backend In-Reply-To: References: <20100821083935.3593B247400C@birch.elegosoft.com>, , Message-ID: I should point out that the type we do build up contains fields of I think integers. static void debug_field (const char *name) { tree f = build_decl (FIELD_DECL, get_identifier (name), t_int); That also needs work and shouldn't be difficult. I'm not sure where the builtin typeids come from though. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: record types in backend Date: Sat, 21 Aug 2010 22:42:21 +0000 In debugging this..the gcc code wants to enumerate the fields of a struct. We spend the effort building up most of this information, but we never hook it up to the parameter. The fields are null. From debugging it. Then from reading our code: declare_param: m3_build_type case T_struct: { tree ts = make_node (RECORD_TYPE); TYPE_FIELDS (ts) = NULL_TREE; Seems to me we should have a hash of typeid to tree, and here we should look up the typeid and set the fields appropriately. I'll try that. Besides fixing SPARC64_SOLARIS here, it should dramatically improve debugging with stock gdb. We'll see. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Sat, 21 Aug 2010 21:49:04 +0000 Subject: Re: [M3commit] CVS Update: cm3 It turns out 4.3.5 fails the same way. - Jay > Date: Sat, 21 Aug 2010 10:39:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/21 10:39:34 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > > Log message: > back to gcc 4.3 for SPARC64_SOLARIS, see m3-sys/m3tests/src/p2/p247 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 22 12:11:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Aug 2010 10:11:08 +0000 Subject: [M3devel] better type information in gcc backend Message-ID: This is getting interesting. I have a small local change so that local structs have type information -- as to what fields they contain. As a result, you can see like: 0x001d65b7 in RTType__Expand (M3_DaARCY_m=0x0) at ../src/runtime/common/RTType.m3:719 (gdb) info locals M3_BQo8Jp_new = { Bd56fi_0_32_name = 0, D0ztjH_32_32_is_equal = 0, DXHNAh_64_32_rehash = 0, Cwb5VA_96_32_initial_size = 0, Cwb5VA_128_32_full = 0, Cwb5VA_160_32_cnt = 0, Cwb5VA_192_32_max = 0, AcxOUs_224_32_mask = 0, AJWxb1_256_32_map = 0 } which is a great improvement. It used to only show you the address of the locals. *However*, first when I put the change in, gcc would hit infinite recursions, something related to bitfields. So I *again* disabled our wierdo bitfield stuff. That hack is a continuing thorn in my side. Yes it does generate better code, at least when not optimizing. We'd surely be better to get all the type information correct though and use member references. I realize that the frontend "lowers" things generally further than that, it expects a lower level backend than the gcc tree representation is really designed for. Anyway.. Then it compiles. But the result crashes. Using -O3. And info locals actually prints the locals three times each. More to do here.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Sun Aug 22 16:26:33 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Sun, 22 Aug 2010 22:26:33 +0800 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 Message-ID: The CM3 binaries for FreeBSD6 don't work in FreeBSD 8.1 because cminstall is looking for very specific versions of libraries. For example it wants libm.so.4 but I only have libm.so -> libm.so.5. It also looks for libc.so.6 where I can only supply libc.so.7. Even worse is the requirement for libpthread.so.2. There *IS* no libpthread.so.anything. There's a libpthread.so which is a soft link to libthr.so which is itself a soft link to libthr.so.3. If I try to fake any of this out with softlinks I get problems with libpthread.so.2 since it's looking for a symbol (LIBTHREAD_1_0) which is apparently not provided by libthr.so.3. There is nothing in /usr/ports that seems to give me a proper libpthread that cminstall would like, so I'm basically stuck at this point unable to install (not build -- install!) CM3 on this FreeBSD machine. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Aug 22 16:43:49 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 22 Aug 2010 16:43:49 +0200 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: References: Message-ID: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Quoting Michael Richter : > The CM3 binaries for FreeBSD6 don't work in FreeBSD 8.1 because cminstall is > looking for very specific versions of libraries. For example it wants > libm.so.4 but I only have libm.so -> libm.so.5. It also looks for libc.so.6 > where I can only supply libc.so.7. Even worse is the requirement for > libpthread.so.2. There *IS* no libpthread.so.anything. There's a > libpthread.so which is a soft link to libthr.so which is itself a soft link > to libthr.so.3. > > If I try to fake any of this out with softlinks I get problems with > libpthread.so.2 since it's looking for a symbol (LIBTHREAD_1_0) which is > apparently not provided by libthr.so.3. There is nothing in /usr/ports that > seems to give me a proper libpthread that cminstall would like, so I'm > basically stuck at this point unable to install (not build -- install!) CM3 > on this FreeBSD machine. AFAIK FreeBSD always offered so-called compatibility distributions, which contain all old libraries of previous systems. You should be able to install these with the FreeBSD installer and then run cm3 and build your own binary which uses the up-to-date libs. Hope this helps, 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 ttmrichter at gmail.com Sun Aug 22 17:49:33 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Sun, 22 Aug 2010 23:49:33 +0800 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> References: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Message-ID: On 22 August 2010 22:43, Olaf Wagner wrote: > AFAIK FreeBSD always offered so-called compatibility distributions, > which contain all old libraries of previous systems. You should be > able to install these with the FreeBSD installer and then run cm3 > and build your own binary which uses the up-to-date libs. > I'm looking at FreeBSD.org and I'm not seeing anything like that at all. Sysintall doesn't offer anything like that under "distributions" either. Sorry for being such a newb here, but I really have no idea where to even LOOK for the next step. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Sun Aug 22 17:54:57 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Sun, 22 Aug 2010 23:54:57 +0800 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: References: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Message-ID: Of course about ten seconds after I post this I find the "compatx" packages in ports. Teaches me to look for full words in names! Please disregard the earlier message. ;) On 22 August 2010 23:49, Michael Richter wrote: > On 22 August 2010 22:43, Olaf Wagner wrote: > >> AFAIK FreeBSD always offered so-called compatibility distributions, >> which contain all old libraries of previous systems. You should be >> able to install these with the FreeBSD installer and then run cm3 >> and build your own binary which uses the up-to-date libs. >> > > I'm looking at FreeBSD.org and I'm not seeing anything like that at all. > Sysintall doesn't offer anything like that under "distributions" either. > Sorry for being such a newb here, but I really have no idea where to even > LOOK for the next step. > > > -- > "Perhaps people don't believe this, but throughout all of the discussions > of entering China our focus has really been what's best for the Chinese > people. It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Aug 22 18:49:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 22 Aug 2010 18:49:39 +0200 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: References: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Message-ID: <20100822184939.4zv8hdovuowgckok@mail.elegosoft.com> Quoting Michael Richter : > On 22 August 2010 22:43, Olaf Wagner wrote: > >> AFAIK FreeBSD always offered so-called compatibility distributions, >> which contain all old libraries of previous systems. You should be >> able to install these with the FreeBSD installer and then run cm3 >> and build your own binary which uses the up-to-date libs. >> > > I'm looking at FreeBSD.org and I'm not seeing anything like that at all. > Sysintall doesn't offer anything like that under "distributions" either. > Sorry for being such a newb here, but I really have no idea where to even > LOOK for the next step. I think this may be of help: luthien [] root # ls -ld /usr/ports/misc/compat?x drwxrwxr-x 3 root wheel 512 May 25 05:23 /usr/ports/misc/compat3x/ drwxrwxr-x 3 root wheel 512 Aug 22 05:23 /usr/ports/misc/compat4x/ drwxrwxr-x 3 root wheel 512 Aug 22 05:23 /usr/ports/misc/compat5x/ drwxrwxr-x 3 root wheel 512 Dec 6 2009 /usr/ports/misc/compat6x/ drwxr-xr-x 3 wagner wheel 512 Dec 8 2009 /usr/ports/misc/compat7x/ luthien [] root # cat /usr/ports/misc/compat6x/pkg-descr This package allows you to install the compat6x libraries on your system, so you can use legacy binaries that depend on them. Ports usage example: -- .include .if ${OSVERSION} >= 700043 LIB_DEPENDS+= c.6:${PORTSDIR}/misc/compat6x .endif -- 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 Mon Aug 23 09:57:04 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Aug 2010 09:57:04 +0200 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com> References: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com> Message-ID: <20100823095704.6pgf9a9xssc4804o@mail.elegosoft.com> Quoting Olaf Wagner : > AMD64_LINUX --> AMD64_DARWIN > --> AMD64_FREEBSD -//-> PPC_DARWIN --> I386_DARWIN > --> I386_NETBSD > --> I386_OPENBSD > --> SOLsun-opencsw-curent9s > --> SOLsun-opencsw-curent10s > --> I386_SOLARIS-opencsw-curent10x > -//-> FreeBSD4 --> LINUXLIBC6 > --> NT386 > --> PPC_LINUX > --> SPARC32_LINUX > --> SOLgnu I've now cut off the subtrees at PPC_DARWIN and FreeBSD4, as the load was still not much better. Those two poll now for themselves again, but only once or twice a day, so that the number of CVS updates and build runs should be further reduced. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 23 12:44:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 10:44:48 +0000 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100823095704.6pgf9a9xssc4804o@mail.elegosoft.com> References: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com>, <20100823095704.6pgf9a9xssc4804o@mail.elegosoft.com> Message-ID: I don't really understand all of this. Surely CVS can tolerate more than 10 "active" users? Or is it really awful? (or, most likely, both) What if they all poll much less than once an hour? Let's say we have 12 machines. Have them each poll 4 times per day: 48 polls. So that's just one operation every 30 minutes. One poll, possibly followed by one update. Or, didn't you set it up so only one machine polled and all the other builds would follow it, serially? If not, that makes sense. Have one machine poll every 30 minutes. If it finds something, it builds, and the next one builds. If it finds nothing, then nothing occurs. Surely this would work ok? It merely serializes all of our Hudson jobs? Which is, granted, rather unfortunate. Adding machines should allow great parallelism. And CVS is read-mostly, so should handle plenty of load. "Read-mostly" being a property that makes systems easier to scale. I assume if I bothered to learn to use cvsup, it would help much? We'd have a few mirrors and it'd "fan out well"? e.g. 5 cvsup mirrors could each serve 5 cvs clients, 25 for the price of 5? - Jay > Date: Mon, 23 Aug 2010 09:57:04 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com; m3-support at elego.de > Subject: Re: [M3devel] changes in CM3 continuous integration setup > > Quoting Olaf Wagner : > > > AMD64_LINUX --> AMD64_DARWIN > > --> AMD64_FREEBSD -//-> PPC_DARWIN --> I386_DARWIN > > --> I386_NETBSD > > --> I386_OPENBSD > > --> SOLsun-opencsw-curent9s > > --> SOLsun-opencsw-curent10s > > --> I386_SOLARIS-opencsw-curent10x > > -//-> FreeBSD4 --> LINUXLIBC6 > > --> NT386 > > --> PPC_LINUX > > --> SPARC32_LINUX > > --> SOLgnu > > I've now cut off the subtrees at PPC_DARWIN and FreeBSD4, as the load > was still not much better. Those two poll now for themselves again, > but only once or twice a day, so that the number of CVS updates > and build runs should be further reduced. > > 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 Mon Aug 23 12:57:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 10:57:00 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com> References: , <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com> Message-ID: I noticed this too. Not sure yet where it comes from. Would folks mind if I removed "NetBSD2_i386" from the system completely? I don't think anybody uses it.. I386_NETBSD serves about the same purpose. - Jay > Date: Fri, 20 Aug 2010 14:58:09 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: VM for I386_NETBSD Hudson > > The installed cm3 still uses the wrong target platform name: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. > Fix config? > > Olaf > > Quoting Jay K : > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, > > pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 23 13:17:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 11:17:17 +0000 Subject: [M3devel] RTLinker.envp, instance removal? Message-ID: RTLinker exposes: envp instance envp is not entirely useless, but is redundant with Cstdlib.getenv, which is exposed through libm3/Env. RTLinker.envp appears somewhat broken on Windows, despite appearances that I tried to fix it. In particular, broken for gui apps. (btw, gui apps and console apps are far more the same than people realize; this whole business where Modula-3's main varies for each of them is unnecessary; the actual entry point for any Win32 console or gui app takes no parameters; the parameters the C runtime passes to main or WinMain are created by it based on stuff such as GetCommandLine, GetStartupInfo, etc.) instance is pretty much useless. Anyone that needs it can get it via GetModuleHandle(NULL); I suppose RTLinker.instance is more portable, as it'll reliably be null on posix -- ie: the #ifdef is built into startup/m3core, instead of the user's app. (on the other hand, there's probably nothing portable you can do with instance, given that it is useless on Posix) Anyway, on the general premise that less is more and things deemed buggy, of little value, and unused, are best just removed instead of fixed or improved, I propose removing both of these. Once I verify they are unused. ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 23 13:23:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 11:23:25 +0000 Subject: [M3devel] main in C or not? Message-ID: There has long been a configuration variable: MAIN_IN_C. I propose that main always be in C. I made that so already, a small change. I further propose that the support for main to not be in C be removed. "Not in C" is "generating it via the backend", directly an .obj for NT386, or going through the gcc backend for Posix. Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. I have this change about ready. I don't think avoiding C is valuable and I'd rather have fewer configuration variables. Pick one approach that works reasonably always. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 23 13:41:40 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Aug 2010 13:41:40 +0200 Subject: [M3devel] changes in CM3 continuous integration setup Message-ID: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> Quoting Jay K : > I don't really understand all of this. > Surely CVS can tolerate more than 10 "active" users? > Or is it really awful? > (or, most likely, both) > What if they all poll much less than once an hour? It's not just CVS. The machine is running our WWW services, FTP, CVSup, backup for several hosts and secondary mail services. > Let's say we have 12 machines. > Have them each poll 4 times per day: 48 polls. > So that's just one operation every 30 minutes. > One poll, possibly followed by one update. That would be an individual setup for all jobs regarding polling. It's of course possible, but more tedious work again. > Or, didn't you set it up so only one machine polled and all the > other builds would follow it, serially? > If not, that makes sense. > Have one machine poll every 30 minutes. > If it finds something, it builds, and the next one builds. > If it finds nothing, then nothing occurs. > Surely this would work ok? > It merely serializes all of our Hudson jobs? > Which is, granted, rather unfortunate. > Adding machines should allow great parallelism. > And CVS is read-mostly, so should handle plenty of load. > "Read-mostly" being > a property that makes systems easier to scale. The current setup is suboptimal. I've changed things in a way that could be done quickly. But it's not easy to foretell how any change will affect the load and responsiveness, as it isn't even clear where the limits are; and other services are continually competing for resources, too. I've set up continuous logging of system load, top and iotop. You can get a quick summary with this job: http://hudson.modula3.com:8080/view/zzz/job/sysload We'll monitor this for some days and see how our changes affect the situation. Complete logs are written to Hudson's ~/log/ directory. > I assume if I bothered to learn to use cvsup, it would help much? > We'd have a few mirrors and it'd "fan out well"? > e.g. 5 cvsup mirrors could each serve 5 cvs clients, 25 for the price of 5? I think we'd only need one CVS mirror that the continous integration could use. Unfortunately, our system administrator is on vacance (his wife's expecting their second baby) right now, and I haven't got any machine for that readily available. We'll sort that out, though; don't worry too much. It may need some weeks, but we'll find an acceptable solution without much limitations. 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 Mon Aug 23 13:57:01 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Aug 2010 13:57:01 +0200 Subject: [M3devel] main in C or not? In-Reply-To: References: Message-ID: <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Quoting Jay K : > There has long been a configuration variable: MAIN_IN_C. > > I propose that main always be in C. I made that so already, a small change. > > I further propose that the support for main to not be in C be removed. > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > going through the gcc backend for Posix. > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > I have this change about ready. > > I don't think avoiding C is valuable and I'd rather have fewer > configuration variables. > Pick one approach that works reasonably always. This requires that every user must have a C compiler in addition to cm3. I thought the default was not to generate C, and just require a C compiler for special runtime support. I'm not sure if this really a valid argument for the systems we support though, as we also need a system linker, and that is probably bundled with the C compiler in a development package. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 23 23:51:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 21:51:44 +0000 Subject: [M3devel] main in C or not? In-Reply-To: <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Mon Aug 23 23:54:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 21:54:17 +0000 Subject: [M3devel] RTLinker.envp, instance removal? In-Reply-To: References: Message-ID: envp is used at least by posix/RTArgs so will stay. I'll investigate further: ie. if it is used on Windows, test it and make it work, else maybe make it null. Still probably remove instance if it isn't used, I don't think it has a portable use. One could compare it to null to deduce Win32 vs. Posix but there is already Compiler.ThisOS or somesuch. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RTLinker.envp, instance removal? Date: Mon, 23 Aug 2010 11:17:17 +0000 RTLinker exposes: envp instance envp is not entirely useless, but is redundant with Cstdlib.getenv, which is exposed through libm3/Env. RTLinker.envp appears somewhat broken on Windows, despite appearances that I tried to fix it. In particular, broken for gui apps. (btw, gui apps and console apps are far more the same than people realize; this whole business where Modula-3's main varies for each of them is unnecessary; the actual entry point for any Win32 console or gui app takes no parameters; the parameters the C runtime passes to main or WinMain are created by it based on stuff such as GetCommandLine, GetStartupInfo, etc.) instance is pretty much useless. Anyone that needs it can get it via GetModuleHandle(NULL); I suppose RTLinker.instance is more portable, as it'll reliably be null on posix -- ie: the #ifdef is built into startup/m3core, instead of the user's app. (on the other hand, there's probably nothing portable you can do with instance, given that it is useless on Posix) Anyway, on the general premise that less is more and things deemed buggy, of little value, and unused, are best just removed instead of fixed or improved, I propose removing both of these. Once I verify they are unused. ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 23 23:55:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 21:55:55 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, Message-ID: > I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration > is ignored. Alternatively I can change cm3cfg.common. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] main in C or not? Date: Mon, 23 Aug 2010 21:51:44 +0000 Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 rcolebur at SCIRES.COM Tue Aug 24 00:10:15 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:06:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:06:04 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , Message-ID: Randy, yes, that is my same understanding, from fairly recent experience. They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: extern const int max_this = 100; extern const int max_that = 200; etc. Certain updates involve changes to that file, recompile it, relink. As such, not much of a C compiler is needed. On Itanium they do give you an ANSI compiler. The K&R compiler is enough of a compile to compile some gcc 3.x, from which you can compile current gcc (or just stick with 3.x I guess). I was able to do that. The K&R compiler I think is also enough to do 64bit work, but I think offers no shared libraries and no optimization. I haven't booted my HP-UX/hppa in months now, I doubt anyone cares much, and if anyone did, we could probably require either the ANSI compiler or gcc. Perhaps perhaps perhaps I'll bring the system back up and make sure our stuff all compiles ok K&R. Perhaps. It kind of muddies the code and even e.g. gcc 4.x can't be compiled with a K&R compiler, not even with the ansi2kr build-time conversion thingy -- which, btw, I'd be willing to try to use as a compromise. Anyway, while supporting HP-UX/hppa/itanium is on some "list", it might never make it to the top. Nobody seems interested in it. The great thing about a C generating backend if you can fairly honestly claim to support "all" systems while doing "zero" work. You know, consider: #include int main() { printf("hello\n"); return 0; } What does it work on? Pretty much "everything" -- everything with a C compiler and stdio. How much porting work? Pretty much "zero". I say "fairly honestly" because there is still a small amount of #ifdef in the C code. Though the amount of #ifdef we have at present is fairly small and the number of systems it supports is fairly large. And even the generated C code might have some system-dependencies to be smushed out perhaps. autoconf might help. The C-generating backend would theoretically and really probably for real work with HP-UX, AIX, Irix, Android, iPhone, VMS, etc. besides the usual assortment of NT (including AMD64, IA64), Linux, Solaris, FreeBSD, NetBSD, OpenBSD (modulo the threading/context problems), Darwin. (iPhone has a problem with the signal headers perhaps). - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: Re: [M3devel] main in C or not? Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:06:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:06:14 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , Message-ID: Randy, yes, that is my same understanding, from fairly recent experience. They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: extern const int max_this = 100; extern const int max_that = 200; etc. Certain updates involve changes to that file, recompile it, relink. As such, not much of a C compiler is needed. On Itanium they do give you an ANSI compiler. The K&R compiler is enough of a compile to compile some gcc 3.x, from which you can compile current gcc (or just stick with 3.x I guess). I was able to do that. The K&R compiler I think is also enough to do 64bit work, but I think offers no shared libraries and no optimization. I haven't booted my HP-UX/hppa in months now, I doubt anyone cares much, and if anyone did, we could probably require either the ANSI compiler or gcc. Perhaps perhaps perhaps I'll bring the system back up and make sure our stuff all compiles ok K&R. Perhaps. It kind of muddies the code and even e.g. gcc 4.x can't be compiled with a K&R compiler, not even with the ansi2kr build-time conversion thingy -- which, btw, I'd be willing to try to use as a compromise. Anyway, while supporting HP-UX/hppa/itanium is on some "list", it might never make it to the top. Nobody seems interested in it. The great thing about a C generating backend if you can fairly honestly claim to support "all" systems while doing "zero" work. You know, consider: #include int main() { printf("hello\n"); return 0; } What does it work on? Pretty much "everything" -- everything with a C compiler and stdio. How much porting work? Pretty much "zero". I say "fairly honestly" because there is still a small amount of #ifdef in the C code. Though the amount of #ifdef we have at present is fairly small and the number of systems it supports is fairly large. And even the generated C code might have some system-dependencies to be smushed out perhaps. autoconf might help. The C-generating backend would theoretically and really probably for real work with HP-UX, AIX, Irix, Android, iPhone, VMS, etc. besides the usual assortment of NT (including AMD64, IA64), Linux, Solaris, FreeBSD, NetBSD, OpenBSD (modulo the threading/context problems), Darwin. (iPhone has a problem with the signal headers perhaps). - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: Re: [M3devel] main in C or not? Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:12:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:12:14 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , Message-ID: Randy, yes, that is my same understanding, from fairly recent experience. They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: extern const int max_this = 100; extern const int max_that = 200; etc. Certain updates involve changes to that file, recompile it, relink. As such, not much of a C compiler is needed. On Itanium they do give you an ANSI compiler. The K&R compiler is enough of a compile to compile some gcc 3.x, from which you can compile current gcc (or just stick with 3.x I guess). I was able to do that. The K&R compiler I think is also enough to do 64bit work, but I think offers no shared libraries and no optimization. I haven't booted my HP-UX/hppa in months now, I doubt anyone cares much, and if anyone did, we could probably require either the ANSI compiler or gcc. Perhaps perhaps perhaps I'll bring the system back up and make sure our stuff all compiles ok K&R. Perhaps. It kind of muddies the code and even e.g. gcc 4.x can't be compiled with a K&R compiler, not even with the ansi2kr build-time conversion thingy -- which, btw, I'd be willing to try to use as a compromise. Anyway, while supporting HP-UX/hppa/itanium is on some "list", it might never make it to the top. Nobody seems interested in it. The great thing about a C generating backend if you can fairly honestly claim to support "all" systems while doing "zero" work. You know, consider: #include int main() { printf("hello\n"); return 0; } What does it work on? Pretty much "everything" -- everything with a C compiler and stdio. How much porting work? Pretty much "zero". I say "fairly honestly" because there is still a small amount of #ifdef in the C code. Though the amount of #ifdef we have at present is fairly small and the number of systems it supports is fairly large. And even the generated C code might have some system-dependencies to be smushed out perhaps. autoconf might help. The C-generating backend would theoretically and really probably for real work with HP-UX, AIX, Irix, Android, iPhone, VMS, etc. besides the usual assortment of NT (including AMD64, IA64), Linux, Solaris, FreeBSD, NetBSD, OpenBSD (modulo the threading/context problems), Darwin. (iPhone has a problem with the signal headers perhaps). - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: Re: [M3devel] main in C or not? Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:21:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:21:13 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , , , , Message-ID: (sorry, some hotmail error caused 3 sends) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Aug 24 03:06:41 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 23 Aug 2010 21:06:41 -0400 Subject: [M3devel] main in C or not? In-Reply-To: References: Message-ID: <20100824010641.GA22229@topoi.pooq.com> On Tue, Aug 24, 2010 at 12:12:14AM +0000, Jay K wrote: > > Randy, yes, that is my same understanding, from fairly recent experience. > > > They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: > extern const int max_this = 100; > extern const int max_that = 200; > etc. > > > Certain updates involve changes to that file, recompile it, relink. > As such, not much of a C compiler is needed. Watch out for binary libraries fetched in by the C compiler. Depending on license, they may prohibit making a binary distribution. -- hendrik From hosking at cs.purdue.edu Tue Aug 24 03:14:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 23 Aug 2010 21:14:52 -0400 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> 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 23 Aug 2010, at 17:51, Jay K wrote: > Hm. Interesting subtle angle you point out. > I have seen very few systems with ld but not cc. e.g. OLPC default install. > My HP-UX/hppa machine came with only a K&R cc. > Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. > AIX maybe also. > We could potentially call ld directly. > But in general I don't write the configuration files that way, they run cc for linking. > *.c is used a bunch in m3core but not much else. > > > On the other hand: > cc is fairly ubiquitous. > We have a "plan" for a "new distribution format" that will require cc -- users will build more of the > system. Though we'll still provide binaries for some systems. > > > I'm *really* interested in a C-generating backend, which will subsume this. How will source-level debugging work in this instance? > Except perhaps systems like NT386, and maybe we'll expand that set. > I'm becoming increasingly frustrated with the gcc backend. > > > I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration > is ignored. > > > I'll still go ahead and make the C code typesafe via ANSI prototypes. > (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef > all the breakage, or require an ANSI compiler such as gcc; I assume nobody really > cares about K&R). > > > Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, > but I admit I didn't fully debug these. And then, removing variations among configurations, I like. > But that can be achieved via the small change for now and leaving the support in. > > > - Jay > > > Date: Mon, 23 Aug 2010 13:57:01 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] main in C or not? > > > > Quoting Jay K : > > > > > There has long been a configuration variable: MAIN_IN_C. > > > > > > I propose that main always be in C. I made that so already, a small change. > > > > > > I further propose that the support for main to not be in C be removed. > > > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > > going through the gcc backend for Posix. > > > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > > > I have this change about ready. > > > > > > I don't think avoiding C is valuable and I'd rather have fewer > > > configuration variables. > > > Pick one approach that works reasonably always. > > > > This requires that every user must have a C compiler in addition to > > cm3. I thought the default was not to generate C, and just require > > a C compiler for special runtime support. > > > > I'm not sure if this really a valid argument for the systems we support > > though, as we also need a system linker, and that is probably bundled with > > the C compiler in a development package. > > > > 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 Tue Aug 24 06:50:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 04:50:38 +0000 Subject: [M3devel] main in C or not? In-Reply-To: <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> Message-ID: >> [Jay] I'm *really* interested in a C-generating backend, which will subsume this. > [Tony How will source-level debugging work in this instance? #line directiives should be used. stock gdb will have very good type information where today it has virtually none. Besides the other debuggers like windbg/VisualStudio. Expressions would be in C perhaps. You could still hack on m3gdb if you really want, but it seems of reduced utility. Compilation would likely be slower. It might be a few steps backwards besides a few steps forward. I find the lure of portability and possibly much improved exception handling (where applicable in C, else in C++), and source distribution, a very high benefit and worth some tradeoff. We'd also lose the GPL, which would please some people. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 24 07:26:14 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 24 Aug 2010 07:26:14 +0200 Subject: [M3devel] main in C or not? also, backend.... In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> , , <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> Message-ID: <1282627574.2694.37.camel@localhost> Looks like a lobotomy for me. GNU Pascal folks are on similar crossroads now, only they are forced because they follow GCC changes "in realtime", as opposed to fixed version approach used by cm3. C *is* assembly and approach, except this debugger/debugging lobotomy thing, is sound. Except - there are better assemblies, and if we are divorcing cm3 from GCC then let's do it properly - going LLVM way. On Tue, 2010-08-24 at 04:50 +0000, Jay K wrote: > stock gdb will have very good type information where today it has > virtually none. > Besides the other debuggers like windbg/VisualStudio. > Expressions would be in C perhaps. > You could still hack on m3gdb if you really want, but it seems of > reduced utility. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 24 07:46:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 05:46:48 +0000 Subject: [M3devel] main in C or not? also, backend.... In-Reply-To: <1282627574.2694.37.camel@localhost> References: ,, , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>,, ,, <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu>, , <1282627574.2694.37.camel@localhost> Message-ID: You could say the same thing about the gcc internal representation, but no. C is a much more portable more documented more implemented more known assembly. - Jay > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Tue, 24 Aug 2010 07:26:14 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? also, backend.... > > Looks like a lobotomy for me. > > GNU Pascal folks are on similar crossroads now, only they are forced > because they follow GCC changes "in realtime", as opposed to fixed > version approach used by cm3. > > C *is* assembly and approach, except this debugger/debugging lobotomy > thing, is sound. Except - there are better assemblies, and if we are > divorcing cm3 from GCC then let's do it properly - going LLVM way. > > On Tue, 2010-08-24 at 04:50 +0000, Jay K wrote: > > stock gdb will have very good type information where today it has > > virtually none. > > Besides the other debuggers like windbg/VisualStudio. > > Expressions would be in C perhaps. > > You could still hack on m3gdb if you really want, but it seems of > > reduced utility. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 08:02:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 06:02:05 +0000 Subject: [M3devel] remove/rename NT386GNU/NT386MINGNU Message-ID: I'm assuming nobody here uses NT386GNU or NT386MINGNU. I'll remove them. They are replaced by I386_CYGWIN, I386_MINGW, which I think also nobody uses. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 08:18:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 06:18:50 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: , <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com>, Message-ID: aha, regression/defs.sh copied all the uname stuff out of sysinfo.sh.. I hand fixed the config already but will fix defs.sh.. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: VM for I386_NETBSD Hudson Date: Mon, 23 Aug 2010 10:57:00 +0000 I noticed this too. Not sure yet where it comes from. Would folks mind if I removed "NetBSD2_i386" from the system completely? I don't think anybody uses it.. I386_NETBSD serves about the same purpose. - Jay > Date: Fri, 20 Aug 2010 14:58:09 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: VM for I386_NETBSD Hudson > > The installed cm3 still uses the wrong target platform name: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. > Fix config? > > Olaf > > Quoting Jay K : > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, > > pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 08:51:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 06:51:04 +0000 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> References: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> Message-ID: Olaf, ssh and cvs are usually failing now. It is quite bad now. I have to retry cvs -z3 diff and cvs -z3 commit multiple times to get them to work. - Jay > Date: Mon, 23 Aug 2010 13:41:40 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] changes in CM3 continuous integration setup > > Quoting Jay K : > > > I don't really understand all of this. > > Surely CVS can tolerate more than 10 "active" users? > > Or is it really awful? > > (or, most likely, both) > > What if they all poll much less than once an hour? > > It's not just CVS. The machine is running our WWW services, FTP, > CVSup, backup for several hosts and secondary mail services. > > > Let's say we have 12 machines. > > Have them each poll 4 times per day: 48 polls. > > So that's just one operation every 30 minutes. > > One poll, possibly followed by one update. > > That would be an individual setup for all jobs regarding polling. > It's of course possible, but more tedious work again. > > > Or, didn't you set it up so only one machine polled and all the > > other builds would follow it, serially? > > If not, that makes sense. > > Have one machine poll every 30 minutes. > > If it finds something, it builds, and the next one builds. > > If it finds nothing, then nothing occurs. > > Surely this would work ok? > > It merely serializes all of our Hudson jobs? > > Which is, granted, rather unfortunate. > > Adding machines should allow great parallelism. > > And CVS is read-mostly, so should handle plenty of load. > > "Read-mostly" being > > a property that makes systems easier to scale. > > The current setup is suboptimal. > I've changed things in a way that could be done quickly. > But it's not easy to foretell how any change will affect the load > and responsiveness, as it isn't even clear where the limits are; and > other services are continually competing for resources, too. > > I've set up continuous logging of system load, top and iotop. > You can get a quick summary with this job: > > http://hudson.modula3.com:8080/view/zzz/job/sysload > > We'll monitor this for some days and see how our changes affect > the situation. > > Complete logs are written to Hudson's ~/log/ directory. > > > I assume if I bothered to learn to use cvsup, it would help much? > > We'd have a few mirrors and it'd "fan out well"? > > e.g. 5 cvsup mirrors could each serve 5 cvs clients, 25 for the price of 5? > > I think we'd only need one CVS mirror that the continous integration > could use. Unfortunately, our system administrator is on vacance (his wife's > expecting their second baby) right now, and I haven't got any machine > for that readily available. > > We'll sort that out, though; don't worry too much. It may need some > weeks, but we'll find an acceptable solution without much limitations. > > 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 wagner at elegosoft.com Tue Aug 24 09:55:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 09:55:42 +0200 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: References: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> Message-ID: <20100824095542.gsanecbbgko0c8w0@mail.elegosoft.com> Quoting Jay K : > Olaf, ssh and cvs are usually failing now. It is quite bad now. > I have to retry cvs -z3 diff and cvs -z3 commit multiple times to > get them to work. No use to retry in such situations, better wait a quarter of an hour. Yes, that's one of those outages we have observed for some time now. I happened to notice and observe this one. I think it was caused by two backup processes using most of the i/o bandwidth and then several CVS server instances pile up while waiting for disk blocks and prevent each other from making much progress. I think we really need a CVS mirror (as we cannot easily improve the i/o system). Sigh. I tried to stop most of the CVS processes, but response and recovery was very slow nonetheless. Things should have calmed down in the meantime 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 Tue Aug 24 10:53:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 10:53:44 +0200 Subject: [M3devel] changes in CM3 continuous integration setup Message-ID: <20100824105344.eeeppqbtus4skgoc@mail.elegosoft.com> >> AMD64_LINUX --> AMD64_DARWIN >> --> AMD64_FREEBSD -//-> PPC_DARWIN --> I386_DARWIN >> --> I386_NETBSD >> --> I386_OPENBSD >> --> SOLsun-opencsw-curent9s >> --> SOLsun-opencsw-curent10s >> --> I386_SOLARIS-opencsw-curent10x >> -//-> FreeBSD4 --> LINUXLIBC6 >> --> NT386 >> --> PPC_LINUX >> --> SPARC32_LINUX >> --> SOLgnu changed again -- further reduce build load two continuous integration servers on AMD64 and SPARC architecture AMD64_FREEBSD polls for changes every 15 minutes \------> SOLsun-opencsw-curent10s AMD64_LINUX polls once per day 23:20/55 PPC_DARWIN polls once per day 22:22/52 \----> I386_DARWIN \---> I386_NETBSD \--> I386_OPENBSD FreeBSD4 polls once per day 21:14/40 \--------> LINUXLIBC6 \-------> NT386 \------> PPC_LINUX SOLsun-opencsw-curent9s polls once per day 1:14/44 \------> I386_SOLARIS-opencsw-curent10x AMD64_DARWIN polls once per day 0:18/48 SPARC32_LINUX polls once per day 3:18/48 SOLgnu on demand only (--> opencsw job) SOLsun on demand only (--> opencsw job) Further changes to reduce build and CVS load may be made until we've set up a CVS mirror or moved away other services from birch. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 24 10:59:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 08:59:08 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: , <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com>, , Message-ID: This worked now. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: VM for I386_NETBSD Hudson Date: Tue, 24 Aug 2010 06:18:50 +0000 aha, regression/defs.sh copied all the uname stuff out of sysinfo.sh.. I hand fixed the config already but will fix defs.sh.. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: VM for I386_NETBSD Hudson Date: Mon, 23 Aug 2010 10:57:00 +0000 I noticed this too. Not sure yet where it comes from. Would folks mind if I removed "NetBSD2_i386" from the system completely? I don't think anybody uses it.. I386_NETBSD serves about the same purpose. - Jay > Date: Fri, 20 Aug 2010 14:58:09 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: VM for I386_NETBSD Hudson > > The installed cm3 still uses the wrong target platform name: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. > Fix config? > > Olaf > > Quoting Jay K : > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, > > pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 11:40:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 09:40:20 +0000 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100824105344.eeeppqbtus4skgoc@mail.elegosoft.com> References: <20100824105344.eeeppqbtus4skgoc@mail.elegosoft.com> Message-ID: It's still seeming really bad for me..can't work this way.. - Jay > Date: Tue, 24 Aug 2010 10:53:44 +0200 > From: wagner > To: m3devel > Subject: Re: [M3devel] changes in CM3 continuous integration setup > > changed again -- further reduce build load -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 24 12:37:30 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 24 Aug 2010 12:37:30 +0200 Subject: [M3devel] ***SPAM*** RE: main in C or not? also, backend.... In-Reply-To: References: ,, , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> ,, ,, <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> , ,<1282627574.2694.37.camel@localhost> Message-ID: <1282646250.3321.35.camel@localhost> And with C you divorce source level from debugging. Also, Modula-3 was there, early in it's lifetime. For some reason, SRC team went debate-RMS route. IMO, it's better to make effort for better dwarf info to object code, and even better to go LLVM. On Tue, 2010-08-24 at 05:46 +0000, Jay K wrote: > You could say the same thing about the gcc internal representation, > but no. > C is a much more portable more documented more implemented more known > assembly. > > - Jay > > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Tue, 24 Aug 2010 07:26:14 +0200 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] main in C or not? also, backend.... > > > > Looks like a lobotomy for me. > > > > GNU Pascal folks are on similar crossroads now, only they are forced > > because they follow GCC changes "in realtime", as opposed to fixed > > version approach used by cm3. > > > > C *is* assembly and approach, except this debugger/debugging > lobotomy > > thing, is sound. Except - there are better assemblies, and if we are > > divorcing cm3 from GCC then let's do it properly - going LLVM way. > > > > On Tue, 2010-08-24 at 04:50 +0000, Jay K wrote: > > > stock gdb will have very good type information where today it has > > > virtually none. > > > Besides the other debuggers like windbg/VisualStudio. > > > Expressions would be in C perhaps. > > > You could still hack on m3gdb if you really want, but it seems of > > > reduced utility. > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From wagner at elegosoft.com Tue Aug 24 17:08:47 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 17:08:47 +0200 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: <20100824170847.alrnx5h5q8wg484k@mail.elegosoft.com> Quoting Jay K : > I'm *really* interested in a C-generating backend, which will subsume this. > Except perhaps systems like NT386, and maybe we'll expand that set. > I'm becoming increasingly frustrated with the gcc backend. The tide comes and goes. The DEC SRC people were very frustrated with the C-generating M3 compiler long ago, and invested large efforts to build the gcc backend ;-) I think I remember that Bill Kalsow, who wrote much of the original compiler code, said that "C was a very mediocre choice as an intermediate language". (It may have been somebody else who said this though.) > I can compromise and leave the code in m3linker, but I still like > the change in cm3 where the configuration > is ignored. Yes, I think we should not unnecessarily remove this. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 24 17:17:28 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 17:17:28 +0200 Subject: [M3devel] remove/rename NT386GNU/NT386MINGNU In-Reply-To: References: Message-ID: <20100824171728.ti1edlk740owc84k@mail.elegosoft.com> Quoting Jay K : > > I'm assuming nobody here uses NT386GNU or NT386MINGNU. > I'll remove them. > They are replaced by I386_CYGWIN, I386_MINGW, which I think also nobody uses. I would like to add a Cygwin build to our Hudson setup, if only the elego-win-vm wasn't so slow and so much offline. 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 Aug 26 11:45:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 09:45:01 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? Message-ID: Olaf, I have some temporary so far hypothetical interest in trying gcc 4.3.0 again -- the SOLgnu/SOLsun problem with 4.3.5. ? Really, hopefully that's not something needed long term. I have some possibly lasting so far hypothetical interest in another gcc fork -- to fork OpenBSD's 4.2.1. ?Though I guess I can try to apply their patches to 4.5.1. It is trivial and reasonable? Or it would be a pain in Hudson? ? In paritcular the notion of gcc-openbsd in a separate repository? ? I actually think maybe we should use gcc-apple for *_DARWIN but Tony disagreed and mainline seems ok. ? It is for ARM_DARWIN, which isn't in great shape (Hudson?! :) ) I'm open to moving the existing gcc (gcc-4.3/gcc-4.3.5) to its own repository. And the existing gcc-apple to its own. (Besides, a C backends wipes this all away. : ) ) I don't much like CVS but I have slowly learned to use it a bit. ? My favorite by far by far is Perforce. We could possibly use it free for open source work. ? I have lots of experience with it. It is fast. It has good gui. It has atomic changes. It does branching right (unlike svn which does branching completely wrong) I have no experience with anything else -- svn, mtn, git, hg, etc. ?- Jay From jay.krell at cornell.edu Thu Aug 26 11:46:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 09:46:54 +0000 Subject: [M3devel] moving the old gcc-4.1.1? Message-ID: Olaf, would be reasonable, easy, profitable to move the old: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.1.1/ to its own repository? Just a simple mv and done? ? Or more involved, e.g. to update existing CVS checkouts? I believe its presence slows down everyone's update/checkout. And benefits only folks interested in "archaelogoy". Maybe a gcc-4.1.1/readme.txt could be dropped in pointing to the new location? ?- Jay From wagner at elegosoft.com Thu Aug 26 12:59:16 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 26 Aug 2010 12:59:16 +0200 Subject: [M3devel] additional CVS repositories for additional gcc forks? Message-ID: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> Quoting Jay K : > Olaf, I have some temporary so far hypothetical interest in trying > gcc 4.3.0 again -- the SOLgnu/SOLsun problem with 4.3.5. > ? Really, hopefully that's not something needed long term. > > I have some possibly lasting so far hypothetical interest in another > gcc fork -- to fork OpenBSD's 4.2.1. > ?Though I guess I can try to apply their patches to 4.5.1. > > It is trivial and reasonable? > Or it would be a pain in Hudson? The main problem wrt. performance and i/o load is importing different gcc versions in different directories and not as different versions. Thus they get stored as lots of new different files, which all need to be read and their directories locked. The gcc structure is huge compared to all the M3 code. Of course, if we use the gcc versions in parallel, i.e. they are variants in one of our configuration, this is actually needed. It might help if you postpone your gcc projects for some weeks until we've either moved our WWW services or setup a repository mirror or whatever. > ? In paritcular the notion of gcc-openbsd in a separate repository? > ? I actually think maybe we should use gcc-apple for *_DARWIN but > Tony disagreed and mainline seems ok. > ? It is for ARM_DARWIN, which isn't in great shape (Hudson?! :) ) > > I'm open to moving the existing gcc (gcc-4.3/gcc-4.3.5) to its own > repository. > And the existing gcc-apple to its own. I wouldn't like to change much now, just remove what we really don't need. > (Besides, a C backends wipes this all away. : ) ) No. I would see a C backend as a variant (option) too, but probably not use it on platforms were I can compile without it. > I don't much like CVS but I have slowly learned to use it a bit. > ? My favorite by far by far is Perforce. We could possibly use it > free for open source work. Perforce is nice, agreed. I haven't used it much in practice though. I'm not sure how much effort it would cost us to get a Perforce setup, and if all users would be comfortable with it. > I have lots of experience with it. It is fast. It has good gui. It > has atomic changes. It does branching right (unlike svn which does > branching completely wrong) I wouldn't say that, though subversion still has several severe problems with merging, especially tree merges. > I have no experience with anything else -- svn, mtn, git, hg, etc. We (Elego) have, but the experience of the M3 developers will vary very much I think. Git may be an interesting option, though I'm not sure if it is really mature enough and has got all the infrastructure support we may need. We've got commercial customers who are thinking about switching over to it completely though. As I've said before, switching to another version control system will involve much tedious work, and I cannot contribute much (time) for that. However, if the M3 community decides to use something different and plans and implements a reasonable migration to the new tool(s), I wouldn't object to that. 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 Thu Aug 26 13:03:33 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 26 Aug 2010 13:03:33 +0200 Subject: [M3devel] moving the old gcc-4.1.1? In-Reply-To: References: Message-ID: <20100826130333.i4d6awas088g0cw0@mail.elegosoft.com> Quoting Jay K : > Olaf, would be reasonable, easy, profitable to move the old: > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.1.1/ > > to its own repository? > Just a simple mv and done? > ? Or more involved, e.g. to update existing CVS checkouts? > > I believe its presence slows down everyone's update/checkout. > And benefits only folks interested in "archaelogoy". > > Maybe a gcc-4.1.1/readme.txt could be dropped in pointing to the new > location? We can just move it to another path in /usr/cvs, i.e. /usr/cvs/unused/cm3/m3cc/gcc-4.11 or however you'd like to call it. I'm not sure if the updates will just complain that something has vanished from the repository (I think so) or if they will fail: we need to check this. 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 Aug 26 13:34:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 11:34:54 +0000 Subject: [M3devel] passing structs by value Message-ID: On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. I really can't follow the complicated rules here: ?? http://www.x86-64.org/documentation/abi-0.99.pdf? but suffice it to say, records can be passed in registers, but it depends on the types of their fields. As much as we don't pass/return records by value between Modula-3 and C, that is ok. As long as Modula-3 callers/recievers agree. And they do, but... The gcc backend is given good type information at first, but historically throws much of it away. As you start to repair that, it starts following the ABI. At least at the callee side. I think the caller is still devoid of type information. I'm assuming there is a fallback rule for the case of missing type information. So if you give just one side the type information, you get a mismatch, bad code. Passing records in registers is nice, but.. (reminder: I think historically we never did). I thin we should probably just change the frontend to handle passing records by value itself. Like it does for I386_NT/NT386. For any record parameter, introduce a temporary in the caller and pass its address. ? Or whatever the code is already prepared to do. We should probably handle records returned by value similarly. This decision can be revisited if/when there is a C backend. Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. I doubt anyone else is either. I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. Further long term deficiencies this uncovers, I'm very inclined to dig further into. The right fix is probably to maintain types in the expression stack. Or at least throw in more casts on the pops. I don't think pop_param presently recieves enough type information -- no type id. ?- Jay From jay.krell at cornell.edu Thu Aug 26 13:36:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 11:36:51 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: Message-ID: aka: I propose Target.i3 standard_structs always be true, and therefore remove it and propagate true through m3front. Or at least make it always true and leave the code in m3front for future generations to revisit.. I will go ahead and test this. ? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: passing structs by value > Date: Thu, 26 Aug 2010 11:34:54 +0000 > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > I really can't follow the complicated rules here: > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > As long as Modula-3 callers/recievers agree. And they do, but... > > > The gcc backend is given good type information at first, but historically throws much of it away. > As you start to repair that, it starts following the ABI. At least at the callee side. > I think the caller is still devoid of type information. > I'm assuming there is a fallback rule for the case of missing type information. > > So if you give just one side the type information, you get a mismatch, bad code. > > > Passing records in registers is nice, but.. > (reminder: I think historically we never did). > > > I thin we should probably just change the frontend to handle passing records by value itself. > Like it does for I386_NT/NT386. > > > For any record parameter, introduce a temporary in the caller and pass its address. > Or whatever the code is already prepared to do. > > > We should probably handle records returned by value similarly. > > > This decision can be revisited if/when there is a C backend. > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > I doubt anyone else is either. > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > The right fix is probably to maintain types in the expression stack. > Or at least throw in more casts on the pops. > > > I don't think pop_param presently recieves enough type information -- no type id. > > > - Jay > From jay.krell at cornell.edu Thu Aug 26 13:46:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 11:46:13 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> Message-ID: > No. I would see a C backend as a variant (option) too, but probably not > use it on platforms were I can compile without it. I would like to see a C backend at least replace the gcc backend. We could maybe then slowly iterate on the integrated backend. Or LLVM. It would provide more obvious correctness, better debugging, better code quality. Imagine -- basically all platforms would get stack walkers. By generating C++ for most platforms, or using C exception handling in NT/VMS/Tru64. Basically all platforms would just work. Stock debuggers would work, gdb and others. Basically no more porting. Basically all optimizations could be enabled. (Aside: I think the generated C would be sure to store gc roots in volatile locals, but not otherwise use said volatiles.) And in more recent developments, it would enregister some records passed by value. It would, in a sense, shrink the code base (cheating sort of). I'm not holding my breath on any of this. But I'm going to start trying to do more and talk less about it. - Jay ---------------------------------------- > Date: Thu, 26 Aug 2010 12:59:16 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: additional CVS repositories for additional gcc forks? > > Quoting Jay K : > > > Olaf, I have some temporary so far hypothetical interest in trying > > gcc 4.3.0 again -- the SOLgnu/SOLsun problem with 4.3.5. > > Really, hopefully that's not something needed long term. > > > > I have some possibly lasting so far hypothetical interest in another > > gcc fork -- to fork OpenBSD's 4.2.1. > > Though I guess I can try to apply their patches to 4.5.1. > > > > It is trivial and reasonable? > > Or it would be a pain in Hudson? > > The main problem wrt. performance and i/o load is importing different > gcc versions in different directories and not as different versions. > Thus they get stored as lots of new different files, which all need > to be read and their directories locked. The gcc structure is huge > compared to all the M3 code. Of course, if we use the gcc versions in > parallel, i.e. they are variants in one of our configuration, this > is actually needed. > > It might help if you postpone your gcc projects for some weeks until > we've either moved our WWW services or setup a repository mirror or > whatever. > > > In paritcular the notion of gcc-openbsd in a separate repository? > > I actually think maybe we should use gcc-apple for *_DARWIN but > > Tony disagreed and mainline seems ok. > > It is for ARM_DARWIN, which isn't in great shape (Hudson?! :) ) > > > > I'm open to moving the existing gcc (gcc-4.3/gcc-4.3.5) to its own > > repository. > > And the existing gcc-apple to its own. > > I wouldn't like to change much now, just remove what we really don't > need. > > > (Besides, a C backends wipes this all away. : ) ) > > No. I would see a C backend as a variant (option) too, but probably not > use it on platforms were I can compile without it. > > > I don't much like CVS but I have slowly learned to use it a bit. > > My favorite by far by far is Perforce. We could possibly use it > > free for open source work. > > Perforce is nice, agreed. I haven't used it much in practice though. > I'm not sure how much effort it would cost us to get a Perforce setup, > and if all users would be comfortable with it. > > > I have lots of experience with it. It is fast. It has good gui. It > > has atomic changes. It does branching right (unlike svn which does > > branching completely wrong) > > I wouldn't say that, though subversion still has several severe problems > with merging, especially tree merges. > > > I have no experience with anything else -- svn, mtn, git, hg, etc. > We (Elego) have, but the experience of the M3 developers will vary > very much I think. > > Git may be an interesting option, though I'm not sure if it is really > mature enough and has got all the infrastructure support we may need. > We've got commercial customers who are thinking about switching over to > it completely though. > > As I've said before, switching to another version control system will > involve much tedious work, and I cannot contribute much (time) > for that. However, if the M3 community decides to use something > different and plans and implements a reasonable migration to the > new tool(s), I wouldn't object to that. > > 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 Thu Aug 26 14:10:22 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 26 Aug 2010 14:10:22 +0200 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> Message-ID: <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> Quoting Jay K : > > No. I would see a C backend as a variant (option) too, but probably not > > use it on platforms were I can compile without it. > > I would like to see a C backend at least replace the gcc backend. > We could maybe then slowly iterate on the integrated backend. Or LLVM. > It would provide more obvious correctness, better debugging, better > code quality. I don't really see that yet. > Imagine -- basically all platforms would get stack walkers. > By generating C++ for most platforms, or using C exception > handling in NT/VMS/Tru64. > Basically all platforms would just work. I doubt that very much. > Stock debuggers would work, gdb and others. > Basically no more porting. > Basically all optimizations could be enabled. > (Aside: I think the generated C would be sure to store > gc roots in volatile locals, but not otherwise use said volatiles.) As I said: it has been tried before. > And in more recent developments, it would enregister some records > passed by value. > It would, in a sense, shrink the code base (cheating sort of). And it would be an order of magnitude slower. > I'm not holding my breath on any of this. > But I'm going to start trying to do more and talk less about it. I will let you convince me ;-) I've got no problem with trying that. If it's really better, we will use it. If not, we may want to use it for special situations (e.g. porting). 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 Aug 26 14:23:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 12:23:36 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> Message-ID: ?>? better code quality Use the native C++ exception handling. Not more calling setjmp all over the place. Inlining. Currnetly disabled in 4.5.1 because it breaks things. LTO/LTCG -- which we could get today, on gcc platforms, if we are willing to import even more code. ?(link time optimization, link time code gen). e.g. cross module inlining. see also PGO -- profile guided optimization. i.e. whatever the full C/C++ toolset is, you can use it. ?> better debugging ? Existing debuggers would work and work well. Notice today that NT386 has only line numbers. That there are systems that don't support stabs -- e.g. HP-UX. That other -g switches to cm3cg crash. > > Basically all platforms would just work. > > I doubt that very much. It's only a slight exaggeration. We'd still need our #ifdef'ing of the C code. Possibly guided by autoconf. And there are still the threading/gc issues. But for example, we should work on any processor for any operating system for which we already work -- NT, Linux, NetBSD, FreeBSD, Solaris, OSF -- on any processors. And AIX, Irix, VMS would work or be closer to working. (IA64 might need an #ifdef) Anyway, I'll try to work on it. > And it would be an order of magnitude slower. It would be slower. I'm not sure by how much. ?- Jay ---------------------------------------- > Date: Thu, 26 Aug 2010 14:10:22 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? > > Quoting Jay K : > > > > No. I would see a C backend as a variant (option) too, but probably not > > > use it on platforms were I can compile without it. > > > > I would like to see a C backend at least replace the gcc backend. > > We could maybe then slowly iterate on the integrated backend. Or LLVM. > > It would provide more obvious correctness, better debugging, better > > code quality. > > I don't really see that yet. > > > Imagine -- basically all platforms would get stack walkers. > > By generating C++ for most platforms, or using C exception > > handling in NT/VMS/Tru64. > > Basically all platforms would just work. > > I doubt that very much. > > > Stock debuggers would work, gdb and others. > > Basically no more porting. > > Basically all optimizations could be enabled. > > (Aside: I think the generated C would be sure to store > > gc roots in volatile locals, but not otherwise use said volatiles.) > > As I said: it has been tried before. > > > And in more recent developments, it would enregister some records > > passed by value. > > It would, in a sense, shrink the code base (cheating sort of). > > And it would be an order of magnitude slower. > > > I'm not holding my breath on any of this. > > But I'm going to start trying to do more and talk less about it. > > I will let you convince me ;-) > I've got no problem with trying that. If it's really better, we will > use it. If not, we may want to use it for special situations (e.g. porting). > > 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 Aug 27 08:14:05 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 08:14:05 +0200 Subject: [M3devel] Fwd: [CM3] #1148: CVSup stalls on several platforms Message-ID: <20100827081405.vw7d059ulcg8wgcc@mail.elegosoft.com> FYI -- I thought this was working, but it's still broken... ----- Forwarded message from bugs at elego.de ----- Date: Fri, 27 Aug 2010 06:05:05 -0000 From: CM3 Reply-To: CM3 Subject: [CM3] #1148: CVSup stalls on several platforms To: wagner at elego.de #1148: CVSup stalls on several platforms --------------------------+------------------------------------------------- Reporter: wagner | Owner: wagner Type: sw-bug | Status: new Priority: high | Milestone: CM3 Release 5.9 Component: misc | Version: 5.8-RC3 Severity: serious | Keywords: cvsup, stalling, hanging, pthreads Relnote: | Org: Estimatedhours: 0 | Hours: 0 Billable: 0 | Totalhours: 0 Internal: 0 | --------------------------+------------------------------------------------- Htr: try to mirror the cm3 repository, possible any other, too Fix: Env: --------------------------+------------------------------------------------- We either still have a problem with fork, or in the pthreads implementation. Here's some evidence from a mail thread: I do, but I'm having trouble with cvsup from release_branch_cm3_5_8 LINUXLIB6. It stalls and hangs after a few minutes. strace says this forever: clone(child_stack=0xb140f4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb140fbd8, {entry_number:6, base_addr:0xb140fb90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb140fbd8) = 20265 write(1, "Running\n"..., 8Running ) = 8 futex(0x80ac0cc, FUTEX_WAIT, 5, NULL) = -1 EINTR (Interrupted system call) --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- rt_sigsuspend(~[INT QUIT ABRT TERM RTMIN RT_1] --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- <... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call) rt_sigreturn(0xb7aedf00) = -1 EINTR (Interrupted system call) rt_sigreturn(0x80ac0cc) = -1 EINTR (Interrupted system call) futex(0x80ac0cc, FUTEX_WAIT, 5, NULL) = -1 EINTR (Interrupted system call) --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- rt_sigsuspend(~[INT QUIT ABRT TERM RTMIN RT_1] --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- <... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call) rt_sigreturn(0xb7aedf00) = -1 EINTR (Interrupted system call) rt_sigreturn(0x80ac0cc) = -1 EINTR (Interrupted system call) futex(0x80ac0cc, FUTEX_WAIT, 5, NULL) = -1 EINTR (Interrupted system call) --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- rt_sigsuspend(~[INT QUIT ABRT TERM RTMIN RT_1] --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- Any ideas there? Maybe I'll just reinstall with FreeBSD ;-) Is this with the actual release (5.8.6) or any RC? Yes, I used cm3-bin-core-LINUXLIBC6-5.8.6-REL.tgz and cm3-src-all-5.8.6-REL.tgz with. wiley:/home/mand# cvsup -v CVSup client, GUI version Copyright 1996-2003 John D. Polstra Software version: release_branch_cm3_5_8 Protocol version: 17.0 Operating system: LINUXLIBC6 @Jay, you did correct the process startup so that CVSup should work, didn't you? Any ideas about this one? @Mike, can you attach with gdb and get a stack backtrace? Here it is... wiley:/home/mand# gdb -p 32607 GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". Attaching to process 32607 Reading symbols from /usr/local/cm3/bin/cvsup...done. Reading symbols from /usr/local/cm3/lib/libm3formsvbt.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3formsvbt.so.5 Reading symbols from /usr/local/cm3/lib/libm3formsvbtpixmaps.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3formsvbtpixmaps.so.5 Reading symbols from /usr/local/cm3/lib/libvideovbt.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libvideovbt.so.5 Reading symbols from /usr/local/cm3/lib/libweb.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libweb.so.5 Reading symbols from /usr/local/cm3/lib/libjvideo.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libjvideo.so.5 Reading symbols from /usr/local/cm3/lib/libm3vbtkit.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3vbtkit.so.5 Reading symbols from /usr/local/cm3/lib/libm3ui.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3ui.so.5 Reading symbols from /usr/local/cm3/lib/libm3X11R4.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3X11R4.so.5 Reading symbols from /usr/local/cm3/lib/libsuplib.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libsuplib.so.5 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/local/cm3/lib/libm3tcp.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3tcp.so.5 Reading symbols from /usr/local/cm3/lib/libset.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libset.so.5 Reading symbols from /usr/local/cm3/lib/libTempFiles.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libTempFiles.so.5 Reading symbols from /usr/local/cm3/lib/libm3.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3.so.5 Reading symbols from /usr/local/cm3/lib/libm3core.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3core.so.5 Reading symbols from /usr/lib/libXaw.so.7...done. Loaded symbols for /usr/lib/libXaw.so.7 Reading symbols from /usr/lib/libXmu.so.6...done. Loaded symbols for /usr/lib/libXmu.so.6 Reading symbols from /usr/lib/libXext.so.6...done. Loaded symbols for /usr/lib/libXext.so.6 Reading symbols from /usr/lib/libXt.so.6...done. Loaded symbols for /usr/lib/libXt.so.6 Reading symbols from /usr/lib/libSM.so.6...done. Loaded symbols for /usr/lib/libSM.so.6 Reading symbols from /usr/lib/libICE.so.6...done. Loaded symbols for /usr/lib/libICE.so.6 Reading symbols from /usr/lib/libX11.so.6...done. Loaded symbols for /usr/lib/libX11.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 0xb6ec26b0 (LWP 32607)] [New Thread 0xb140fb90 (LWP 32617)] [New Thread 0xb1e0fb90 (LWP 32616)] [New Thread 0xb320fb90 (LWP 32614)] [New Thread 0xb3c0fb90 (LWP 32613)] [New Thread 0xb460fb90 (LWP 32612)] [New Thread 0xb5051b90 (LWP 32611)] [New Thread 0xb5a7fb90 (LWP 32610)] [New Thread 0xb647fb90 (LWP 32609)] [New Thread 0xb6e7fb90 (LWP 32608)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libXpm.so.4...done. Loaded symbols for /usr/lib/libXpm.so.4 Reading symbols from /usr/lib/libXau.so.6...done. Loaded symbols for /usr/lib/libXau.so.6 Reading symbols from /usr/lib/libxcb-xlib.so.0...done. Loaded symbols for /usr/lib/libxcb-xlib.so.0 Reading symbols from /usr/lib/libxcb.so.1...done. Loaded symbols for /usr/lib/libxcb.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libXdmcp.so.6...done. Loaded symbols for /usr/lib/libXdmcp.so.6 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_mdns4_minimal.so.2...done. Loaded symbols for /lib/libnss_mdns4_minimal.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libnss_compat.so.2...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libnss_nis.so.2...done. Loaded symbols for /lib/libnss_nis.so.2 0xb6f2599d in sigsuspend () from /lib/libc.so.6 (gdb) bt #0 0xb6f2599d in sigsuspend () from /lib/libc.so.6 #1 0xb72a7ece in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 #2 0xb72a6d56 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=64, M3_AJWxb1_info=0xbfffc6f0, M3_AJWxb1_context=0xbfffc770) at ../src/thread/PTHREAD/ThreadPThread.m3:1205 #3 #4 0xb70438f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #5 0xb72a84d6 in ThreadPThread__pthread_cond_wait (cond=0x80ac0c8, mutex=0x80ac0a8) at ../src/thread/PTHREAD/ThreadPThreadC.c:507 #6 0xb72a29a9 in ThreadPThread__XWait (M3_DMxDjQ_self=0x80ac018, M3_AYIbX3_m=0xb6e84bc4, M3_Bl0jv4_c=0xb6e84bdc, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #7 0xb72a2a71 in Thread__AlertWait (M3_AYIbX3_m=0xb6e84bc4, M3_Bl0jv4_c=0xb6e84bdc) at ../src/thread/PTHREAD/ThreadPThread.m3:196 #8 0xb7cdd671 in Reaper__AlertJoinNext (M3_Cjq8Fl_reaper=0xb6e84bc4, M3_DTZVTc_thr=0xbfffcf50, M3_EKuYlT_ret=0xbfffcf54) at ../src/Reaper.m3:111 #9 0x08079323 in FSClient__Apply (M3_EVLLAD_self=0xb6eb5ab8) at ../src/FSClient.m3:201 #10 0x08091e26 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:398 #11 0xb7292ccb in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a6d40) at ../src/runtime/common/RTLinker.m3:406 #12 0xb7291ffe in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a6d40) at ../src/runtime/common/RTLinker.m3:113 #13 0xb729208c in RTLinker__AddUnit (M3_DjPxE5_b=0x808d275) at ../src/runtime/common/RTLinker.m3:122 #14 0x0804e9ce in main (argc=6, argv=0xbfffd914, envp=0xbfffd930) at _m3main.mc:4 (gdb) 2 or 3 thoughts: o Did you turn off the GUI (I think -g)? Yes. o Did you increase the debugging level (-L 2?)? Yes. o Have you tried an old binary e.g. from our DCVS packages? Not yet. I'll try that next. [update: yes, it works, needs libc6-i386 of course] I upgraded my vServer and installed a 64-bit Ubuntu with cm3 from AMD_64 sources, but encountered the same stall. I thought perhaps this might have to do with the modified kernel or ulimits on the vServer, but as it turns out, cvsup on birch also hangs, as well as on willow (Ubuntu i386). -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 Aug 27 08:14:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 08:14:59 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms Message-ID: <20100827081459.s88b14400448owk8@mail.elegosoft.com> FYI -- fixed version info (5.8.6) ----- Forwarded message from bugs at elego.de ----- Date: Fri, 27 Aug 2010 06:09:55 -0000 From: CM3 Reply-To: CM3 Subject: Re: [CM3] #1148: CVSup stalls on several platforms To: wagner at elego.de #1148: CVSup stalls on several platforms --------------------------+------------------------------------------------- Reporter: wagner | Owner: wagner Type: sw-bug | Status: new Priority: high | Milestone: CM3 Release 5.9 Component: misc | Version: 5.8.6 Severity: serious | Keywords: cvsup, stalling, hanging, pthreads Relnote: | Org: Estimatedhours: 0.0 | Hours: 0 Billable: 0 | Totalhours: 0 Internal: 0 | --------------------------+------------------------------------------------- Htr: try to mirror the cm3 repository, possible any other, too Fix: Env: --------------------------+------------------------------------------------- Changes (by wagner): * version: 5.8-RC3 => 5.8.6 -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 Fri Aug 27 09:01:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 07:01:57 +0000 Subject: [M3devel] m3cc often succeeds when it should fail Message-ID: I finally looked into this. The reason is that the exit code of a pipeline is the last command. Seems kind of dumb and I don't like any of the options. I like having tee in there to save a log. There is a way to deal it with bash, zsh, and it takes a big function to do it in standard sh. Maybe q_exec or m3_exec? It looks like no. I suppose we could wrap up everything in a .sh file, detect bash 3 or newer, and use set -o pipefail? ?- Jay From jay.krell at cornell.edu Fri Aug 27 09:19:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 07:19:59 +0000 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: References: Message-ID: We could introduce a new quake feature.. if defined("set_pipefail") ? set_pipefail() end q_exec() ? ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 27 Aug 2010 07:01:57 +0000 > Subject: [M3devel] m3cc often succeeds when it should fail > > > I finally looked into this. > > The reason is that the exit code of a pipeline is the last command. > Seems kind of dumb and I don't like any of the options. > I like having tee in there to save a log. > > There is a way to deal it with bash, zsh, and it takes a big function to do it in standard sh. > > Maybe q_exec or m3_exec? > It looks like no. > > I suppose we could wrap up everything in a .sh file, detect bash 3 or newer, and use set -o pipefail? > > - Jay > From jay.krell at cornell.edu Fri Aug 27 11:12:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 09:12:00 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: , Message-ID: Easier said than done. Setting standard_structs = TRUE I thought would free the backend from worrying about passing or returning structs at all, but that's far from true. I thought the frontend would introduce temporaries and pass their addresses. But no. See for example what M3x86 does in pop_struct. Frustrating. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: passing structs by value > Date: Thu, 26 Aug 2010 11:36:51 +0000 > > > aka: I propose Target.i3 standard_structs always be true, and therefore remove it and propagate true through m3front. > Or at least make it always true and leave the code in m3front for future generations to revisit.. > > I will go ahead and test this. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: passing structs by value > > Date: Thu, 26 Aug 2010 11:34:54 +0000 > > > > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > I really can't follow the complicated rules here: > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > As you start to repair that, it starts following the ABI. At least at the callee side. > > I think the caller is still devoid of type information. > > I'm assuming there is a fallback rule for the case of missing type information. > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > Passing records in registers is nice, but.. > > (reminder: I think historically we never did). > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > Like it does for I386_NT/NT386. > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > Or whatever the code is already prepared to do. > > > > > > We should probably handle records returned by value similarly. > > > > > > This decision can be revisited if/when there is a C backend. > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > I doubt anyone else is either. > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > The right fix is probably to maintain types in the expression stack. > > Or at least throw in more casts on the pops. > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > - Jay > > > From jay.krell at cornell.edu Fri Aug 27 11:21:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 09:21:42 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: , , Message-ID: Hm. I think the right fix here is to pass a typeid to pop_struct. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: passing structs by value > Date: Fri, 27 Aug 2010 09:12:00 +0000 > > > Easier said than done. > Setting standard_structs = TRUE I thought would free the backend from worrying > about passing or returning structs at all, but that's far from true. > I thought the frontend would introduce temporaries and pass their addresses. But no. > > See for example what M3x86 does in pop_struct. > Frustrating. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: RE: passing structs by value > > Date: Thu, 26 Aug 2010 11:36:51 +0000 > > > > > > aka: I propose Target.i3 standard_structs always be true, and therefore remove it and propagate true through m3front. > > Or at least make it always true and leave the code in m3front for future generations to revisit.. > > > > I will go ahead and test this. > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Subject: passing structs by value > > > Date: Thu, 26 Aug 2010 11:34:54 +0000 > > > > > > > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > > > I really can't follow the complicated rules here: > > > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > > As you start to repair that, it starts following the ABI. At least at the callee side. > > > I think the caller is still devoid of type information. > > > I'm assuming there is a fallback rule for the case of missing type information. > > > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > > > > Passing records in registers is nice, but.. > > > (reminder: I think historically we never did). > > > > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > > Like it does for I386_NT/NT386. > > > > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > > Or whatever the code is already prepared to do. > > > > > > > > > We should probably handle records returned by value similarly. > > > > > > > > > This decision can be revisited if/when there is a C backend. > > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > > I doubt anyone else is either. > > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > > > > The right fix is probably to maintain types in the expression stack. > > > Or at least throw in more casts on the pops. > > > > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > > > > - Jay > > > > > > From michael.anderson at elego.de Fri Aug 27 12:03:06 2010 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 27 Aug 2010 12:03:06 +0200 Subject: [M3devel] [elego Server Maintenance] Friday 27.08.2010 20:00 Message-ID: <20100827120306.2yrr0fzucgcksk0g@mail.elego.de> Hello, On Friday, August 27 at 8 PM CEST, we will perform scheduled maintenance on our servers, including the modula3 CVS server and Hudson CI server. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 27 12:29:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 10:29:41 +0000 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: <20100827081459.s88b14400448owk8@mail.elegosoft.com> References: <20100827081459.s88b14400448owk8@mail.elegosoft.com> Message-ID: Can you add more information to the bug as to how to reproduce the problem? Exact files? cvsup.conf or whatnot? Exact command lines? I don't use cvsup, don't know how to set it up. Before when I debugging this it wasn't too difficult though. Perhaps we can put something in m3-sys/m3tests even? ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 08:14:59 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms > > FYI -- fixed version info (5.8.6) > > ----- Forwarded message from bugs at elego.de ----- > Date: Fri, 27 Aug 2010 06:09:55 -0000 > From: CM3 > Reply-To: CM3 > Subject: Re: [CM3] #1148: CVSup stalls on several platforms > To: wagner at elego.de > > #1148: CVSup stalls on several platforms > --------------------------+------------------------------------------------- > Reporter: wagner | Owner: wagner > Type: sw-bug | Status: new > Priority: high | Milestone: CM3 Release 5.9 > Component: misc | Version: 5.8.6 > Severity: serious | Keywords: cvsup, stalling, hanging, pthreads > Relnote: | Org: > Estimatedhours: 0.0 | Hours: 0 > Billable: 0 | Totalhours: 0 > Internal: 0 | > --------------------------+------------------------------------------------- > Htr: > try to mirror the cm3 repository, possible any other, too > > > Fix: > > > > Env: > > > --------------------------+------------------------------------------------- > Changes (by wagner): > > * version: 5.8-RC3 => 5.8.6 > > > -- > Ticket URL: > CM3 > Critical Mass Modula3 Compiler > > > ----- End forwarded message ----- > > > -- > 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 Aug 27 13:01:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 13:01:23 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: References: <20100827081459.s88b14400448owk8@mail.elegosoft.com> Message-ID: <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com> Quoting Jay K : > Can you add more information to the bug as to how to reproduce the problem? > Exact files? cvsup.conf or whatnot? > Exact command lines? > > I don't use cvsup, don't know how to set it up. > Before when I debugging this it wasn't too difficult though. > > Perhaps we can put something in m3-sys/m3tests even? I will try to set up an automated cvsup test at the weekend. In our DCVS distribution we had quite a few replication tests; perhaps I can burrow something from that. It won't go into m3tests though, but rather be a subdir to cvsup. m3-sys/m3tests is for language/compiler tests. 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 michael.anderson at elego.de Fri Aug 27 13:25:57 2010 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 27 Aug 2010 13:25:57 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com> References: <20100827081459.s88b14400448owk8@mail.elegosoft.com> <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com> Message-ID: <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> Quoting Olaf Wagner : > Quoting Jay K : > >> Can you add more information to the bug as to how to reproduce the problem? >> Exact files? cvsup.conf or whatnot? >> Exact command lines? >> I'm able to reliably reproduce the problem with this command: /usr/local/cm3/bin/cvsup -g -L 2 cvsupfile.cm3 where the cvsupfile contains: *default host=birch.elego.de *default base=/home/mand/tmp/cvsup *default prefix=/home/mand/tmp/cvs *default release=cvs *default delete use-rel-suffix *default preserve cm3 Sometimes the first sync will finish, but a subsequent sync will hang. >> I don't use cvsup, don't know how to set it up. >> Before when I debugging this it wasn't too difficult though. >> >> Perhaps we can put something in m3-sys/m3tests even? > > I will try to set up an automated cvsup test at the weekend. > In our DCVS distribution we had quite a few replication tests; > perhaps I can burrow something from that. > > It won't go into m3tests though, but rather be a subdir to cvsup. > m3-sys/m3tests is for language/compiler tests. > > 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 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 27 13:44:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 11:44:02 +0000 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> References: <20100827081459.s88b14400448owk8@mail.elegosoft.com>, , <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com>, <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> Message-ID: Michael, thank you. Please add it to the bug. ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 13:25:57 +0200 > From: michael.anderson at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms > > Quoting Olaf Wagner : > > > Quoting Jay K : > > > >> Can you add more information to the bug as to how to reproduce the problem? > >> Exact files? cvsup.conf or whatnot? > >> Exact command lines? > >> > > > I'm able to reliably reproduce the problem with this command: > > /usr/local/cm3/bin/cvsup -g -L 2 cvsupfile.cm3 > > where the cvsupfile contains: > > *default host=birch.elego.de > *default base=/home/mand/tmp/cvsup > *default prefix=/home/mand/tmp/cvs > *default release=cvs > *default delete use-rel-suffix > *default preserve > cm3 > > Sometimes the first sync will finish, but a subsequent sync will hang. > > >> I don't use cvsup, don't know how to set it up. > >> Before when I debugging this it wasn't too difficult though. > >> > >> Perhaps we can put something in m3-sys/m3tests even? > > > > I will try to set up an automated cvsup test at the weekend. > > In our DCVS distribution we had quite a few replication tests; > > perhaps I can burrow something from that. > > > > It won't go into m3tests though, but rather be a subdir to cvsup. > > m3-sys/m3tests is for language/compiler tests. > > > > 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 > > > > -- > Michael Anderson > IT Services & Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Building 12.3 (BIG) room 227 > 13355 Berlin, Germany > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > fax +49 30 23 45 86 95 http://www.elegosoft.com > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > From jay.krell at cornell.edu Fri Aug 27 13:45:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 11:45:07 +0000 Subject: [M3devel] type id for globals? Message-ID: Is it reasonable to desire a typeid for the globals records? ie. to assist in generating type information? I guess I don't need it after all, really.. (3553) comment ? quoted_string:global data type descriptor ? comment: `global data type descriptor' (3554) declare_record ? record id:0xffffffff fields:0xc size:0x3c80 (3555) declare_field ? quoted_string:types ? field types, id 0x454792e7, size 0x240, offset 0x640 (3556) declare_field ? quoted_string:uids ? field uids, id 0x454792e7, size 0x240, offset 0x880 (3557) declare_field ? quoted_string:brands ? field brands, id 0x454792e7, size 0x240, offset 0xac0 (3558) declare_field ? quoted_string:Dummy1_typecell ? field Dummy1_typecell, id 0xf8c78b31, size 0x300, offset 0x1600 (3559) declare_field ? quoted_string:Dummy3_typecell ? field Dummy3_typecell, id 0xf8c78b31, size 0x300, offset 0x1900 (3560) declare_field ? quoted_string:NULL_typecell ? field NULL_typecell, id 0xf8c78b31, size 0x300, offset 0x1c00 (3561) declare_field ? quoted_string:UNROOT_typecell ? field UNROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x1f00 (3562) declare_field ? quoted_string:ROOT_typecell ? field ROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x23c0 (3563) declare_field From hosking at cs.purdue.edu Fri Aug 27 16:00:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Aug 2010 10:00:32 -0400 Subject: [M3devel] type id for globals? In-Reply-To: References: Message-ID: <48EBBDD6-52BE-47DB-A8C8-49413477C615@cs.purdue.edu> Not sure... haven't really been following much lately... On 27 Aug 2010, at 07:45, Jay K wrote: > > Is it reasonable to desire a typeid for the globals records? > ie. to assist in generating type information? > I guess I don't need it after all, really.. > > (3553) comment > quoted_string:global data type descriptor > comment: `global data type descriptor' > (3554) declare_record > record id:0xffffffff fields:0xc size:0x3c80 > (3555) declare_field > quoted_string:types > field types, id 0x454792e7, size 0x240, offset 0x640 > (3556) declare_field > quoted_string:uids > field uids, id 0x454792e7, size 0x240, offset 0x880 > (3557) declare_field > quoted_string:brands > field brands, id 0x454792e7, size 0x240, offset 0xac0 > (3558) declare_field > quoted_string:Dummy1_typecell > field Dummy1_typecell, id 0xf8c78b31, size 0x300, offset 0x1600 > (3559) declare_field > quoted_string:Dummy3_typecell > field Dummy3_typecell, id 0xf8c78b31, size 0x300, offset 0x1900 > (3560) declare_field > quoted_string:NULL_typecell > field NULL_typecell, id 0xf8c78b31, size 0x300, offset 0x1c00 > (3561) declare_field > quoted_string:UNROOT_typecell > field UNROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x1f00 > (3562) declare_field > quoted_string:ROOT_typecell > field ROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x23c0 > (3563) declare_field > > > > > From wagner at elegosoft.com Fri Aug 27 17:17:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 17:17:23 +0200 Subject: [M3devel] Potential bug in RTAllocator.Clone, was: Fwd: Auto-discard notification Message-ID: <20100827171723.2a60uadm0wos04gw@mail.elegosoft.com> Forwarded; sent before subscription was confirmed: The attached message has been automatically discarded. Info The following are the headers for this message/rfc822 message. Date: Fri, 27 Aug 2010 15:39:23 +0100 Subject: Potential bug in RTAllocator.Clone From: Raja Mukherji To: m3devel at elegosoft.com 2.1 unnamed [text/plain] 0.58 KB Download Hi, this is my first post to the Modula-3 mailing list... While using RTAllocator.Clone in a project, I kept getting errors related to the type of the returned object. The debugger m3gdb returned a TYPECODE of 0. I think the cause is line 84 in RTAllocator.m3 which currently reads res := AllocTraced(dataSize, def.dataAlignment, thread^); which doesn't seem to set the header of the clone. Changing it to res := LOOPHOLE(GetTraced(def), ADDRESS); seems to fix the problems, but since I'm not that familiar with the object representation I thought I should ask here first. Thanks, Raja ----- Forwarded message from m3devel-bounces at elegosoft.com ----- Date: Fri, 27 Aug 2010 16:48:17 +0200 From: m3devel-bounces at elegosoft.com Reply-To: m3devel-bounces at elegosoft.com Subject: Auto-discard notification To: m3devel-owner at elegosoft.com The attached message has been automatically discarded. ----- End forwarded message ----- -- 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 rajamukherji at gmail.com Fri Aug 27 17:19:18 2010 From: rajamukherji at gmail.com (Raja Mukherji) Date: Fri, 27 Aug 2010 16:19:18 +0100 Subject: [M3devel] Potential bug in RTAllocator.Clone Message-ID: Hi, this is my first post to the Modula-3 mailing list... While using RTAllocator.Clone in a project, I kept getting errors related to the type of the returned object. The debugger m3gdb returned a TYPECODE of 0. I think the cause is line 84 in RTAllocator.m3 which currently reads res := AllocTraced(dataSize, def.dataAlignment, thread^); which doesn't seem to set the header of the clone. Changing it to res := LOOPHOLE(GetTraced(def), ADDRESS); seems to fix the problems, but since I'm not that familiar with the object representation I thought I should ask here first. Thanks, Raja From rodney_bates at lcwb.coop Fri Aug 27 17:20:51 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 Aug 2010 10:20:51 -0500 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> Message-ID: <4C77D7D3.6070602@lcwb.coop> Jay K wrote: > > better code quality > > Use the native C++ exception handling. Not more calling setjmp all over the place. > Inlining. Currnetly disabled in 4.5.1 because it breaks things. > LTO/LTCG -- which we could get today, on gcc platforms, if we are willing to import even more code. > (link time optimization, link time code gen). e.g. cross module inlining. > see also PGO -- profile guided optimization. > i.e. whatever the full C/C++ toolset is, you can use it. > > > > better debugging > > > Existing debuggers would work and work well. There is no way a debugger that has no Modula-3 awareness is going to provide a Modula-3-like view. The operators will have C spellings and C semantics, and these do differ. The syntax will be strictly C. The display of values will be C. TEXT won't work in any reasonable way at all. Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 type info would be lost, and output formats would lose. Things that use pointers at the machine level can never know whether the pointers point to a single value or an array, and if the latter, with what bounds. Display of whole arrays is pretty much out of the question. Probably the worst thing will be calls. They just don't work without the debugger having knowledge of a lot of stuff. There are extra hidden parameters, method calls, passing procedure-typed parameters with environments, calling the same, the three modes of Modula-3, etc. I consider calls in debugger commands very valuable. This could probably be improved a lot by switching to a better debug info format, probably the latest Dwarf variant. But that is a big job. > Notice today that NT386 has only line numbers. > That there are systems that don't support stabs -- e.g. HP-UX. > That other -g switches to cm3cg crash. > > >>> Basically all platforms would just work. >> I doubt that very much. > > It's only a slight exaggeration. > We'd still need our #ifdef'ing of the C code. Possibly guided by autoconf. > And there are still the threading/gc issues. > But for example, we should work on any processor for any operating system > for which we already work -- NT, Linux, NetBSD, FreeBSD, Solaris, OSF -- on any processors. > And AIX, Irix, VMS would work or be closer to working. > (IA64 might need an #ifdef) > > Anyway, I'll try to work on it. > >> And it would be an order of magnitude slower. > > It would be slower. I'm not sure by how much. > > - Jay > > > ---------------------------------------- >> Date: Thu, 26 Aug 2010 14:10:22 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? >> >> Quoting Jay K : >> >>>> No. I would see a C backend as a variant (option) too, but probably not >>>> use it on platforms were I can compile without it. >>> I would like to see a C backend at least replace the gcc backend. >>> We could maybe then slowly iterate on the integrated backend. Or LLVM. >>> It would provide more obvious correctness, better debugging, better >>> code quality. >> I don't really see that yet. >> >>> Imagine -- basically all platforms would get stack walkers. >>> By generating C++ for most platforms, or using C exception >>> handling in NT/VMS/Tru64. >>> Basically all platforms would just work. >> I doubt that very much. >> >>> Stock debuggers would work, gdb and others. >>> Basically no more porting. >>> Basically all optimizations could be enabled. >>> (Aside: I think the generated C would be sure to store >>> gc roots in volatile locals, but not otherwise use said volatiles.) >> As I said: it has been tried before. >> >>> And in more recent developments, it would enregister some records >>> passed by value. >>> It would, in a sense, shrink the code base (cheating sort of). >> And it would be an order of magnitude slower. >> >>> I'm not holding my breath on any of this. >>> But I'm going to start trying to do more and talk less about it. >> I will let you convince me ;-) >> I've got no problem with trying that. If it's really better, we will >> use it. If not, we may want to use it for special situations (e.g. porting). >> >> 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 Aug 27 17:31:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 17:31:06 +0200 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: References: Message-ID: <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> Quoting Jay K : > We could introduce a new quake feature.. > if defined("set_pipefail") > ? set_pipefail() > end > q_exec() > ? Could you elaborate what exactly fails? I don't think we should rely on bash3 or zsh or something else fancy. I'm also not sure that we can easily implement it in quake. The problem with pipelining logs through tee and losing result values is a standard one, but has no canonical solution AFAIK. More details would help, Olaf > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Fri, 27 Aug 2010 07:01:57 +0000 >> Subject: [M3devel] m3cc often succeeds when it should fail >> >> >> I finally looked into this. >> >> The reason is that the exit code of a pipeline is the last command. >> Seems kind of dumb and I don't like any of the options. >> I like having tee in there to save a log. >> >> There is a way to deal it with bash, zsh, and it takes a big >> function to do it in standard sh. >> >> Maybe q_exec or m3_exec? >> It looks like no. >> >> I suppose we could wrap up everything in a .sh file, detect bash 3 >> or newer, and use set -o pipefail? >> >> - 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 rodney_bates at lcwb.coop Fri Aug 27 17:30:15 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 Aug 2010 10:30:15 -0500 Subject: [M3devel] passing structs by value In-Reply-To: References: Message-ID: <4C77DA07.8030608@lcwb.coop> Jay, I am not sure what you are saying here, but it sounds like you might be considering the passing mode of records to be an implementor choice. Have I read this right? It isn't a choice for Modula-3. The language specifies the mode. Value for VALUE in the signature, reference for VAR, and for READONLY, it depends on the form of the actual. For function returns, the semantics are always by value. Of course, at the machine level, you can always pass a pointer between caller and callee, as long as the necessary copying is done somewhere This is the only reasonable way to implement READONLY, since whether a copy is to be made will differ at different call sites. Jay K wrote: > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > I really can't follow the complicated rules here: > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > As long as Modula-3 callers/recievers agree. And they do, but... > > > The gcc backend is given good type information at first, but historically throws much of it away. > As you start to repair that, it starts following the ABI. At least at the callee side. > I think the caller is still devoid of type information. > I'm assuming there is a fallback rule for the case of missing type information. > > So if you give just one side the type information, you get a mismatch, bad code. > > > Passing records in registers is nice, but.. > (reminder: I think historically we never did). > > > I thin we should probably just change the frontend to handle passing records by value itself. > Like it does for I386_NT/NT386. > > > For any record parameter, introduce a temporary in the caller and pass its address. > Or whatever the code is already prepared to do. > > > We should probably handle records returned by value similarly. > > > This decision can be revisited if/when there is a C backend. > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > I doubt anyone else is either. > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > The right fix is probably to maintain types in the expression stack. > Or at least throw in more casts on the pops. > > > I don't think pop_param presently recieves enough type information -- no type id. > > > - Jay > From hosking at cs.purdue.edu Fri Aug 27 18:11:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Aug 2010 12:11:50 -0400 Subject: [M3devel] Potential bug in RTAllocator.Clone, was: Fwd: Auto-discard notification In-Reply-To: <20100827171723.2a60uadm0wos04gw@mail.elegosoft.com> References: <20100827171723.2a60uadm0wos04gw@mail.elegosoft.com> Message-ID: I just committed a fix for this. On 27 Aug 2010, at 11:17, Olaf Wagner wrote: > Forwarded; sent before subscription was confirmed: > > The attached message has been automatically discarded. > Info The following are the headers for this message/rfc822 message. > Date: Fri, 27 Aug 2010 15:39:23 +0100 > Subject: Potential bug in RTAllocator.Clone > From: Raja Mukherji > To: m3devel at elegosoft.com > 2.1 unnamed [text/plain] 0.58 KB Download > Hi, this is my first post to the Modula-3 mailing list... > > While using RTAllocator.Clone in a project, I kept getting errors > related to the type of the returned object. The debugger m3gdb > returned a TYPECODE of 0. > I think the cause is line 84 in RTAllocator.m3 which currently reads > > res := AllocTraced(dataSize, def.dataAlignment, thread^); > > which doesn't seem to set the header of the clone. Changing it to > > res := LOOPHOLE(GetTraced(def), ADDRESS); > > seems to fix the problems, but since I'm not that familiar with the > object representation I thought I should ask here first. > > Thanks, > Raja > > ----- Forwarded message from m3devel-bounces at elegosoft.com ----- > Date: Fri, 27 Aug 2010 16:48:17 +0200 > From: m3devel-bounces at elegosoft.com > Reply-To: m3devel-bounces at elegosoft.com > Subject: Auto-discard notification > To: m3devel-owner at elegosoft.com > > The attached message has been automatically discarded. > > ----- End forwarded message ----- > > > -- > 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 Fri Aug 27 18:36:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 16:36:19 +0000 Subject: [M3devel] passing structs by value In-Reply-To: <4C77DA07.8030608@lcwb.coop> References: , <4C77DA07.8030608@lcwb.coop> Message-ID: Rodney, don't worry too much, I believe I understand the language semantics and won't deliberately change them. > Of course, at the machine levelI'm talking about the machine level. Passing a record by value can be in registers or a pointer to a copy. The gcc backend wasn't passing enough type information around, such that where the C ABI specified in registers, it'd a be a pointer to a copy. ?? Imho, it's kind of bad of the gcc code to even have accepted the trees we give it. I don't much mind the inefficiency, but I do mind missing type information in the debugger. And what really got me started here is an assertion failure in the SPARC64_SOLARIS backend. It goes to decide how to pass a record by value, which includes looking at what fields the record has, and it had none. Which it is sometimes ok with, but not in this case. If you just change parse.c to pass around the type information it has, well, the easy code only has information at the reciever, not the caller, leading to inconsistency, bad code, crash. The badness only occurs in a little bit of code in the system, and then, only on some platforms. I was lucky to be using such a platform! I have fixed it now so that the passer and recieve both have the information. The result should be, on some platforms, depending on the ABI, depending on the exact RECORD, some records will be passed in registers. Minor side benefit is correct interop with C, though I'd suggest just staying away from passing records by value with C. Unfortunately SPARC64_SOLARIS still hits the same assertion failure in gcc. :( I'm double checking to make sure I used current source. Accidentally doing a clean build of m3cc, so it'll be a while. ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 10:30:15 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] passing structs by value > > Jay, I am not sure what you are saying here, but it sounds like you might be considering the > passing mode of records to be an implementor choice. Have I read this right? > > It isn't a choice for Modula-3. The language specifies the mode. Value for VALUE in the > signature, reference for VAR, and for READONLY, it depends on the form of the actual. > > For function returns, the semantics are always by value. > > Of course, at the machine level, you can always pass a pointer between caller and callee, > as long as the necessary copying is done somewhere This is the only reasonable way to > implement READONLY, since whether a copy is to be made will differ at different call > sites. > > Jay K wrote: > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > I really can't follow the complicated rules here: > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > As you start to repair that, it starts following the ABI. At least at the callee side. > > I think the caller is still devoid of type information. > > I'm assuming there is a fallback rule for the case of missing type information. > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > Passing records in registers is nice, but.. > > (reminder: I think historically we never did). > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > Like it does for I386_NT/NT386. > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > Or whatever the code is already prepared to do. > > > > > > We should probably handle records returned by value similarly. > > > > > > This decision can be revisited if/when there is a C backend. > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > I doubt anyone else is either. > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > The right fix is probably to maintain types in the expression stack. > > Or at least throw in more casts on the pops. > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > - Jay > > From jay.krell at cornell.edu Fri Aug 27 18:51:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 16:51:57 +0000 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> References: , , <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> Message-ID: > Could you elaborate what exactly fails? I use make | tee -a. Any compilation failure..and still success. > I don't think we should rely on bash3 or zsh or something else fancy. Agreed. > I'm also not sure that we can easily implement it in quake. Here is where I disagree...though I'm not certain. You put in a substantial sh emulation already, in sysutils, already exposed in quake. m3-libs/sysutils/src/System.m3 ? PROCEDURE WaitForAll() : INTEGER = ??? VAR p: Process.T; ret: INTEGER := 0; ??? BEGIN ????? WHILE processes.size() > 0 DO ??????? p := NARROW(processes.remlo(), Process.T); ??????? ret := Process.Wait(p); ??????? CloseFiles(cjobid); ??????? INC(cjobid); ????? END; ????? RETURN ret; ??? END WaitForAll; A small change there would do what I want I think. ? PROCEDURE WaitForAll() : INTEGER = ??? VAR p: Process.T; ret := 0; overall := 0; ??? BEGIN ????? WHILE processes.size() > 0 DO ??????? p := NARROW(processes.remlo(), Process.T); ??????? ret := Process.Wait(p); ??????? IF ret <> 0 AND overall = 0 THEN ?????????? overall := ret; ??????? END; ??????? CloseFiles(cjobid); ??????? INC(cjobid); ????? END; ????? RETURN overall; ??? END WaitForAll; It could be made optional, though the way I showed would be global for that cm3 invocation, once set. It'd probably be safe to make it not optional. ? > The problem with pipelining logs through tee and losing result > values is a standard one, but has no canonical solution AFAIK. Agreed, based on my web searching last night. ?- Jay From jay.krell at cornell.edu Fri Aug 27 18:54:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 16:54:50 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: , , <4C77DA07.8030608@lcwb.coop>, Message-ID: > bad code, crash. Clarification, not a crash but an "orderly" error. This is somewhat by chance though. You could imagine perhaps a record that just contains a pointer, and a crash. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Fri, 27 Aug 2010 16:36:19 +0000 > Subject: Re: [M3devel] passing structs by value > > > Rodney, don't worry too much, I believe I understand the language semantics and won't deliberately change them. > > > Of course, at the machine levelI'm talking about the machine level. > > Passing a record by value can be in registers or a pointer to a copy. > The gcc backend wasn't passing enough type information around, such that > where the C ABI specified in registers, it'd a be a pointer to a copy. > Imho, it's kind of bad of the gcc code to even have accepted the trees we give it. > I don't much mind the inefficiency, but I do mind missing type information in the debugger. > > And what really got me started here is an assertion failure in the SPARC64_SOLARIS backend. > It goes to decide how to pass a record by value, which includes looking at what fields the record > has, and it had none. Which it is sometimes ok with, but not in this case. > > If you just change parse.c to pass around the type information it has, well, the easy > code only has information at the reciever, not the caller, leading to inconsistency, bad code, crash. > The badness only occurs in a little bit of code in the system, and then, only on some platforms. > I was lucky to be using such a platform! > > I have fixed it now so that the passer and recieve both have the information. > > The result should be, on some platforms, depending on the ABI, depending on the exact RECORD, > some records will be passed in registers. > Minor side benefit is correct interop with C, though I'd suggest just staying away from > passing records by value with C. > > Unfortunately SPARC64_SOLARIS still hits the same assertion failure in gcc. :( > I'm double checking to make sure I used current source. Accidentally doing > a clean build of m3cc, so it'll be a while. > > > - Jay > > > ---------------------------------------- > > Date: Fri, 27 Aug 2010 10:30:15 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] passing structs by value > > > > Jay, I am not sure what you are saying here, but it sounds like you might be considering the > > passing mode of records to be an implementor choice. Have I read this right? > > > > It isn't a choice for Modula-3. The language specifies the mode. Value for VALUE in the > > signature, reference for VAR, and for READONLY, it depends on the form of the actual. > > > > For function returns, the semantics are always by value. > > > > Of course, at the machine level, you can always pass a pointer between caller and callee, > > as long as the necessary copying is done somewhere This is the only reasonable way to > > implement READONLY, since whether a copy is to be made will differ at different call > > sites. > > > > Jay K wrote: > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > > > I really can't follow the complicated rules here: > > > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > > As you start to repair that, it starts following the ABI. At least at the callee side. > > > I think the caller is still devoid of type information. > > > I'm assuming there is a fallback rule for the case of missing type information. > > > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > > > > Passing records in registers is nice, but.. > > > (reminder: I think historically we never did). > > > > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > > Like it does for I386_NT/NT386. > > > > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > > Or whatever the code is already prepared to do. > > > > > > > > > We should probably handle records returned by value similarly. > > > > > > > > > This decision can be revisited if/when there is a C backend. > > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > > I doubt anyone else is either. > > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > > > > The right fix is probably to maintain types in the expression stack. > > > Or at least throw in more casts on the pops. > > > > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > > > > - Jay > > > > From wagner at elegosoft.com Fri Aug 27 19:23:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 19:23:31 +0200 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: References: , , <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> Message-ID: <20100827192331.fwoon2w4sgwgks8w@mail.elegosoft.com> Quoting Jay K : >> Could you elaborate what exactly fails? > > I use make | tee -a. > Any compilation failure..and still success. You loose stderr there. One standard solution would be to write stderr to a file and check that for content afterwards: make 2>make.err | tee -a log if[ -s make.err ]; then # error >> I'm also not sure that we can easily implement it in quake. > > Here is where I disagree...though I'm not certain. > You put in a substantial sh emulation already, in sysutils, already > exposed in quake. > > m3-libs/sysutils/src/System.m3 > > ? PROCEDURE WaitForAll() : INTEGER = > ??? VAR p: Process.T; ret: INTEGER := 0; > ??? BEGIN > ????? WHILE processes.size() > 0 DO > ??????? p := NARROW(processes.remlo(), Process.T); > ??????? ret := Process.Wait(p); > ??????? CloseFiles(cjobid); > ??????? INC(cjobid); > ????? END; > ????? RETURN ret; > ??? END WaitForAll; > > A small change there would do what I want I think. > > ? PROCEDURE WaitForAll() : INTEGER = > > ??? VAR p: Process.T; ret := 0; overall := 0; > ??? BEGIN > ????? WHILE processes.size() > 0 DO > ??????? p := NARROW(processes.remlo(), Process.T); > ??????? ret := Process.Wait(p); > ??????? IF ret <> 0 AND overall = 0 THEN > ?????????? overall := ret; > ??????? END; > ??????? CloseFiles(cjobid); > ??????? INC(cjobid); > ????? END; > ????? RETURN overall; > ??? END WaitForAll; > > It could be made optional, though the way I showed would be global for > that cm3 invocation, once set. > > It'd probably be safe to make it not optional. ? If this is what is used in your situation I'm in favour of making it the default to heed all return codes. I only said that I'm not sure it can be done easily, as there are different ways how processes are created in quake, often via system shells (might even be a cmd.exe) or anything specified in QUAKE_SHELL. As long as we're using one of the new functions I wrote some years ago it should be no problem. If it's working for you, just change it and document it in the quake manual (cm3/doc/help/cm3/quake.html). 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 hendrik at topoi.pooq.com Fri Aug 27 19:35:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 13:35:02 -0400 Subject: [M3devel] conversion to another version control system Message-ID: <20100827173502.GA8777@topoi.pooq.com> I was tinkering with a copy of the Modula 3 cvs repository I had made a few months ago using cvsup, seeing of cvs2git would make me a proper git-fast-import file. It complained that what I provided wasn't a valid CVS repository: ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS repository, nor a path within a CVS repository. A CVS repository contains a CVSROOT directory within its root directory. Now I looked around, and couldn't find a CVSROOT directory anywhere except in /usr/lib/cvs, which is probably irrelevant. Is this a problem with cvs2git, a problem with the repository, or a problem with cvsup, or a problem with the way I used cvsup to copy the repository? Or would any regular cvs user know just exactly what to do? By the way, the recent problems mentioned on this list about cvsup have made me afraid to use it again. Are those problems restricted to a few platforms, or widespread? -- hendrik From hendrik at topoi.pooq.com Fri Aug 27 20:09:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 14:09:02 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827173502.GA8777@topoi.pooq.com> References: <20100827173502.GA8777@topoi.pooq.com> Message-ID: <20100827180902.GA8903@topoi.pooq.com> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: > I was tinkering with a copy of the Modula 3 cvs repository I had made > a few months ago using cvsup, seeing of cvs2git would make me a proper > git-fast-import file. It complained that what I provided wasn't a valid > CVS repository: > > ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS > repository, nor a path within a CVS repository. A CVS repository > contains a CVSROOT directory within its root directory. > > Now I looked around, and couldn't find a CVSROOT directory anywhere > except in /usr/lib/cvs, which is probably irrelevant. > > Is this a problem with cvs2git, a problem with the repository, or a > problem with cvsup, or a problem with the way I used cvsup to copy the > repository? Or would any regular cvs user know just exactly what to do? Should I perhaps just create an empty CVSROOT directory somewhere? In case it indicates what I did wrong, an ancient log indicates that when I created the copy of the repository in the first place, I used the commands cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 -- hendrik From hosking at cs.purdue.edu Fri Aug 27 20:02:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Aug 2010 14:02:50 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827180902.GA8903@topoi.pooq.com> References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> Message-ID: cvs checkout gives you a checked out working directory not a repository. You'd need to *copy* the repository hierarchy verbatim. On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >> I was tinkering with a copy of the Modula 3 cvs repository I had made >> a few months ago using cvsup, seeing of cvs2git would make me a proper >> git-fast-import file. It complained that what I provided wasn't a valid >> CVS repository: >> >> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >> repository, nor a path within a CVS repository. A CVS repository >> contains a CVSROOT directory within its root directory. >> >> Now I looked around, and couldn't find a CVSROOT directory anywhere >> except in /usr/lib/cvs, which is probably irrelevant. >> >> Is this a problem with cvs2git, a problem with the repository, or a >> problem with cvsup, or a problem with the way I used cvsup to copy the >> repository? Or would any regular cvs user know just exactly what to do? > > Should I perhaps just create an empty CVSROOT directory somewhere? > > In case it indicates what I did wrong, an ancient log indicates that > when I created the copy of the repository in the first place, I used the > commands > > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 > > -- hendrik From jay.krell at cornell.edu Fri Aug 27 20:28:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 18:28:47 +0000 Subject: [M3devel] importing types not described to backend Message-ID: This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 INTERFACE Color; TYPE T = RECORD a,b,c:REAL; END; END Color. MODULE Main; IMPORT Color; TYPE ColorT = RECORD a,b,c: REAL; END; <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = BEGIN END F1; <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = BEGIN END F2; BEGIN ? F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); ? F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); END Main. On SPARC64_SOLARIS there is an assertion failure in the backend: /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1? -mno-app-regs? -quiet -fno-reorder-blocks -funwind-tables -fPIC?? -m64? -gstabs+ Main.mc -o Main.ms ../Main.m3: In function 'Main__F1': ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 I fixed it so F1 is ok. But still F2 isn't. The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. The problem as I understand is we don't tell the backend about imported types. ?There is nothing in the IR about them, judging from -y and a quick look at parse.c. I intend to fix this if I don't here any objections. I'm hoping it isn't too much work. I believe it will mostly/all be in m3front. My opinion of our gcc backend drops.. Perhaps the time is better used on a C front end. Though in this case, I think the work is shared, the same stuff would be missing there too. Thanks, ?- Jay From jay.krell at cornell.edu Fri Aug 27 20:35:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 18:35:00 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: Message-ID: Very wierd: MODULE Main; IMPORT Color; TYPE ColorT = RECORD a,b,c: REAL; END; <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = BEGIN END F1; BEGIN ? F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); END Main. This fails. If you remove the IMPORT, it worked. The declare_record of ColorT comes and goes with that change. So I guess the error really is in F1. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 27 Aug 2010 18:28:47 +0000 > Subject: [M3devel] importing types not described to backend > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > INTERFACE Color; > TYPE T = RECORD a,b,c:REAL; END; > END Color. > > > MODULE Main; > IMPORT Color; > TYPE ColorT = RECORD a,b,c: REAL; END; > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > BEGIN > END F1; > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > BEGIN > END F2; > > > BEGIN > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > END Main. > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > ../Main.m3: In function 'Main__F1': > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > I fixed it so F1 is ok. > But still F2 isn't. > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > The problem as I understand is we don't tell the backend about imported types. > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > I intend to fix this if I don't here any objections. > I'm hoping it isn't too much work. > I believe it will mostly/all be in m3front. > > > My opinion of our gcc backend drops.. > > > Perhaps the time is better used on a C front end. > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > Thanks, > - Jay > From wagner at elegosoft.com Fri Aug 27 20:55:55 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 20:55:55 +0200 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> Message-ID: <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> Quoting Tony Hosking : > cvs checkout gives you a checked out working directory not a repository. > You'd need to *copy* the repository hierarchy verbatim. The CM3 repository is on birch.elegosoft.com:/usr/cvs It contains CVSROOT and cm3 as CVS modules. CVSROOT contains metainformation about the versions. You'll probably need it for git conversion. You can get the whole repository via cvsup, rsync or scp. The last two require an ssh account on birch. Olaf PS: I did mention that Peter Eiserloh is also working on a git conversion of our history? > On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > >> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >>> I was tinkering with a copy of the Modula 3 cvs repository I had made >>> a few months ago using cvsup, seeing of cvs2git would make me a proper >>> git-fast-import file. It complained that what I provided wasn't a valid >>> CVS repository: >>> >>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >>> repository, nor a path within a CVS repository. A CVS repository >>> contains a CVSROOT directory within its root directory. >>> >>> Now I looked around, and couldn't find a CVSROOT directory anywhere >>> except in /usr/lib/cvs, which is probably irrelevant. >>> >>> Is this a problem with cvs2git, a problem with the repository, or a >>> problem with cvsup, or a problem with the way I used cvsup to copy the >>> repository? Or would any regular cvs user know just exactly what to do? >> >> Should I perhaps just create an empty CVSROOT directory somewhere? >> >> In case it indicates what I did wrong, an ancient log indicates that >> when I created the copy of the repository in the first place, I used the >> commands >> >> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login >> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 >> >> -- hendrik > > -- 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 hendrik at topoi.pooq.com Fri Aug 27 21:31:56 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 15:31:56 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> Message-ID: <20100827193155.GB8903@topoi.pooq.com> On Fri, Aug 27, 2010 at 02:02:50PM -0400, Tony Hosking wrote: > cvs checkout gives you a checked out working directory not a repository. > You'd need to *copy* the repository hierarchy verbatim. > > On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > > > On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: > >> I was tinkering with a copy of the Modula 3 cvs repository I had made > >> a few months ago using cvsup, seeing of cvs2git would make me a proper > >> git-fast-import file. It complained that what I provided wasn't a valid > >> CVS repository: > >> > >> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS > >> repository, nor a path within a CVS repository. A CVS repository > >> contains a CVSROOT directory within its root directory. > >> > >> Now I looked around, and couldn't find a CVSROOT directory anywhere > >> except in /usr/lib/cvs, which is probably irrelevant. > >> > >> Is this a problem with cvs2git, a problem with the repository, or a > >> problem with cvsup, or a problem with the way I used cvsup to copy the > >> repository? Or would any regular cvs user know just exactly what to do? > > > > Should I perhaps just create an empty CVSROOT directory somewhere? > > > > In case it indicates what I did wrong, an ancient log indicates that > > when I created the copy of the repository in the first place, I used the > > commands > > > > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 OK. it looks as if this wasn't the command I used. I do remember using cvsup at some point. I do have a lot of ,v files. so it's not a checkout I'm looking at. I seem to have looked at the wrong set of logs. That's was from the set that records how I compiled cvsup. I found the cvsupfile.cm3 file I used. It looks as if I didn't fully uncomment stuff. Will rerun. I hope it won't overload the server. -- hendrik From wagner at elegosoft.com Fri Aug 27 21:29:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 21:29:06 +0200 Subject: [M3devel] cm3cg running amok Message-ID: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> I was just able to kill this process before my system ran out of swap space: % ps -wwwlp 95345 UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? 0:22.91 /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ RTHeapDebug.mc -o RTHeapDebug.ms It had already acquired more than 16 GB. Any ideas? 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 hendrik at topoi.pooq.com Fri Aug 27 21:38:37 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 15:38:37 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> Message-ID: <20100827193836.GC8903@topoi.pooq.com> On Fri, Aug 27, 2010 at 08:55:55PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > >> cvs checkout gives you a checked out working directory not a repository. >> You'd need to *copy* the repository hierarchy verbatim. > > The CM3 repository is on birch.elegosoft.com:/usr/cvs > It contains CVSROOT and cm3 as CVS modules. > CVSROOT contains metainformation about the versions. You'll > probably need it for git conversion. > > You can get the whole repository via cvsup, rsync or scp. The last > two require an ssh account on birch. > > Olaf > > PS: I did mention that Peter Eiserloh is also working on a git > conversion of our history? No. From discussions half a year ago or longer, I thought that monotone was the preferred solution. Git is easier, I suppose, because no one has to write anything to feed git-fast-import into monotone. And a git-fast-import file would probably be the first step to get it into monotone anyway, since the direct cvs import I tried into monotone failed one of monotone's internal sanity checks. Perhaps this means I don't have to do the cvs2mtn stuff any more. Not for Modula 3, anyway. Though git2mtn might still be useful for others. -- hendrik > >> On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: >> >>> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >>>> I was tinkering with a copy of the Modula 3 cvs repository I had made >>>> a few months ago using cvsup, seeing of cvs2git would make me a proper >>>> git-fast-import file. It complained that what I provided wasn't a valid >>>> CVS repository: >>>> >>>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >>>> repository, nor a path within a CVS repository. A CVS repository >>>> contains a CVSROOT directory within its root directory. >>>> >>>> Now I looked around, and couldn't find a CVSROOT directory anywhere >>>> except in /usr/lib/cvs, which is probably irrelevant. >>>> >>>> Is this a problem with cvs2git, a problem with the repository, or a >>>> problem with cvsup, or a problem with the way I used cvsup to copy the >>>> repository? Or would any regular cvs user know just exactly what to do? >>> >>> Should I perhaps just create an empty CVSROOT directory somewhere? >>> >>> In case it indicates what I did wrong, an ancient log indicates that >>> when I created the copy of the repository in the first place, I used the >>> commands >>> >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 >>> >>> -- hendrik >> >> > > > > -- > 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 Sat Aug 28 00:05:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 22:05:38 +0000 Subject: [M3devel] cm3cg running amok In-Reply-To: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> Message-ID: Hm. I've only been testing AMD64_DARWIN lately. ? > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg This path -- to m3-sys/m3cc: When I made the pop_struct change, I changed my cm3cfg.common to only use $PATH, and not root around in the CVS tree. To use old cm3cg with old cm3, new cm3cg with new cm3. Could that be the problem here? ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 21:29:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] cm3cg running amok > > I was just able to kill this process before my system ran out of swap > space: > > % ps -wwwlp 95345 > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? > 0:22.91 > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ RTHeapDebug.mc -o > RTHeapDebug.ms > > It had already acquired more than 16 GB. > > Any ideas? > > 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 Sat Aug 28 00:15:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 22:15:42 +0000 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827193836.GC8903@topoi.pooq.com> References: <20100827173502.GA8777@topoi.pooq.com>, <20100827180902.GA8903@topoi.pooq.com>, , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, <20100827193836.GC8903@topoi.pooq.com> Message-ID: > I thought that monotone was the preferred solutionMy "ressearch" (not really worth calling it that), suggests the following are good options, roughly in this order: ?perforce ("p4") ?mercurial ("hg") ?git ?monotone ("mtn")? ?subversion ("svn") ?subversion doesn't do branching right, but for us it probably is good enough. ?Perforce is my favorite by far. I know very well how to use it and it works very well. ?I just could never find a hoster for it. ?svn's familiar centralized model might put it up at #2 after p4. ?hg is said to be easier to use and understand than git. ?hg and git seems to be the running favorites of the distributed systems. ?mtn was rejected by Linus because it was too slow. It is better now and ?? probably ok. svn doesn't do branching right and isn't distibuted, but as I said, maybe #2. It also pays to use the heavily used systems. They become the most reliable. (Modula-3 not necessarily a counterexcample...) ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 15:38:37 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] conversion to another version control system > > On Fri, Aug 27, 2010 at 08:55:55PM +0200, Olaf Wagner wrote: > > Quoting Tony Hosking : > > > >> cvs checkout gives you a checked out working directory not a repository. > >> You'd need to *copy* the repository hierarchy verbatim. > > > > The CM3 repository is on birch.elegosoft.com:/usr/cvs > > It contains CVSROOT and cm3 as CVS modules. > > CVSROOT contains metainformation about the versions. You'll > > probably need it for git conversion. > > > > You can get the whole repository via cvsup, rsync or scp. The last > > two require an ssh account on birch. > > > > Olaf > > > > PS: I did mention that Peter Eiserloh is also working on a git > > conversion of our history? > > No. From discussions half a year ago or longer, I thought that monotone > was the preferred solution. Git is easier, I suppose, because no one > has to write anything to feed git-fast-import into monotone. And > a git-fast-import file would probably be the first step to get it into > monotone anyway, since the direct cvs import I tried into monotone > failed one of monotone's internal sanity checks. > > Perhaps this means I don't have to do the cvs2mtn stuff any more. Not > for Modula 3, anyway. Though git2mtn might still be useful for others. > > -- hendrik > > > > >> On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > >> > >>> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: > >>>> I was tinkering with a copy of the Modula 3 cvs repository I had made > >>>> a few months ago using cvsup, seeing of cvs2git would make me a proper > >>>> git-fast-import file. It complained that what I provided wasn't a valid > >>>> CVS repository: > >>>> > >>>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS > >>>> repository, nor a path within a CVS repository. A CVS repository > >>>> contains a CVSROOT directory within its root directory. > >>>> > >>>> Now I looked around, and couldn't find a CVSROOT directory anywhere > >>>> except in /usr/lib/cvs, which is probably irrelevant. > >>>> > >>>> Is this a problem with cvs2git, a problem with the repository, or a > >>>> problem with cvsup, or a problem with the way I used cvsup to copy the > >>>> repository? Or would any regular cvs user know just exactly what to do? > >>> > >>> Should I perhaps just create an empty CVSROOT directory somewhere? > >>> > >>> In case it indicates what I did wrong, an ancient log indicates that > >>> when I created the copy of the repository in the first place, I used the > >>> commands > >>> > >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 > >>> > >>> -- hendrik > >> > >> > > > > > > > > -- > > 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 Sat Aug 28 00:31:51 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 28 Aug 2010 00:31:51 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: References: <20100827081459.s88b14400448owk8@mail.elegosoft.com>, , <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com>, <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> Message-ID: <20100828003151.nqk0l9d7w0owcswg@mail.elegosoft.com> I compiled the latest code on my FreeBSD 8 system and found that it sometimes hangs when shutting down the connection. Here is a backtrace: (m3gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x00000008033087dc in poll () from /lib/libc.so.7 (m3gdb) bt #0 0x00000008033087dc in poll () from /lib/libc.so.7 #1 0x000000080315a85e in poll () from /lib/libthr.so.3 #2 0x0000000801d7e0bd in ThreadInternal__Poll (fd=8, read=1, m3timeout=1) at ../src/thread/Common/ThreadInternal.c:31 #3 0x0000000801d8161a in XIOWait (Cannot resolve type with uid DMxDjQ ) at ../src/thread/PTHREAD/ThreadPThread.m3:627 #4 0x0000000801d814c2 in IOAlertWait (fd=8, read=TRUE, timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:603 #5 0x00000008012f1528 in ReadPipe (fd=8) at ../src/SigHandler.m3:221 #6 0x00000008012f0d80 in DoDispatch () at ../src/SigHandler.m3:138 #7 0x00000008012f0b58 in DispatcherRun (closure=16_00000008005cc378) at ../src/SigHandler.m3:112 #8 0x0000000801d806a5 in RunThread (Cannot resolve type with uid DMxDjQ ) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #9 0x0000000801d80359 in ThreadBase (param=16_0000000803c76f80) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #10 0x0000000803158511 in pthread_getprio () from /lib/libthr.so.3 #11 0x0000000000000000 in ?? () There seem to be no other threads at this point. Olaf Quoting Jay K : > > Michael, thank you. Please add it to the bug. > > ?- Jay > > > ---------------------------------------- >> Date: Fri, 27 Aug 2010 13:25:57 +0200 >> From: michael.anderson at elego.de >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on >> several platforms >> >> Quoting Olaf Wagner : >> >> > Quoting Jay K : >> > >> >> Can you add more information to the bug as to how to reproduce >> the problem? >> >> Exact files? cvsup.conf or whatnot? >> >> Exact command lines? >> >> >> >> >> I'm able to reliably reproduce the problem with this command: >> >> /usr/local/cm3/bin/cvsup -g -L 2 cvsupfile.cm3 >> >> where the cvsupfile contains: >> >> *default host=birch.elego.de >> *default base=/home/mand/tmp/cvsup >> *default prefix=/home/mand/tmp/cvs >> *default release=cvs >> *default delete use-rel-suffix >> *default preserve >> cm3 >> >> Sometimes the first sync will finish, but a subsequent sync will hang. >> >> >> I don't use cvsup, don't know how to set it up. >> >> Before when I debugging this it wasn't too difficult though. >> >> >> >> Perhaps we can put something in m3-sys/m3tests even? >> > >> > I will try to set up an automated cvsup test at the weekend. >> > In our DCVS distribution we had quite a few replication tests; >> > perhaps I can burrow something from that. >> > >> > It won't go into m3tests though, but rather be a subdir to cvsup. >> > m3-sys/m3tests is for language/compiler tests. >> > >> > 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 >> >> >> >> -- >> Michael Anderson >> IT Services & Support >> >> elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 >> Building 12.3 (BIG) room 227 >> 13355 Berlin, Germany >> >> phone +49 30 23 45 86 96 michael.anderson at elegosoft.com >> fax +49 30 23 45 86 95 http://www.elegosoft.com >> >> Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin >> Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 >> >> > -- 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 Sat Aug 28 00:38:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 28 Aug 2010 00:38:39 +0200 Subject: [M3devel] cm3cg running amok In-Reply-To: References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> Message-ID: <20100828003839.izqrqjd14w44owk4@mail.elegosoft.com> Quoting Jay K : > Hm. I've only been testing AMD64_DARWIN lately. > ? > > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg > > This path -- to m3-sys/m3cc: > When I made the pop_struct change, I changed my cm3cfg.common to > only use $PATH, and not root around > in the CVS tree. To use old cm3cg with old cm3, new cm3cg with new cm3. > Could that be the problem here? I don't know. It was part of the Hudson regression, so the upgrade should have been done properly. Let's just see if it happens again. I need to get some sleep now, 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 rodney_bates at lcwb.coop Sat Aug 28 03:43:36 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 Aug 2010 20:43:36 -0500 Subject: [M3devel] cm3cg running amok In-Reply-To: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> Message-ID: <4C7869C8.7050600@lcwb.coop> The ticked #1147 I reported a couple of weeks ago would probably show this symptom. That was AMD64_LINUX. Hmm, I think I never got back to supplying the attachment .ms file to reproduce. I'll try to do that tomorrow. I need sleep now too. Olaf Wagner wrote: > I was just able to kill this process before my system ran out of swap > space: > > % ps -wwwlp 95345 > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? 0:22.91 > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg > -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 > -gstabs+ RTHeapDebug.mc -o RTHeapDebug.ms > > It had already acquired more than 16 GB. > > Any ideas? > > Olaf From darko at darko.org Sat Aug 28 08:31:13 2010 From: darko at darko.org (Darko) Date: Fri, 27 Aug 2010 23:31:13 -0700 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, <20100827180902.GA8903@topoi.pooq.com>, , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, <20100827193836.GC8903@topoi.pooq.com> Message-ID: <45AF1046-B964-4509-878D-406269EEA3EC@darko.org> FWIW, I like and use mercurial which has good support generally. Perforce is commercial and proprietary. On 27/08/2010, at 3:15 PM, Jay K wrote: > >> I thought that monotone was the preferred solutionMy "ressearch" (not really worth calling it that), suggests the following are good > options, roughly in this order: > > perforce ("p4") > mercurial ("hg") > git > monotone ("mtn") > subversion ("svn") > > subversion doesn't do branching right, but for us it probably is good enough. > Perforce is my favorite by far. I know very well how to use it and it works very well. > I just could never find a hoster for it. > > svn's familiar centralized model might put it up at #2 after p4. > hg is said to be easier to use and understand than git. > hg and git seems to be the running favorites of the distributed systems. > mtn was rejected by Linus because it was too slow. It is better now and > probably ok. > svn doesn't do branching right and isn't distibuted, but as I said, maybe #2. > > > It also pays to use the heavily used systems. They become the most > reliable. (Modula-3 not necessarily a counterexcample...) > > > - Jay > > ---------------------------------------- >> Date: Fri, 27 Aug 2010 15:38:37 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] conversion to another version control system >> >> On Fri, Aug 27, 2010 at 08:55:55PM +0200, Olaf Wagner wrote: >>> Quoting Tony Hosking : >>> >>>> cvs checkout gives you a checked out working directory not a repository. >>>> You'd need to *copy* the repository hierarchy verbatim. >>> >>> The CM3 repository is on birch.elegosoft.com:/usr/cvs >>> It contains CVSROOT and cm3 as CVS modules. >>> CVSROOT contains metainformation about the versions. You'll >>> probably need it for git conversion. >>> >>> You can get the whole repository via cvsup, rsync or scp. The last >>> two require an ssh account on birch. >>> >>> Olaf >>> >>> PS: I did mention that Peter Eiserloh is also working on a git >>> conversion of our history? >> >> No. From discussions half a year ago or longer, I thought that monotone >> was the preferred solution. Git is easier, I suppose, because no one >> has to write anything to feed git-fast-import into monotone. And >> a git-fast-import file would probably be the first step to get it into >> monotone anyway, since the direct cvs import I tried into monotone >> failed one of monotone's internal sanity checks. >> >> Perhaps this means I don't have to do the cvs2mtn stuff any more. Not >> for Modula 3, anyway. Though git2mtn might still be useful for others. >> >> -- hendrik >> >>> >>>> On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: >>>> >>>>> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >>>>>> I was tinkering with a copy of the Modula 3 cvs repository I had made >>>>>> a few months ago using cvsup, seeing of cvs2git would make me a proper >>>>>> git-fast-import file. It complained that what I provided wasn't a valid >>>>>> CVS repository: >>>>>> >>>>>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >>>>>> repository, nor a path within a CVS repository. A CVS repository >>>>>> contains a CVSROOT directory within its root directory. >>>>>> >>>>>> Now I looked around, and couldn't find a CVSROOT directory anywhere >>>>>> except in /usr/lib/cvs, which is probably irrelevant. >>>>>> >>>>>> Is this a problem with cvs2git, a problem with the repository, or a >>>>>> problem with cvsup, or a problem with the way I used cvsup to copy the >>>>>> repository? Or would any regular cvs user know just exactly what to do? >>>>> >>>>> Should I perhaps just create an empty CVSROOT directory somewhere? >>>>> >>>>> In case it indicates what I did wrong, an ancient log indicates that >>>>> when I created the copy of the repository in the first place, I used the >>>>> commands >>>>> >>>>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login >>>>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 >>>>> >>>>> -- hendrik >>>> >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > From dragisha at m3w.org Sat Aug 28 10:12:52 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Aug 2010 10:12:52 +0200 Subject: [M3devel] conversion to another version control system In-Reply-To: <45AF1046-B964-4509-878D-406269EEA3EC@darko.org> References: <20100827173502.GA8777@topoi.pooq.com> , <20100827180902.GA8903@topoi.pooq.com> , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> , <20100827193836.GC8903@topoi.pooq.com> <45AF1046-B964-4509-878D-406269EEA3EC@darko.org> Message-ID: <1282983172.2770.71.camel@boromir.m3w.org> I use mercurial from time to time and from what I found it's excellent little package. Does its work well, is distributed, supported by trac... What else we need? :) On Fri, 2010-08-27 at 23:31 -0700, Darko wrote: > FWIW, I like and use mercurial which has good support generally. > Perforce is commercial and proprietary. -- Dragi?a Duri? From jay.krell at cornell.edu Sat Aug 28 10:40:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Aug 2010 08:40:29 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <4C77D7D3.6070602@lcwb.coop> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , <4C77D7D3.6070602@lcwb.coop> Message-ID: > > There is no way a debugger that has no Modula-3 awareness is going to provide > a Modula-3-like view. The operators will have C spellings and C semantics, How many operators do people use in a debugger? I use very few. Partly because for a long time I used a debugger with a great gui and an awful expression evaluator. Still, I use basically only "+" "->" "*" (dereference) and "=" for assignment. ?Sometimes multiplication and subtraction. I agree it would be nice if all the C debuggers would be lenient about "->" vs. ".". ? That would unify Modula-3, Java, C#, C, C++. ?? Except where C++ has an operator-> overload. But operator overload ?? is an area where.. tangent... C++ is a great language..my compiler implements ?? it well..but my debugger, my editor, plain text search.. can't cope with it. ?? Modula-3, C#, Java run afoul of plain text search too -- anything with prevalent "scoped names". ?? In C you get Window_Init, File_Open, etc. never just Init or Open. ?? How do you search for calls to operator+ in C++? For a certain type? ?? In C, except for the builtin types, they'd be unique function names. ? Anyway, tangent over. + is the same in the various languages. I think "=", ":=", "==" are the main problem. You might try a compare and accidentally to an assignment. > The syntax will be strictly C. Almost the same. ?> The display of values will be C. Almost the same. Also if you have a particularly good C compiler/debugger, we could do ? #define AND &&? ? #define OR ||? getting you back those two operators, which I rarely use in a debugger. ?> TEXT won't work in any reasonable way at all. Sure it might. In Visual Studio you can write little addins to help the debugger display stuff. I believe there is a small builtin "language" or I believe you can write actual code. In Windbg you can write little plugins. You could provide like !m3.text. I don't know if you can tell the debugger ahead of time how to custom display types. I don't know if gdb has a story here. Still, one might imagine a *small* patch to gdb. ?> Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 ?> type info would be lost, and output formats would lose. Um, you think maybe this stuff was done the wrong way in the first place? ?That the names shouldn't be mangled in the first place? ? I strongly suspect so. Other systems don't depend on this. ?? (Yes, I know about C++ name mangling, and even though it does something similar, ?? that's a trick for the linker and now how debug information works. It for ?? in the absence of debug information, among other reasons.) There is "naturally" type information you get just by building up decent gcc trees. Ditto for intermediate C code. For a while you know, every record is a void* or just has a size, and all the type information is buried in the names. This is questionable. I'm sure it has some advantages. You can describe things maybe not easily described in C. ? e.g. Subranges? And then our code in m3gdb is probably very portable, in that, I think, we just ferry along some strings, from our code to our code, and we can decipher them the same in all systems. I think, I'm not sure, there is like no dependence on the vagaries of coff, dwarf, etc., and what they can or cannot represent. However there is a dependency on stabs being available. It is not for example available on HP-UX. Furthermore the lack of correct type information, apart from stabs, causes problems. For some targets the backend wants accurate type information to pass records by value. I again/still think we should probably not rely on the backend for this anyway. We should probably make a copy and pass a pointer to it, kind of like m3x86 does. ?> Things that use pointers at the machine level can never know whether the pointers ?> point to a single value or an array, and if the latter, with what bounds. C programmers can cope with that. Can't we? And..I admit.. I don't know what our machine level mapping looks like. Do we pass a pointer and a size as two parameters? Or a small record with pointer/size by value? The debugger need not be a full blown Modula-3 interpreter. > Probably the worst thing will be calls. They just don't work without the debugger > having knowledge of a lot of stuff. There are extra hidden parameters, method > calls, passing procedure-typed parameters with environments, calling the same, > the three modes of Modula-3, etc. I consider calls in debugger commands very > valuable. I use calls very rarely. I'm not super keen on running some of my code when otherwise my code is all frozen and some of it is misbehaving. I know this is partly me. Even so, generally you only call certain functions that put there for use from a debugger, right? Like gcc's debug_node or such? And they tend to not be fancy? And the extra parameters..debugger would complain about missing them, programmer would figure it out? I'm not saying there aren't drawbacks here. But there are also major advantages. There are major costs and drawbacks to our current approach. ? We have a ton of extra code. ? Which I don't think we are well equipped for. ? Maybe Tony is. Maybe someone else is. I'm not. ? Partly, I'll admit, anything I write, I am much more able to maintain. Or, another lazy angle, anything smaller is easier to maintain. In gcc we have a large code base. It takes me a long time to get just slightly up to speed on it. We have several nagging problems with it. Maybe I just need to look at the C front end more. Or read tree.h. I don't know. ?4.5.1 doesn't work with SPARC32_SOLARIS/SOLgnu/SOLsun. ?4.3.5 maybe not either. ?A few optimizations I have turned off for 4.5.1 because they cause problems. Including inlining. ?Maybe I just need to debug more. ?Apple and OpenBSD each maintain their own forks. So that, *sort of but not really*, triples things. ?? (now, they are all highly related, so it doesn't) So far we don't have the OpenBSD fork. ? But for example 4.5.1 doesn't have the OpenBSD/powerpc stuff quite. And there is a small OpenBSD/mips64 ?? problem I worked around. Minor, I guess. We could just drop these platforms, or OpenBSD entirely. ? Not a huge deal. But it is yet more stuff that C as an intermediate platform solves. ? Exception handling stinks on all platforms but SOLsun/SOLgnu. ?? The ALPHA_OSF code no longer works. I tried. ? Generating C/C++ would significantly improve exception handling nearly across the board. ?? It is possible otherwise, but much more difficult. So, again, C as intermediate code isn't perfect or without drawbacks, but it promises: ? greatly increased portability ? more efficient exception handling ? better codegen by letting the optimizer be full on, even acrosss modules with some C compilers (gcc 4.5, Visual C++, at least) ? better debugging with stock debuggers (including Visual C++, windbg) ? a portable distribution format -- no more having to distribute binaries, though they still have advantages ???? easier to get into the various "ports" systems I think as a result ? a much smaller system overall (no GPL, if it matters) Again, there are drawbacks, but it just seems so very tempting. I'm sure I'll plug away at m3cc a while longer, but I think more and more it is questionable. I can try again to read the LLVM stuff. A new backend I think is unavoidably a lot of work, be it C or LLVM. That's my hangup on both of these. It requires knowing a lot about two big things -- M3CG and the underlying generator. parse.c is "only" 6,000 lines but pretty dense in terms of information gone into it. Maybe I'm just feeling dumb. The thing about C though, is it is a very well understood next layer down. Certainly compared to the gcc trees or LLVM. I don't think it is just me, that I'm some C expert. > This could probably be improved a lot by switching to a better debug info format, > probably the latest Dwarf variant. But that is a big job. I don't believe we have to do *anything* sort of to switch debug formats. We just have to provide gcc with decently formed typeful trees. It should do the rest. Currently I guess it is all custom. I tried -g again, thinking maybe things were better now. It still crashes. It seems related to the fact that _m3_fault is in an unknown location. But that seems actually deliberate and reasonable, and I tried fiddling with it anyway. No luck yet. This debug format problem is also solved by using C intermediate code. You just use -g or -gdb or -Zi or whatever, whatever is normal for C, and it'd just work. Anyway.. ?- Jay From jay.krell at cornell.edu Sat Aug 28 10:46:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Aug 2010 08:46:51 +0000 Subject: [M3devel] conversion to another version control system In-Reply-To: <1282983172.2770.71.camel@boromir.m3w.org> References: <20100827173502.GA8777@topoi.pooq.com>,, <20100827180902.GA8903@topoi.pooq.com>,, ,, <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>,, <20100827193836.GC8903@topoi.pooq.com>, , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, <1282983172.2770.71.camel@boromir.m3w.org> Message-ID: Perforce is closed source, but it is free of charge ("free beer") for Open Source work. It is an excellent excellent system and I can provide good support here for it, writing up introductory and advanced material and answering questions. It is easy to use. It is just an excellent system and I've used it *a lot*. FreeBSD and OpenWatcom use it. The FreeBSD Perforce repository: ? http://p4web.freebsd.org/@md=d&cd=//&c=0qt@//?ac=83 The OpenWatcom Perforce repository: http://perforce.openwatcom.org:4000/@md=d&cd=//&c=bxM@//?ac=83 ?- Jay ---------------------------------------- > From: dragisha at m3w.org > To: darko at darko.org > Date: Sat, 28 Aug 2010 10:12:52 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] conversion to another version control system > > I use mercurial from time to time and from what I found it's excellent > little package. Does its work well, is distributed, supported by trac... > What else we need? :) > > On Fri, 2010-08-27 at 23:31 -0700, Darko wrote: > > FWIW, I like and use mercurial which has good support generally. > > Perforce is commercial and proprietary. > -- > Dragi?a Duri? > From darko at darko.org Sat Aug 28 10:56:11 2010 From: darko at darko.org (Darko) Date: Sat, 28 Aug 2010 01:56:11 -0700 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, , <20100827180902.GA8903@topoi.pooq.com>, , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , <20100827193836.GC8903@topoi.pooq.com>, , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, <1282983172.2770.71.camel@boromir.m3w.org> Message-ID: <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org> I sort of meant software support. But isn't this all academic since Elego is a CVS shop and they host the project? On 28/08/2010, at 1:46 AM, Jay K wrote: > > Perforce is closed source, but it is free of charge ("free beer") for Open Source work. > > > It is an excellent excellent system and I can provide good support here for it, > writing up introductory and advanced material and answering questions. > It is easy to use. > It is just an excellent system and I've used it *a lot*. > > > FreeBSD and OpenWatcom use it. > The FreeBSD Perforce repository: http://p4web.freebsd.org/@md=d&cd=//&c=0qt@//?ac=83 > The OpenWatcom Perforce repository: http://perforce.openwatcom.org:4000/@md=d&cd=//&c=bxM@//?ac=83 > > > - Jay > > ---------------------------------------- >> From: dragisha at m3w.org >> To: darko at darko.org >> Date: Sat, 28 Aug 2010 10:12:52 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] conversion to another version control system >> >> I use mercurial from time to time and from what I found it's excellent >> little package. Does its work well, is distributed, supported by trac... >> What else we need? :) >> >> On Fri, 2010-08-27 at 23:31 -0700, Darko wrote: >>> FWIW, I like and use mercurial which has good support generally. >>> Perforce is commercial and proprietary. >> -- >> Dragi?a Duri? >> > From jay.krell at cornell.edu Sat Aug 28 11:54:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Aug 2010 09:54:54 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: , Message-ID: Interesting. TYPE Color1 = RECORD a,b,c: REAL; END; TYPE Color2 = RECORD a,b,c: REAL; END; Have the same id. If the module defining them also imports an interface with a type with the same id, ? or I think, if its interface defines a type with same id (same thing I think, ? no relationship at the cg level between a module and its interface), then the declare_records are skipped. The fix is probably something simple in Type.Compile involve the order it checks the tables in when deciding to call t.compile or not. Or can it just always call t.compile? Worst thing is that extra type information created? A lot of it? (all types in all imports, instead of just the used ones??) ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] importing types not described to backend > Date: Fri, 27 Aug 2010 18:35:00 +0000 > > > Very wierd: > > MODULE Main; > IMPORT Color; > TYPE ColorT = RECORD a,b,c: REAL; END; > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > BEGIN > END F1; > > BEGIN > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > END Main. > > > This fails. If you remove the IMPORT, it worked. > The declare_record of ColorT comes and goes with that change. > So I guess the error really is in F1. > > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Fri, 27 Aug 2010 18:28:47 +0000 > > Subject: [M3devel] importing types not described to backend > > > > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > > > INTERFACE Color; > > TYPE T = RECORD a,b,c:REAL; END; > > END Color. > > > > > > MODULE Main; > > IMPORT Color; > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > BEGIN > > END F1; > > > > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > > BEGIN > > END F2; > > > > > > BEGIN > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > > END Main. > > > > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > > ../Main.m3: In function 'Main__F1': > > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > > > > I fixed it so F1 is ok. > > But still F2 isn't. > > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > > > > The problem as I understand is we don't tell the backend about imported types. > > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > > > > I intend to fix this if I don't here any objections. > > I'm hoping it isn't too much work. > > I believe it will mostly/all be in m3front. > > > > > > My opinion of our gcc backend drops.. > > > > > > Perhaps the time is better used on a C front end. > > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > > > > Thanks, > > - Jay > > > From rodney_bates at lcwb.coop Sat Aug 28 21:15:02 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 28 Aug 2010 14:15:02 -0500 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , <4C77D7D3.6070602@lcwb.coop> Message-ID: <4C796036.1000806@lcwb.coop> Jay K wrote: > >> There is no way a debugger that has no Modula-3 awareness is going to provide >> a Modula-3-like view. The operators will have C spellings and C semantics, > > > How many operators do people use in a debugger? > > I use very few. Partly because for a long time I used a debugger > with a great gui and an awful expression evaluator. > > > Still, I use basically only "+" "->" "*" (dereference) and "=" for assignment. > Sometimes multiplication and subtraction. > I agree it would be nice if all the C debuggers would be lenient about "->" vs. ".". > That would unify Modula-3, Java, C#, C, C++. > Except where C++ has an operator-> overload. But operator overload > is an area where.. tangent... C++ is a great language..my compiler implements > it well..but my debugger, my editor, plain text search.. can't cope with it. > Modula-3, C#, Java run afoul of plain text search too -- anything with prevalent "scoped names". > In C you get Window_Init, File_Open, etc. never just Init or Open. > How do you search for calls to operator+ in C++? For a certain type? > In C, except for the builtin types, they'd be unique function names. > Anyway, tangent over. > > > + is the same in the various languages. > > I think "=", ":=", "==" are the main problem. > You might try a compare and accidentally to an assignment. > > >> The syntax will be strictly C. > > Almost the same. > > > > The display of values will be C. > > Almost the same. On the strength of your comments, I rest my case. > > Also if you have a particularly good C compiler/debugger, we could do > #define AND && > #define OR || > > > getting you back those two operators, which I rarely use in a debugger. > > > > TEXT won't work in any reasonable way at all. > > Sure it might. > In Visual Studio you can write little addins to help the debugger display stuff. > I believe there is a small builtin "language" or I believe you can write actual code. > In Windbg you can write little plugins. You could provide like !m3.text. > I don't know if you can tell the debugger ahead of time how to custom display types. > I don't know if gdb has a story here. > Still, one might imagine a *small* patch to gdb. All of which is just different ways of providing a debugger with proper Modula-3 support. > > > > Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 > > type info would be lost, and output formats would lose. > > > Um, you think maybe this stuff was done the wrong way in the first place? > That the names shouldn't be mangled in the first place? > I strongly suspect so. Other systems don't depend on this. > (Yes, I know about C++ name mangling, and even though it does something similar, > that's a trick for the linker and now how debug information works. It for > in the absence of debug information, among other reasons.) > I think it could be done a lot better if switching to a better debug info format. stabs may have been the best option around at the time it was done. And I don't know if Modula-3's structural type equivalence rules could be supported any better without the uid's. But there will still have to be name mangling to get a standard linker to work, with just about any language. Stock gdb does what it does in part because it has builtin demanglers for the various languages it supports. It chooses the appropriate demangler dynamically. It would be a pretty ugly user interface if it didn't. > There is "naturally" type information you get just by building up decent gcc trees. > Ditto for intermediate C code. > For a while you know, every record is a void* or just has a size, and all the type information > is buried in the names. This is questionable. I'm sure it has some advantages. > You can describe things maybe not easily described in C. > e.g. Subranges? > And then our code in m3gdb is probably very portable, in that, I think, we just ferry along > some strings, from our code to our code, and we can decipher them the same in all systems. > I think, I'm not sure, there is like no dependence on the vagaries of coff, dwarf, etc., and > what they can or cannot represent. However there is a dependency on stabs being available. > It is not for example available on HP-UX. > > > Furthermore the lack of correct type information, apart from stabs, causes problems. > For some targets the backend wants accurate type information to pass records by value. > I again/still think we should probably not rely on the backend for this anyway. > We should probably make a copy and pass a pointer to it, kind of like m3x86 does. > Certainly, a back end needs type information for code generation. That won't do much to help a debugger that is oblivious to the source language. > > > Things that use pointers at the machine level can never know whether the pointers > > point to a single value or an array, and if the latter, with what bounds. > > > C programmers can cope with that. Can't we? Look at the security advisories. Buffer overflow, buffer overrun, buffer overflow, ... over and over. Almost all of them are buffer overruns. But that's a tangent too. > And..I admit.. I don't know what our machine level mapping looks like. > Do we pass a pointer and a size as two parameters? Or a small record with pointer/size by value? > If it's a fixed array, its all in the static type, which the stabs (as extended for Modula-3) info conveys. If it's an open array, there is runtime dope: a pointer to the zero-th array element, followed by a shape, which is just a list of words giving the NUMBER of each dimension. The dimension count is statically known. generally passed by reference, although it is never altered. For heap-allocated arrays, it's located right in the heap object, at the beginning, making the pointer redundant. For Formal parameters, if the actual doesn't already have the needed dope, it is constructed at runtime by code at the call site. This works for, e.g., passing a fixed array or a SUBARRAY to a formal that is open. BTW, this is another thing a debugger has to know about to either pass, display, or alter open array values. Perhaps Dwarf is sophisticated enough that it could just be encoded in Dwarf, but certainly not in stabs. (Well, we could probably cobble up yet another stabs extension, but that would still require specialized debugger support.) > > The debugger need not be a full blown Modula-3 interpreter. > > >> Probably the worst thing will be calls. They just don't work without the debugger >> having knowledge of a lot of stuff. There are extra hidden parameters, method >> calls, passing procedure-typed parameters with environments, calling the same, >> the three modes of Modula-3, etc. I consider calls in debugger commands very >> valuable. > > > I use calls very rarely. > I'm not super keen on running some of my code when otherwise my code is all frozen > and some of it is misbehaving. I know this is partly me. > > > Even so, generally you only call certain functions that put there for use from a debugger, right? > Like gcc's debug_node or such? > And they tend to not be fancy? I regularly type a debugger call to rexecute something that I just stepped over, not knowing whether the problem I am looking for would occur inside the procedure or not. Reverse debugging in the newest gdb could provide an alternative, but I am hearing that the necessary recording costs ~ n*10 slowdown. I also do it as an easy way to test some parameter combination. Kind of like having an interpreter for the language. And I do it with fancy procedures that format some elaborate data structure in a readable, high-level way, which is, I think, what you meant. Sometimes a *lot* of effort. > > And the extra parameters..debugger would complain about missing them, programmer would figure it out? Before I got call support working, I found there were many calls I could not make work at all. Either I couldn't figure out what was needed (This amounts, in part, to manually reading stabs), or there was no way to supply what was needed in a debugger command. Also, on method calls, there was no way to figure out where it would dispatch to, even when you could locate all the possible overrides in all the subtypes, in all the source files of the closure. Language-specific support can take care of this, when done completely. m3gdb is a long way from there now, but it helps a lot. > > > I'm not saying there aren't drawbacks here. > But there are also major advantages. > There are major costs and drawbacks to our current approach. > We have a ton of extra code. > Which I don't think we are well equipped for. > Maybe Tony is. Maybe someone else is. I'm not. > > > Partly, I'll admit, anything I write, I am much more able to maintain. > Or, another lazy angle, anything smaller is easier to maintain. > > > In gcc we have a large code base. It takes me a long time to get just slightly up to speed on it. > We have several nagging problems with it. Maybe I just need to look at the C front end more. > Or read tree.h. I don't know. > > > 4.5.1 doesn't work with SPARC32_SOLARIS/SOLgnu/SOLsun. > 4.3.5 maybe not either. > A few optimizations I have turned off for 4.5.1 because they cause problems. Including inlining. > Maybe I just need to debug more. > Apple and OpenBSD each maintain their own forks. So that, *sort of but not really*, triples things. > (now, they are all highly related, so it doesn't) So far we don't have the OpenBSD fork. > But for example 4.5.1 doesn't have the OpenBSD/powerpc stuff quite. And there is a small OpenBSD/mips64 > problem I worked around. Minor, I guess. We could just drop these platforms, or OpenBSD entirely. > Not a huge deal. But it is yet more stuff that C as an intermediate platform solves. > Exception handling stinks on all platforms but SOLsun/SOLgnu. > The ALPHA_OSF code no longer works. I tried. > Generating C/C++ would significantly improve exception handling nearly across the board. > It is possible otherwise, but much more difficult. > > > So, again, C as intermediate code isn't perfect or without drawbacks, but it promises: > greatly increased portability > more efficient exception handling > better codegen by letting the optimizer be full on, even acrosss modules with some C compilers (gcc 4.5, Visual C++, at least) > better debugging with stock debuggers (including Visual C++, windbg) > a portable distribution format -- no more having to distribute binaries, though they still have advantages > easier to get into the various "ports" systems I think as a result > a much smaller system overall (no GPL, if it matters) > > > Again, there are drawbacks, but it just seems so very tempting. > > > I'm sure I'll plug away at m3cc a while longer, but I think more and more it is questionable. > > > I can try again to read the LLVM stuff. > > > A new backend I think is unavoidably a lot of work, be it C or LLVM. > That's my hangup on both of these. It requires knowing a lot about two big things -- M3CG and the underlying generator. > parse.c is "only" 6,000 lines but pretty dense in terms of information gone into it. Maybe I'm just feeling dumb. > > > The thing about C though, is it is a very well understood next layer down. Certainly compared to > the gcc trees or LLVM. I don't think it is just me, that I'm some C expert. > > > >> This could probably be improved a lot by switching to a better debug info format, >> probably the latest Dwarf variant. But that is a big job. > > > I don't believe we have to do *anything* sort of to switch debug formats. > We just have to provide gcc with decently formed typeful trees. > It should do the rest. > Currently I guess it is all custom. It doesn't provide nearly enough information in stock form. The "stabs" it now produces has a lot of Modula-3-specific stuff crammed inside the fields of stabs entries. This had be be added by the original implementors of the gcc backend. A different debug format will need changes to gcc to emit what is needed. However, it might well be entirely within the "llanguage" of, say Dwarf, which is very general. It certainly would be a lot cleaner, and it could easily be completed in places that are now hard. So there would still be a lot of work. I don't completely understand where the current back end emits all the stabs stuff, but I believe all or almost all of it comes through code in parse.c calling utility code (dbxout.c, e.g.), and is not much taken from the trees gcc uses. This is why I have yet to figure out how to write correct debug info describing the locations of static links, since gcc develops this information by transforming trees, after parse.c has done its thing. > > I tried -g again, thinking maybe things were better now. It still crashes. > It seems related to the fact that _m3_fault is in an unknown location. > But that seems actually deliberate and reasonable, and I tried fiddling with it anyway. > No luck yet. > > > This debug format problem is also solved by using C intermediate code. > You just use -g or -gdb or -Zi or whatever, whatever is normal for C, and it'd just work. > Lots of things, TEXT being probably the worst, won't display in a Modula-3 form this way. And things in expressions/statements won't work either. A debugger user will have to understand a lot of low-level stuff about how the C back end translates Modula-3 code to C, to use it at all, and it will still be far less convenient. > > Anyway.. > - Jay > From mvfranz at gmail.com Sun Aug 29 01:06:45 2010 From: mvfranz at gmail.com (Michael Franz) Date: Sat, 28 Aug 2010 19:06:45 -0400 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system Message-ID: Hi, I have been reading Systems Programming with Modula-3, edited by Greg Nelson. The chapter on Trestle refers to SRC Report 69 - Performance analysis of a multiprocessor window system. I have some link on the web, but they are all broken. The one that did work I cannot display. Does anyone know where I can get the pdf version? Thank you Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Aug 29 01:51:57 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 28 Aug 2010 18:51:57 -0500 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system In-Reply-To: References: Message-ID: <4C79A11D.8010008@lcwb.coop> Inside the cm3 CVS release branch (cm3-58--release) (and no doubt the head too), is file doc/src_reports/src-069.pdf. When I open it, its title page has report number 69 and title "Trestle Tutorial", which agrees with its contents. It is hard to image SRC would have ambiguously numbered reports. The report number must be a mistake in the citation. I have a printed copy of SRC 135a, with a listing in the back of the reports through 133b, with no mention of that title. Not much help, but it might help structure searches more effectively. I think copies of a lot of the SRC stuff are still online somewhere, but I don't remember where. Perhaps an HP site? Michael Franz wrote: > Hi, > > I have been reading Systems Programming with Modula-3, edited by Greg > Nelson. The chapter on Trestle refers to SRC Report 69 - Performance > analysis of a multiprocessor window system. I have some link on the > web, but they are all broken. The one that did work I cannot display. > Does anyone know where I can get the pdf version? > > Thank you > > Michael From rodney_bates at lcwb.coop Sun Aug 29 02:02:17 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 28 Aug 2010 19:02:17 -0500 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system In-Reply-To: <4C79A11D.8010008@lcwb.coop> References: <4C79A11D.8010008@lcwb.coop> Message-ID: <4C79A389.1070202@lcwb.coop> Rodney M. Bates wrote: > Inside the cm3 CVS release branch (cm3-58--release) (and no doubt the > head too), > is file doc/src_reports/src-069.pdf. When I open it, its title page has > report > number 69 and title "Trestle Tutorial", which agrees with its contents. > It is hard to image SRC would have ambiguously numbered reports. > The report number must be a mistake in the citation. > > I have a printed copy of SRC 135a, with a listing in the back of the > reports > through 133b, with no mention of that title. > > Not much help, but it might help structure searches more effectively. > > I think copies of a lot of the SRC stuff are still online somewhere, but I > don't remember where. Perhaps an HP site? P.S.: http://www.hpl.hp.com/techreports/Compaq-DEC/ has them. But not that title. P.P.S. If you are seriously reading either the Trestle tutorial or reference manual are puzzled the concept of a "share of a mutex", I can help, if I can remember it. It took me years to figure out what it meant. > > Michael Franz wrote: >> Hi, >> >> I have been reading Systems Programming with Modula-3, edited by Greg >> Nelson. The chapter on Trestle refers to SRC Report 69 - Performance >> analysis of a multiprocessor window system. I have some link on the >> web, but they are all broken. The one that did work I cannot display. >> Does anyone know where I can get the pdf version? >> >> Thank you >> >> Michael > From jay.krell at cornell.edu Sun Aug 29 02:21:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 00:21:31 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <4C796036.1000806@lcwb.coop> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, ,,, , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , , , <4C77D7D3.6070602@lcwb.coop>, , <4C796036.1000806@lcwb.coop> Message-ID: Ps we don't even have m3gdb for all systems e.g. Darwin, and the Windows debuggers are much better than anything I've seen on Unix. On these systems intermediate C would improve debugging much. Though Darwin gdb I've also been improving. Also you seem to confuse C name mangling with what Modula-3 does. They are quite different. C only mangles things with linkage, for linking reasons, not for debugging information. Locals, parameters, record fields: no mangling. C code analogous to what Modula-3 allows would survive with everything being extern C, no name mangling. In both cases as I understand, an effective hack to tunnel information through systems not quite designed/extended to suit. What we have is flawed. What I favor is flawed. But differently. - Jay/phone > Date: Sat, 28 Aug 2010 14:15:02 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? > > > > Jay K wrote: > > > >> There is no way a debugger that has no Modula-3 awareness is going to provide > >> a Modula-3-like view. The operators will have C spellings and C semantics, > > > > > > How many operators do people use in a debugger? > > > > I use very few. Partly because for a long time I used a debugger > > with a great gui and an awful expression evaluator. > > > > > > Still, I use basically only "+" "->" "*" (dereference) and "=" for assignment. > > Sometimes multiplication and subtraction. > > I agree it would be nice if all the C debuggers would be lenient about "->" vs. ".". > > That would unify Modula-3, Java, C#, C, C++. > > Except where C++ has an operator-> overload. But operator overload > > is an area where.. tangent... C++ is a great language..my compiler implements > > it well..but my debugger, my editor, plain text search.. can't cope with it. > > Modula-3, C#, Java run afoul of plain text search too -- anything with prevalent "scoped names". > > In C you get Window_Init, File_Open, etc. never just Init or Open. > > How do you search for calls to operator+ in C++? For a certain type? > > In C, except for the builtin types, they'd be unique function names. > > Anyway, tangent over. > > > > > > + is the same in the various languages. > > > > I think "=", ":=", "==" are the main problem. > > You might try a compare and accidentally to an assignment. > > > > > >> The syntax will be strictly C. > > > > Almost the same. > > > > > > > The display of values will be C. > > > > Almost the same. > > On the strength of your comments, I rest my case. > > > > > Also if you have a particularly good C compiler/debugger, we could do > > #define AND && > > #define OR || > > > > > > getting you back those two operators, which I rarely use in a debugger. > > > > > > > TEXT won't work in any reasonable way at all. > > > > Sure it might. > > In Visual Studio you can write little addins to help the debugger display stuff. > > I believe there is a small builtin "language" or I believe you can write actual code. > > In Windbg you can write little plugins. You could provide like !m3.text. > > I don't know if you can tell the debugger ahead of time how to custom display types. > > I don't know if gdb has a story here. > > Still, one might imagine a *small* patch to gdb. > > All of which is just different ways of providing a debugger with proper Modula-3 support. > > > > > > > > Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 > > > type info would be lost, and output formats would lose. > > > > > > Um, you think maybe this stuff was done the wrong way in the first place? > > That the names shouldn't be mangled in the first place? > > I strongly suspect so. Other systems don't depend on this. > > (Yes, I know about C++ name mangling, and even though it does something similar, > > that's a trick for the linker and now how debug information works. It for > > in the absence of debug information, among other reasons.) > > > > I think it could be done a lot better if switching to a better debug info format. > stabs may have been the best option around at the time it was done. And I don't > know if Modula-3's structural type equivalence rules could be supported any better > without the uid's. > > But there will still have to be name mangling to get a standard linker to work, > with just about any language. Stock gdb does what it does in part because it > has builtin demanglers for the various languages it supports. It chooses the > appropriate demangler dynamically. It would be a pretty ugly user interface if > it didn't. > > > There is "naturally" type information you get just by building up decent gcc trees. > > Ditto for intermediate C code. > > For a while you know, every record is a void* or just has a size, and all the type information > > is buried in the names. This is questionable. I'm sure it has some advantages. > > You can describe things maybe not easily described in C. > > e.g. Subranges? > > And then our code in m3gdb is probably very portable, in that, I think, we just ferry along > > some strings, from our code to our code, and we can decipher them the same in all systems. > > I think, I'm not sure, there is like no dependence on the vagaries of coff, dwarf, etc., and > > what they can or cannot represent. However there is a dependency on stabs being available. > > It is not for example available on HP-UX. > > > > > > Furthermore the lack of correct type information, apart from stabs, causes problems. > > For some targets the backend wants accurate type information to pass records by value. > > I again/still think we should probably not rely on the backend for this anyway. > > We should probably make a copy and pass a pointer to it, kind of like m3x86 does. > > > > Certainly, a back end needs type information for code generation. That won't do much to > help a debugger that is oblivious to the source language. > > > > > > Things that use pointers at the machine level can never know whether the pointers > > > point to a single value or an array, and if the latter, with what bounds. > > > > > > C programmers can cope with that. Can't we? > > Look at the security advisories. Buffer overflow, buffer overrun, buffer overflow, ... > over and over. Almost all of them are buffer overruns. But that's a tangent too. > > > And..I admit.. I don't know what our machine level mapping looks like. > > Do we pass a pointer and a size as two parameters? Or a small record with pointer/size by value? > > > > If it's a fixed array, its all in the static type, which the stabs (as extended for Modula-3) > info conveys. If it's an open array, there is runtime dope: a pointer to the zero-th array > element, followed by a shape, which is just a list of words giving the NUMBER of each dimension. > The dimension count is statically known. generally passed by reference, although it is never > altered. For heap-allocated arrays, it's located right in the heap object, at the beginning, > making the pointer redundant. For Formal parameters, if the actual doesn't already have the > needed dope, it is constructed at runtime by code at the call site. This works for, e.g., > passing a fixed array or a SUBARRAY to a formal that is open. > > BTW, this is another thing a debugger has to know about to either pass, display, or alter > open array values. Perhaps Dwarf is sophisticated enough that it could just be encoded in > Dwarf, but certainly not in stabs. (Well, we could probably cobble up yet another stabs > extension, but that would still require specialized debugger support.) > > > > > The debugger need not be a full blown Modula-3 interpreter. > > > > > >> Probably the worst thing will be calls. They just don't work without the debugger > >> having knowledge of a lot of stuff. There are extra hidden parameters, method > >> calls, passing procedure-typed parameters with environments, calling the same, > >> the three modes of Modula-3, etc. I consider calls in debugger commands very > >> valuable. > > > > > > I use calls very rarely. > > I'm not super keen on running some of my code when otherwise my code is all frozen > > and some of it is misbehaving. I know this is partly me. > > > > > > Even so, generally you only call certain functions that put there for use from a debugger, right? > > Like gcc's debug_node or such? > > And they tend to not be fancy? > > I regularly type a debugger call to rexecute something that I just stepped over, not knowing whether > the problem I am looking for would occur inside the procedure or not. Reverse debugging in the newest > gdb could provide an alternative, but I am hearing that the necessary recording costs ~ n*10 slowdown. > > I also do it as an easy way to test some parameter combination. Kind of like having an interpreter for > the language. And I do it with fancy procedures that format some elaborate data structure in a readable, > high-level way, which is, I think, what you meant. Sometimes a *lot* of effort. > > > > > > And the extra parameters..debugger would complain about missing them, programmer would figure it out? > > Before I got call support working, I found there were many calls I could not make work at all. Either > I couldn't figure out what was needed (This amounts, in part, to manually reading stabs), or there > was no way to supply what was needed in a debugger command. Also, on method calls, there was no way > to figure out where it would dispatch to, even when you could locate all the possible overrides in all > the subtypes, in all the source files of the closure. Language-specific support can take care of this, > when done completely. m3gdb is a long way from there now, but it helps a lot. > > > > > > > I'm not saying there aren't drawbacks here. > > But there are also major advantages. > > There are major costs and drawbacks to our current approach. > > We have a ton of extra code. > > Which I don't think we are well equipped for. > > Maybe Tony is. Maybe someone else is. I'm not. > > > > > > Partly, I'll admit, anything I write, I am much more able to maintain. > > Or, another lazy angle, anything smaller is easier to maintain. > > > > > > In gcc we have a large code base. It takes me a long time to get just slightly up to speed on it. > > We have several nagging problems with it. Maybe I just need to look at the C front end more. > > Or read tree.h. I don't know. > > > > > > 4.5.1 doesn't work with SPARC32_SOLARIS/SOLgnu/SOLsun. > > 4.3.5 maybe not either. > > A few optimizations I have turned off for 4.5.1 because they cause problems. Including inlining. > > Maybe I just need to debug more. > > Apple and OpenBSD each maintain their own forks. So that, *sort of but not really*, triples things. > > (now, they are all highly related, so it doesn't) So far we don't have the OpenBSD fork. > > But for example 4.5.1 doesn't have the OpenBSD/powerpc stuff quite. And there is a small OpenBSD/mips64 > > problem I worked around. Minor, I guess. We could just drop these platforms, or OpenBSD entirely. > > Not a huge deal. But it is yet more stuff that C as an intermediate platform solves. > > Exception handling stinks on all platforms but SOLsun/SOLgnu. > > The ALPHA_OSF code no longer works. I tried. > > Generating C/C++ would significantly improve exception handling nearly across the board. > > It is possible otherwise, but much more difficult. > > > > > > So, again, C as intermediate code isn't perfect or without drawbacks, but it promises: > > greatly increased portability > > more efficient exception handling > > better codegen by letting the optimizer be full on, even acrosss modules with some C compilers (gcc 4.5, Visual C++, at least) > > better debugging with stock debuggers (including Visual C++, windbg) > > a portable distribution format -- no more having to distribute binaries, though they still have advantages > > easier to get into the various "ports" systems I think as a result > > a much smaller system overall (no GPL, if it matters) > > > > > > Again, there are drawbacks, but it just seems so very tempting. > > > > > > I'm sure I'll plug away at m3cc a while longer, but I think more and more it is questionable. > > > > > > I can try again to read the LLVM stuff. > > > > > > A new backend I think is unavoidably a lot of work, be it C or LLVM. > > That's my hangup on both of these. It requires knowing a lot about two big things -- M3CG and the underlying generator. > > parse.c is "only" 6,000 lines but pretty dense in terms of information gone into it. Maybe I'm just feeling dumb. > > > > > > The thing about C though, is it is a very well understood next layer down. Certainly compared to > > the gcc trees or LLVM. I don't think it is just me, that I'm some C expert. > > > > > > > >> This could probably be improved a lot by switching to a better debug info format, > >> probably the latest Dwarf variant. But that is a big job. > > > > > > I don't believe we have to do *anything* sort of to switch debug formats. > > We just have to provide gcc with decently formed typeful trees. > > It should do the rest. > > Currently I guess it is all custom. > > It doesn't provide nearly enough information in stock form. The "stabs" it now produces has a lot > of Modula-3-specific stuff crammed inside the fields of stabs entries. This had be be added by the > original implementors of the gcc backend. A different debug format will need changes to gcc to > emit what is needed. However, it might well be entirely within the "llanguage" of, say Dwarf, which > is very general. It certainly would be a lot cleaner, and it could easily be completed in places > that are now hard. So there would still be a lot of work. > > I don't completely understand where the current back end emits all the stabs stuff, but I believe > all or almost all of it comes through code in parse.c calling utility code (dbxout.c, e.g.), and > is not much taken from the trees gcc uses. This is why I have yet to figure out how to write > correct debug info describing the locations of static links, since gcc develops this information > by transforming trees, after parse.c has done its thing. > > > > > I tried -g again, thinking maybe things were better now. It still crashes. > > It seems related to the fact that _m3_fault is in an unknown location. > > But that seems actually deliberate and reasonable, and I tried fiddling with it anyway. > > No luck yet. > > > > > > This debug format problem is also solved by using C intermediate code. > > You just use -g or -gdb or -Zi or whatever, whatever is normal for C, and it'd just work. > > > > Lots of things, TEXT being probably the worst, won't display in a Modula-3 form this way. > And things in expressions/statements won't work either. A debugger user will have to understand > a lot of low-level stuff about how the C back end translates Modula-3 code to C, to use it at all, > and it will still be far less convenient. > > > > > Anyway.. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvfranz at gmail.com Sun Aug 29 05:40:12 2010 From: mvfranz at gmail.com (Michael Franz) Date: Sat, 28 Aug 2010 23:40:12 -0400 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system In-Reply-To: <4C79A389.1070202@lcwb.coop> References: <4C79A11D.8010008@lcwb.coop> <4C79A389.1070202@lcwb.coop> Message-ID: I did manage to find a version of SRC-69, but it is as you pointed out the Trestle Tutorial. I have found reference to Performance analysis of a multiprocessor window system, but not the actual report. Either the citation is wrong or SRC numbers there reports from 1 every year. The report I am looking for is from 1991, but the tutorial is from 1992. When I get to the shared mutex and have issues I will contact you, for now, I am just reading for an overview. Thank you On Sat, Aug 28, 2010 at 8:02 PM, Rodney M. Bates wrote: > > > Rodney M. Bates wrote: > >> Inside the cm3 CVS release branch (cm3-58--release) (and no doubt the head >> too), >> is file doc/src_reports/src-069.pdf. When I open it, its title page has >> report >> number 69 and title "Trestle Tutorial", which agrees with its contents. >> It is hard to image SRC would have ambiguously numbered reports. >> The report number must be a mistake in the citation. >> >> I have a printed copy of SRC 135a, with a listing in the back of the >> reports >> through 133b, with no mention of that title. >> >> Not much help, but it might help structure searches more effectively. >> >> I think copies of a lot of the SRC stuff are still online somewhere, but I >> don't remember where. Perhaps an HP site? >> > > P.S.: http://www.hpl.hp.com/techreports/Compaq-DEC/ has them. But not > that title. > > P.P.S. If you are seriously reading either the Trestle tutorial or > reference manual are puzzled the concept of a "share of a mutex", > I can help, if I can remember it. It took me years to figure out > what it meant. > > > >> Michael Franz wrote: >> >>> Hi, >>> >>> I have been reading Systems Programming with Modula-3, edited by Greg >>> Nelson. The chapter on Trestle refers to SRC Report 69 - Performance >>> analysis of a multiprocessor window system. I have some link on the web, >>> but they are all broken. The one that did work I cannot display. Does >>> anyone know where I can get the pdf version? >>> >>> Thank you >>> >>> Michael >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 29 09:35:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 07:35:24 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: , , Message-ID: I've been quite banging my head against this. I believe basically every type referenced in a module must be "described" to the backend, such as with declare_opaque, declare_record, etc. Type.Compile should call t.compile on more stuff. You need not declare everything in every imported module. Only types that are used. There is at least one hard to solve problem here, for some level of lack of understanding at least. Specifically if you call t.compile on all types in Type.Compile, RecordType.Compiler => Scope.InitValues ?=> assertion failures about non-empty stack. It seems Type.Compile gets called "in the middle of stuff" instead of just from CompileAll. I'm almost stumped. I have to check still where Type.Compile vs. Type.CompileAll are called. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] importing types not described to backend > Date: Sat, 28 Aug 2010 09:54:54 +0000 > > > Interesting. > > TYPE Color1 = RECORD a,b,c: REAL; END; > TYPE Color2 = RECORD a,b,c: REAL; END; > > Have the same id. > If the module defining them also imports an interface with a type with the same id, > or I think, if its interface defines a type with same id (same thing I think, > no relationship at the cg level between a module and its interface), > then the declare_records are skipped. > > The fix is probably something simple in Type.Compile involve the order it checks the tables in > when deciding to call t.compile or not. > > Or can it just always call t.compile? > Worst thing is that extra type information created? > A lot of it? (all types in all imports, instead of just the used ones??) > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: RE: [M3devel] importing types not described to backend > > Date: Fri, 27 Aug 2010 18:35:00 +0000 > > > > > > Very wierd: > > > > MODULE Main; > > IMPORT Color; > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > BEGIN > > END F1; > > > > BEGIN > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > END Main. > > > > > > This fails. If you remove the IMPORT, it worked. > > The declare_record of ColorT comes and goes with that change. > > So I guess the error really is in F1. > > > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Date: Fri, 27 Aug 2010 18:28:47 +0000 > > > Subject: [M3devel] importing types not described to backend > > > > > > > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > > > > > INTERFACE Color; > > > TYPE T = RECORD a,b,c:REAL; END; > > > END Color. > > > > > > > > > MODULE Main; > > > IMPORT Color; > > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > > BEGIN > > > END F1; > > > > > > > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > > > BEGIN > > > END F2; > > > > > > > > > BEGIN > > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > > > END Main. > > > > > > > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > > > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > > > ../Main.m3: In function 'Main__F1': > > > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > > > > > > > I fixed it so F1 is ok. > > > But still F2 isn't. > > > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > > > > > > > The problem as I understand is we don't tell the backend about imported types. > > > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > > > > > > > I intend to fix this if I don't here any objections. > > > I'm hoping it isn't too much work. > > > I believe it will mostly/all be in m3front. > > > > > > > > > My opinion of our gcc backend drops.. > > > > > > > > > Perhaps the time is better used on a C front end. > > > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > > > > > > > Thanks, > > > - Jay > > > > > > From jay.krell at cornell.edu Sun Aug 29 09:52:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 07:52:23 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: , , , , , Message-ID: Arg. Another problem I see in some attempted fixes is: opaque type defined twice: _t9a0e5dbc ? defined in? FileWr.i3 ? and also??? System.m3 ? I don't need to reveal opaque types repeatedly but I do need to declare them repeatedly -- so that backend knows they are pointers.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 29 Aug 2010 07:35:24 +0000 > Subject: Re: [M3devel] importing types not described to backend > > > I've been quite banging my head against this. > I believe basically every type referenced in a module must be > "described" to the backend, such as with declare_opaque, declare_record, etc. > > Type.Compile should call t.compile on more stuff. > You need not declare everything in every imported module. Only types that are used. > > There is at least one hard to solve problem here, for some level of lack of understanding at least. > Specifically if you call t.compile on all types in Type.Compile, RecordType.Compiler => Scope.InitValues > => assertion failures about non-empty stack. > > It seems Type.Compile gets called "in the middle of stuff" instead of just from CompileAll. > > I'm almost stumped. > I have to check still where Type.Compile vs. Type.CompileAll are called. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: RE: [M3devel] importing types not described to backend > > Date: Sat, 28 Aug 2010 09:54:54 +0000 > > > > > > Interesting. > > > > TYPE Color1 = RECORD a,b,c: REAL; END; > > TYPE Color2 = RECORD a,b,c: REAL; END; > > > > Have the same id. > > If the module defining them also imports an interface with a type with the same id, > > or I think, if its interface defines a type with same id (same thing I think, > > no relationship at the cg level between a module and its interface), > > then the declare_records are skipped. > > > > The fix is probably something simple in Type.Compile involve the order it checks the tables in > > when deciding to call t.compile or not. > > > > Or can it just always call t.compile? > > Worst thing is that extra type information created? > > A lot of it? (all types in all imports, instead of just the used ones??) > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Subject: RE: [M3devel] importing types not described to backend > > > Date: Fri, 27 Aug 2010 18:35:00 +0000 > > > > > > > > > Very wierd: > > > > > > MODULE Main; > > > IMPORT Color; > > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > > BEGIN > > > END F1; > > > > > > BEGIN > > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > > END Main. > > > > > > > > > This fails. If you remove the IMPORT, it worked. > > > The declare_record of ColorT comes and goes with that change. > > > So I guess the error really is in F1. > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > > > From: jay.krell at cornell.edu > > > > To: m3devel at elegosoft.com > > > > Date: Fri, 27 Aug 2010 18:28:47 +0000 > > > > Subject: [M3devel] importing types not described to backend > > > > > > > > > > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > > > > > > > INTERFACE Color; > > > > TYPE T = RECORD a,b,c:REAL; END; > > > > END Color. > > > > > > > > > > > > MODULE Main; > > > > IMPORT Color; > > > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > > > BEGIN > > > > END F1; > > > > > > > > > > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > > > > BEGIN > > > > END F2; > > > > > > > > > > > > BEGIN > > > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > > > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > > > > END Main. > > > > > > > > > > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > > > > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > > > > ../Main.m3: In function 'Main__F1': > > > > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > > > > > > > > > > I fixed it so F1 is ok. > > > > But still F2 isn't. > > > > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > > > > > > > > > > The problem as I understand is we don't tell the backend about imported types. > > > > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > > > > > > > > > > I intend to fix this if I don't here any objections. > > > > I'm hoping it isn't too much work. > > > > I believe it will mostly/all be in m3front. > > > > > > > > > > > > My opinion of our gcc backend drops.. > > > > > > > > > > > > Perhaps the time is better used on a C front end. > > > > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > > > > > > > > > > Thanks, > > > > - Jay > > > > > > > > > > From jay.krell at cornell.edu Sun Aug 29 11:54:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 09:54:16 +0000 Subject: [M3devel] representation of opaque types? Message-ID: Are values of opaque types always pointers? Is that something that might change/improve? This for purposes of fixing the type information in the gcc backend. The backend really would like accurate type information. For purposes of passing records by value, and for debugging, at least. ?? Unless we would/should/could/will just deoptimize passing records by value, which would cover up this headache. I'll poke around more.. http://www.cs.tut.fi/lintula/manual/modula3/m3defn/html/opaques.html TYPE T <: U where T is an identifier and U an expression denoting a reference type. It introduces the name T as an opaque type and reveals that U is a supertype of T. The concrete type of T must be revealed elsewhere in the program. That clears it up -- U is a reference type. Seems like it might be nice if the "linker" could optimize and teach clients of opaque types their sizes and allow them to be stack-allocated. What does it mean when the front end says "new opaque info, recompiling"? I'll poke around.. ?- Jay From wagner at elegosoft.com Sun Aug 29 12:45:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 12:45:13 +0200 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, ,,, , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , , , <4C77D7D3.6070602@lcwb.coop>, , <4C796036.1000806@lcwb.coop> Message-ID: <20100829124513.otk0e8am8ww00gw8@mail.elegosoft.com> Quoting Jay K : > Ps we don't even have m3gdb for all systems e.g. Darwin, and the > Windows debuggers are much better than anything I've seen on Unix. > On these systems intermediate C would improve debugging much. Though > Darwin gdb I've also been improving. > > Also you seem to confuse C name mangling with what Modula-3 does. > They are quite different. C only mangles things with linkage, for > linking reasons, not for debugging information. Locals, parameters, > record fields: no mangling. C code analogous to what Modula-3 > allows would survive with everything being extern C, no name mangling. > > In both cases as I understand, an effective hack to tunnel > information through systems not quite designed/extended to suit. > > What we have is flawed. What I favor is flawed. But differently. We don't need to give up what we have in order to try something else additionally, do we? I think m3gdb works quite well on some platforms these days. Unfortunately, it doesn't build on others. On Windows we'll need something for the native debuggers anyway. Improving the use of other C debuggers will be good, too, for platforms we haven't got anything else. What I've learned from this discussion is that we should definitely try to support dwarf debugging format for the gcc backend. I'll add that as a task for the 5.9 release. And Jay has already announced that he will be working on a C backend. That should open up other possibilities. 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 Sun Aug 29 13:15:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 13:15:44 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org> References: <20100827173502.GA8777@topoi.pooq.com>, , <20100827180902.GA8903@topoi.pooq.com>, , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , <20100827193836.GC8903@topoi.pooq.com>, , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, <1282983172.2770.71.camel@boromir.m3w.org> <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org> Message-ID: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Quoting Darko : > I sort of meant software support. But isn't this all academic since > Elego is a CVS shop and they host the project? No. Elego is no CVS shop. We're not a shop at all in the sense that you can buy anything from our shelves. We help other companies improve their development processes wrt. software configuration management. Actually, almost all our work in the recent 2 yours has been Subversion-related. For more information of what we do, have a look at our web pages at http://www.elegosoft.com/. We used CVS for M3 at the start because it was the only reasonable possibility several years ago. I always opposed a switch of the system because it will bind a lot of resources we could use better, e.g. for improving the debugging support, IPv6 support, writing a C backend, etc. And we don't really need more than CVS offers. I still doubt that somebody will do all the work to set up a new version control infrastructure with easy migration, Hudson and trac integration, etc. If anybody sets up something that works better than what we have, we will of course use it. Elego will continue to provide some resources for the M3 project in form of CPU time, disk space and administration support if the community wants that. And we'll provide git or mercurial or svn access for M3 if it is needed. Actually, svn should be rather easy. We currently have some overload problems with the server that hosts CVS and the M3 continuous integration, which led me to reduce the number of checkouts and builds. This will be sorted out during the fall. Unfortunately, we don't have hard data about i/o needs of other systems compared to CVS yet (but we'll get them). BTW, CI is working quite well now, and produces nightly snapshots that can be downloaded for almost all supported platforms, so this is better than ever before. See http://hudson.modula3.com:8080/view/cm3-current/ for details. 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 Sun Aug 29 14:02:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 12:02:01 +0000 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: ?> We're not a shop at all in the sense that you can buy anything from our shelves "Shop" has a different meaning in this context. English is wierd. Roughly speaking "an X shop" is a "company that tends to use product X or products from company X, not necessarily to the exclusion of others" "a Microsoft shop" "a Java shop" "a Unix shop" "an Oracle shop" "a .NET shop" ?> And we don't really need more than CVS offers. ? A few things bug me. The number one is that there are no change lists, just multiple independent changes to independent files. I want to be able to browse history as a list of changes, and click on them, not navigate to each file individually. I would also like a system that keeps enough local state so that I can diff my local version against current without going to the slow unreliable network. The network is indeed very slow and unreliable. Perforce seems ideal in so many ways. Its command line interface is excellent. Its gui is very good. Its feature set is excellent. Its branching support is excellent. I don't know if it has good offline support though. I think I would settle for SVN. Though SVN has completely broken branching last I checked, and they acknowledged it. SVN also has relatively large dependencies to build from source. I would also like a system that doesn't drop files/directories all over the place. Just in the root of a checkout should suffice and be ideal. CVS is awful here and I believe SVN is too. Perforce maybe doesn't have the portability I'd like -- e.g. I don't see OpenBSD. But that might be an ok compromise, if copying can be done, or if those platforms can be requested. It seems they are extremely extremely portable but just don't bother to provide the binaries. Through time they do have excellent platform coverage. I'm sure we don't go for this, but I do recommend it wholeheartedly. I want a system that makes me do *something* before editing a file. ? Run some command to acknowledge I'm editing it, so it can keep track. I want a systerm with a command to undo the edits. With CVS I delete and update. Lame. I want a system that quickly knows which files I have changed. Perforce meets all these requirements. When I'm lazy I do: ? p4 edit ... ? spend a while editing ? p4 revert -a? to revert anything I didn't actually change ? It is wasteful, but plenty fast. I'd prefer a system that knows how to use windiff or some other decent gui to show diffs. I've gradually become comfortable with textual diffs. But I like gui diffs. Windiff is nice. Some people think it is old and limited, but it is much better than textual diffs. CVS handling of merges and conflicts is also very poor. ?- Jay ---------------------------------------- > Date: Sun, 29 Aug 2010 13:15:44 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system > > Quoting Darko : > > > I sort of meant software support. But isn't this all academic since > > Elego is a CVS shop and they host the project? > > No. Elego is no CVS shop. We're not a shop at all in the sense > that you can buy anything from our shelves. We help other companies > improve their development processes wrt. software configuration > management. Actually, almost all our work in the recent 2 yours > has been Subversion-related. For more information of what we do, > have a look at our web pages at http://www.elegosoft.com/. > > We used CVS for M3 at the start because it was the only reasonable > possibility several years ago. > > I always opposed a switch of the system because it will bind a lot > of resources we could use better, e.g. for improving the debugging > support, IPv6 support, writing a C backend, etc. And we don't > really need more than CVS offers. > > I still doubt that somebody will do all the work to set up a new > version control infrastructure with easy migration, Hudson and trac > integration, etc. If anybody sets up something that works better > than what we have, we will of course use it. > > Elego will continue to provide some resources for the M3 project > in form of CPU time, disk space and administration support if the > community wants that. And we'll provide git or mercurial or svn > access for M3 if it is needed. Actually, svn should be rather easy. > > We currently have some overload problems with the server that hosts > CVS and the M3 continuous integration, which led me to reduce the > number of checkouts and builds. This will be sorted out during > the fall. Unfortunately, we don't have hard data about i/o needs > of other systems compared to CVS yet (but we'll get them). > > BTW, CI is working quite well now, and produces nightly snapshots > that can be downloaded for almost all supported platforms, so this > is better than ever before. See > > http://hudson.modula3.com:8080/view/cm3-current/ > > for details. > > 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 Sun Aug 29 14:25:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 12:25:33 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <20100829124513.otk0e8am8ww00gw8@mail.elegosoft.com> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , , , , , ,,<20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, ,,, , , <4C77D7D3.6070602@lcwb.coop>, , , , <4C796036.1000806@lcwb.coop>, , <20100829124513.otk0e8am8ww00gw8@mail.elegosoft.com> Message-ID: > What I've learned from this discussion is that we should definitely try > to support dwarf debugging format for the gcc backend. I'll add that > as a task for the 5.9 release. I am not certain this makes any sense at all. I'm not sure. I don't think it is the job of a gcc front end (as Modula-3 is structured) to do anything for debugging, to know about debug formats, *except* to provide type-ful trees to the backend, which they should do anyway, except which Modula-3 historically doesn't do much. It is the job of the gcc backend -- below parse.c -- to generate debugging information. I think what Modula-3 currently does is "tunnel" a bunch of private data through to m3gdb. I think "stabs" might help associate the data with the code. Again, I don't know. And I think the trees are slightly well formed such that gcc can generate line numbers and knows a little bit about locals -- it shows pretty much everything as? void*. This is getting better lately though. I'm not doing anything specific to debugging or stabs or dwarf or something. I'm just filling in the types in the trees. There was already some code. I couldn't have figured this out so fast otherwise. We were already building struct types. But we weren't associating them with locals/parameters. What got me started down this area is actually that gcc cannot generate SPARC64_SOLARIS code that passes records by value without type information for the records. As well, if you only provide information to the caller or callee but not both, then AMD64_DARWIN and possibly others generate incorrect code. Then I realized what I had actually discovered is how to get stock gdb to work significantly better. What the code should have been doing all along. I suppose we could tunnel the private data through dwarf, but I don't think it would provide much gain. Mainly that HP-UX might stand a chance of working with a debugger. Might. Given the "data intensity" of the many debugging tasks, sprinking in RTIO calls is actually often much more effective than any debugger could be. You know, the code I want to debug gets hit many many times and I don't want to debug it until a certain late point. Getting there in a debugger is too difficult. Though easier if there is a way to get the debugger to stop, like by putting int 3 in x86 code. Win32 has the portable (to Win32 architectures) DebugBreak() call. Macintosh has similar. Too bad I haven't seen anything like this in Posix. Posix is generally very small and limiting.. ?- Jay ---------------------------------------- > Date: Sun, 29 Aug 2010 12:45:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? > > Quoting Jay K : > > > Ps we don't even have m3gdb for all systems e.g. Darwin, and the > > Windows debuggers are much better than anything I've seen on Unix. > > On these systems intermediate C would improve debugging much. Though > > Darwin gdb I've also been improving. > > > > Also you seem to confuse C name mangling with what Modula-3 does. > > They are quite different. C only mangles things with linkage, for > > linking reasons, not for debugging information. Locals, parameters, > > record fields: no mangling. C code analogous to what Modula-3 > > allows would survive with everything being extern C, no name mangling. > > > > In both cases as I understand, an effective hack to tunnel > > information through systems not quite designed/extended to suit. > > > > What we have is flawed. What I favor is flawed. But differently. > > We don't need to give up what we have in order to try something else > additionally, do we? > > I think m3gdb works quite well on some platforms these days. Unfortunately, > it doesn't build on others. > > On Windows we'll need something for the native debuggers anyway. > > Improving the use of other C debuggers will be good, too, for platforms > we haven't got anything else. > > What I've learned from this discussion is that we should definitely try > to support dwarf debugging format for the gcc backend. I'll add that > as a task for the 5.9 release. > > And Jay has already announced that he will be working on a C backend. > That should open up other possibilities. > > 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 Sun Aug 29 15:58:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 15:58:21 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> Quoting Jay K : > I think I would settle for SVN. > Though SVN has completely broken branching last I checked, and they > acknowledged it. > SVN also has relatively large dependencies to build from source. Branching in SVN is OK, merging is still wanting in case of tree conflicts. > I would also like a system that doesn't drop files/directories all > over the place. Just in the root of a checkout should > suffice and be ideal. CVS is awful here and I believe SVN is too. The working copy overhaul expected to be included in SVN 1.7 will keep all metadata at the root of the checkout in an SQL database. > I want a system that makes me do *something* before editing a file. > ? Run some command to acknowledge I'm editing it, so it can keep track. You can use cvs watch and cvs edit for that. I really wouldn't recommend it though. See also CVSREAD. > I want a systerm with a command to undo the edits. With CVS I delete > and update. Lame. cvs unedit > I'd prefer a system that knows how to use windiff or some other > decent gui to show diffs. tkcvs should work on all platforms. You may want to look at that. It also show graphical development line trees. > I've gradually become comfortable with textual diffs. > But I like gui diffs. Windiff is nice. Some people think it is old > and limited, but it is > much better than textual diffs. > > CVS handling of merges and conflicts is also very poor. Yes. No way to improve that, I'm afraid. 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 Sun Aug 29 17:05:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 17:05:44 +0200 Subject: [M3devel] cm3cg running amok In-Reply-To: <4C7869C8.7050600@lcwb.coop> References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> <4C7869C8.7050600@lcwb.coop> Message-ID: <20100829170544.l9x4yvd5340g0gkg@mail.elegosoft.com> The Hudson job for package tests on AMD64_FREEBSD was actually using a cm3cg binary from 2010-06-04 due to a configuration mistake. It may well be that changes in the interface or tree construction since then caused the problem. Currently the test-all-pkgs job progresses well on my system. Olaf Quoting "Rodney M. Bates" : > The ticked #1147 I reported a couple of weeks ago would probably show > this symptom. > That was AMD64_LINUX. > > Hmm, I think I never got back to supplying the attachment .ms file to > reproduce. > I'll try to do that tomorrow. I need sleep now too. > > Olaf Wagner wrote: >> I was just able to kill this process before my system ran out of swap >> space: >> >> % ps -wwwlp 95345 >> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND >> 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? >> 0:22.91 >> /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ RTHeapDebug.mc -o >> RTHeapDebug.ms >> >> It had already acquired more than 16 GB. >> >> Any ideas? >> >> 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 rcolebur at SCIRES.COM Sun Aug 29 19:19:28 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 29 Aug 2010 13:19:28 -0400 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com>, Message-ID: >I'd prefer a system that knows how to use windiff or some other decent gui to show diffs. >I've gradually become comfortable with textual diffs.> >But I like gui diffs. Windiff is nice. Some people think it is old and limited, but it is >much better than textual diffs. Jay, have you looked into WinMerge on Windows? I use WinMerge and TortoiseCVS with cm3. http://winmerge.org/ http://www.tortoisecvs.org/ Regards, Randy From hendrik at topoi.pooq.com Sun Aug 29 20:40:12 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 29 Aug 2010 14:40:12 -0400 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: <20100829184012.GA17077@topoi.pooq.com> On Sun, Aug 29, 2010 at 12:02:01PM +0000, Jay K wrote: > > ?> We're not a shop at all in the sense that you can buy anything from our shelves > > > "Shop" has a different meaning in this context. > English is wierd. > > > Roughly speaking "an X shop" is a "company that tends to use product X or products from company X, not necessarily to the exclusion of others" > "a Microsoft shop" > "a Java shop" > "a Unix shop" > "an Oracle shop" > "a .NET shop" > > > ?> And we don't really need more than CVS offers. > ? > > A few things bug me. > The number one is that there are no change lists, just multiple independent changes to independent files. monotone does this. > I want to be able to browse history as a list of changes, and click on them, not navigate to each file individually. One of the independent GUIs associated with monotone does this. > I would also like a system that keeps enough local state so that I can diff my local version against current > without going to the slow unreliable network. The network is indeed very slow and unreliable. monotone does this withoug using the unreliable network. > > > Perforce seems ideal in so many ways. Its command line interface is excellent. > Its gui is very good. > Its feature set is excellent. > Its branching support is excellent. > I don't know if it has good offline support though. > > > I think I would settle for SVN. > Though SVN has completely broken branching last I checked, and they acknowledged it. > SVN also has relatively large dependencies to build from source. > > > I would also like a system that doesn't drop files/directories all over the place. Just in the root of a checkout should > suffice and be ideal. CVS is awful here and I believe SVN is too. I don't know what you mean with files/directories all over the place. monotone does allow you to have mutiple workspaces (perhaps you are working on several bugs simultaneousle, on the same of different branches, without having more than one local copy of the entire repository. But I suspect this isn't what you mean with "all over the place". > > > Perforce maybe doesn't have the portability I'd like -- e.g. I don't see OpenBSD. > But that might be an ok compromise, if copying can be done, or if those platforms can be requested. > It seems they are extremely extremely portable but just don't bother to provide the binaries. > Through time they do have excellent platform coverage. > I'm sure we don't go for this, but I do recommend it wholeheartedly. monotone available for * Cygwin * Debian Linux * FreeBSD Ports * Mac OS X MacPorts * NetBSD pkgsrc * openSuSE Linux * Fedora Linux * Gentoo Linux and it's free and open source. So are quite a few other VCS's. We certainly don't want to be in the position the Linux kernel got into with bitkeeper. > I want a system that makes me do *something* before editing a file. > ? Run some command to acknowledge I'm editing it, so it can keep track. monotone can tell you what *has* been edited. Though it doesn't have a specific command that allows editing ... just what do you mean here? What do you really need? > I want a systerm with a command to undo the edits. With CVS I delete and update. Lame. I'm not sure what you mean here. > I want a system that quickly knows which files I have changed. > Perforce meets all these requirements. > > > When I'm lazy I do: > ? p4 edit ... > ? spend a while editing > ? p4 revert -a? to revert anything I didn't actually change > ? It is wasteful, but plenty fast. In monotone, you can just discard the entire workspace, create another. But you can also use the mtn revert ... command, where ... is a list od files and directories you specifically want to revert. There's also a command to remove the last revision you committed to the repository, as long as you haven't sync'd with another copy of the repositiry (in that case it would just com back the next time you sync'd) Is that wnat you want? > > > I'd prefer a system that knows how to use windiff or some other decent gui to show diffs. > I've gradually become comfortable with textual diffs. > But I like gui diffs. Windiff is nice. Some people think it is old and limited, but it is > much better than textual diffs. > > > CVS handling of merges and conflicts is also very poor. > Monotone on my system deals with merge conflicts by using emacs merge mode. Is that what you're talking about? But it's possible to have multiple heads on a branch. But that's not why I use monotone in my own work. I chose it primarily because of its utter paranoia about data loss. It's primarily its internal self-checking that makes it slow to the extent that it still is slow. I like that. For example, it will *not* sync with a damaged repository, thereby limiting contagion. I've heard of occasional problems checing out extremely old versions from CVS. Single-bit errors can have long-lasting consequences. But converting CVS to monotone seems still to be a pain. Monotone's own cvs to monotone conversion campaign failed on my (it turns out incomplete) copy of the Modula 3 repository I made several months ago, failing on some kind of internal consistency check, thereby protecting the monotone repository it was building. I should try it again after I re-cvsup the whole repository. For all I know, it may be a problem with my missing CVSROOT. -- hendrik P.S. I don't know how other version control systems rate on these issues at present. I suspect several would rate as well. Input on this from people with actual experience would be very useful. -- hendrik > > ?- Jay > From hendrik at topoi.pooq.com Sun Aug 29 20:43:28 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 29 Aug 2010 14:43:28 -0400 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> References: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> Message-ID: <20100829184327.GB17077@topoi.pooq.com> On Sun, Aug 29, 2010 at 03:58:21PM +0200, Olaf Wagner wrote: > >> I would also like a system that doesn't drop files/directories all >> over the place. Just in the root of a checkout should >> suffice and be ideal. CVS is awful here and I believe SVN is too. > > The working copy overhaul expected to be included in SVN 1.7 will > keep all metadata at the root of the checkout in an SQL database. There's some mechanism in monotone to handle checkouts from one package in a subdirectory of a checkout of another package, possibly from another repository. I don't kno whow it works. Other than this, all the metadata is indeed kept in the _MTN subdirectory of the root directory of a workspace. -- hendrik From hosking at cs.purdue.edu Mon Aug 30 15:58:36 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Aug 2010 09:58:36 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100830070111.78809247400F@birch.elegosoft.com> Message-ID: <77612C42-A038-4D0D-A47D-F731DB3D825C@cs.purdue.edu> This code using NARROW in RecordType.m3 is unfortunate. Should you not implement the "declare" method for Field.T instead, and then invoke Value.Declare on it? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 30 Aug 2010, at 03:09, Jay K wrote: > > diff attached > > - Jay > > ---------------------------------------- >> Date: Mon, 30 Aug 2010 09:01:11 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/08/30 09:01:11 >> >> Modified files: >> cm3/m3-sys/m3front/src/values/: Field.i3 Field.m3 >> cm3/m3-sys/m3front/src/types/: Type.m3 RecordType.m3 >> cm3/m3-sys/m3front/src/builtinOps/: BitSize.m3 >> >> Log message: >> Pass more type information to backend. Hopefully it will use it. >> >> In particular, if you imported: >> >> TYPE Foo = RECORD a:INTEGER; END: >> >> and you also defined yourself unrelated: >> >> TYPE Bar = RECORD a:INTEGER; END; >> >> then the anonymous "RECORD a:INTEGER END;" >> >> would not be described to the backend. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 30 22:46:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 30 Aug 2010 20:46:00 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <77612C42-A038-4D0D-A47D-F731DB3D825C@cs.purdue.edu> References: <20100830070111.78809247400F@birch.elegosoft.com> , <77612C42-A038-4D0D-A47D-F731DB3D825C@cs.purdue.edu> Message-ID: I'll look into that. My home network is down currently. There's still problems in this area, at least in the backend, probably not in the frontend at this point. - Jay Subject: Re: [M3commit] CVS Update: cm3 From: hosking at cs.purdue.edu Date: Mon, 30 Aug 2010 09:58:36 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu This code using NARROW in RecordType.m3 is unfortunate. Should you not implement the "declare" method for Field.T instead, and then invoke Value.Declare on it? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 30 Aug 2010, at 03:09, Jay K wrote: diff attached - Jay ---------------------------------------- Date: Mon, 30 Aug 2010 09:01:11 +0000 To: m3commit at elegosoft.com From: jkrell at elego.de Subject: [M3commit] CVS Update: cm3 CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/08/30 09:01:11 Modified files: cm3/m3-sys/m3front/src/values/: Field.i3 Field.m3 cm3/m3-sys/m3front/src/types/: Type.m3 RecordType.m3 cm3/m3-sys/m3front/src/builtinOps/: BitSize.m3 Log message: Pass more type information to backend. Hopefully it will use it. In particular, if you imported: TYPE Foo = RECORD a:INTEGER; END: and you also defined yourself unrelated: TYPE Bar = RECORD a:INTEGER; END; then the anonymous "RECORD a:INTEGER END;" would not be described to the backend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 31 13:25:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 11:25:43 +0000 Subject: [M3devel] a trouble with passing records by value.. Message-ID: Given something like this: jbook2:p247 jay$ more 1.c #include typedef struct { long code; long value; } T1; void ActionLookup(T1 t, long code, long value); void ActionLookup(T1 t, long code, long value) { ? assert(t.code == code); ? assert(t.value == value); } int main() { ? T1 t1 = {2,2}; ? ActionLookup(t1, 2, 2); ? return 0; } j on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. Darn. If m3cg were higher level this could be better. There should be a viable compromise where the parameter is passed in registers, and only "homed" to some stack location if its address is used -- e.g. to pass unused parameters in registers. But given the inefficiency of field accesses, I'm not sure it is worth trying? Maybe we should have M3CG include field references? There is this basic problem that the interface between m3front and m3cc isn't really at the right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. ?- Jay From hosking at cs.purdue.edu Tue Aug 31 15:15:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Aug 2010 09:15:32 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: Message-ID: What happens if you take the address of t inside ActionLookup? What happens if you take the address of t1 inside main? On 31 Aug 2010, at 07:25, Jay K wrote: > > Given something like this: > > jbook2:p247 jay$ more 1.c > #include > > typedef struct { long code; long value; } T1; > > void ActionLookup(T1 t, long code, long value); > > void ActionLookup(T1 t, long code, long value) > { > assert(t.code == code); > assert(t.value == value); > } > > int main() > { > T1 t1 = {2,2}; > ActionLookup(t1, 2, 2); > return 0; > } > j > > > on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > > However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > Darn. > > > If m3cg were higher level this could be better. > > > There should be a viable compromise where the parameter is passed in registers, and only "homed" > to some stack location if its address is used -- e.g. to pass unused parameters in registers. > But given the inefficiency of field accesses, I'm not sure it is worth trying? > > > Maybe we should have M3CG include field references? > > > There is this basic problem that the interface between m3front and m3cc isn't really at the > right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > > - Jay > From jay.krell at cornell.edu Sun Aug 1 00:13:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 31 Jul 2010 22:13:58 +0000 Subject: [M3devel] rmrec problems -- delete while enumerating Message-ID: Aha. http://www.cz.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/readdir.c Strongly hints at problems related to deleting and enumerating at the same time. >From that then, I'll make another speculation -- enumeration ends up missing entries. IF IF IF the directory is viewed like an array, and if readdir maintains a position, moving forwad in chunks, and if delete underneath it shifts everything down, then, I think one can see the problem. I'm not sure which of these statements is true though. Certainly deleting while enumerating is not in general obvious how to deal with. Depending on a few factors. In STL documentation, they always mention what iterators are invalidated by deletion. It varies from collection to collection and perhaps other aspects. As to why my "rewrite" isn't working, I don't know, I can't look at until Monday. It looks simple and correct, I tested it some, and should deal with delete-during-enumerate. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Aug 3 01:08:48 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 02 Aug 2010 18:08:48 -0500 Subject: [M3devel] trac ticket 1147, additional info Message-ID: <4C575000.5000208@lcwb.coop> I couldn't find any place to attach these files directly to a ticket. They are definitely relevant. The file Test.mc, needed to rerun the error, is 906386 bytes. Ask if you want it. Note: The same symptom occurs on LINUXLIBC6. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: failurelog URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: backtrace URL: From wagner at elegosoft.com Tue Aug 3 09:05:17 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 03 Aug 2010 09:05:17 +0200 Subject: [M3devel] Fwd: [CM3] #1147: Runaway recursion in m3cc. Message-ID: <20100803090517.km5chcezw40cskw4@mail.elegosoft.com> FYI ----- Forwarded message from bugs at elego.de ----- Date: Mon, 02 Aug 2010 22:59:36 -0000 From: CM3 Reply-To: CM3 Subject: [CM3] #1147: Runaway recursion in m3cc. To: rodney.m.bates at acm.org, wagner at elego.de #1147: Runaway recursion in m3cc. -------------------------------------+-------------------------------------- Reporter: rodney.m.bates@? | Owner: wagner Type: sw-bug | Status: new Priority: medium | Milestone: CM3 Release 5.9 Component: sys | Version: 5.8-RC3 Severity: serious | Keywords: m3cc, recursion Relnote: | Confidential: no Org: | Estimatedhours: 0 Hours: 0 | Billable: 0 Totalhours: 0 | Internal: 0 -------------------------------------+-------------------------------------- Htr: run command: /usr/local/cm3//bin/cm3cg -gstabs+ -m64 -fPIC -mno-align-double -funwind-tables -quiet -fno-reorder-blocks Test.mc -o Test.ms with file Test.ms present. This file to be supplied. Fix: Env: m3cc from branch cm3-5-8-release, up to date as of 2010-8-1, except for using dbxout.c 1.8, instead of 1.9, which is almost certainly irrelevant -------------------------------------+-------------------------------------- m3cc crashes after runaway recursion in gcc's garbage collector, collecting nodes apparently created in parse.c. There is a linear list of 261924 nodes of kind TS_FIELD_DECL, linked on the 'chain' field. This is rooted in field 'chain' of a TS_FUNCTION_DECL node. These are node types created from parse.c. -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 3 11:36:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Aug 2010 09:36:53 +0000 Subject: [M3devel] rmrec problems Message-ID: There seems to another final problem, or maybe this was the problem all along, or maybe maybe I introduced this with the previous fix (*) stat on a symlink whose target has been deleted, apparently fails. e.g. m3cc/target/gmp/.libs/libgmp.la -> ../libgmp.la *: maybe I introduced it: Well, before it might have been sensitive to directory enumeration order. My change deletes files and then subdirectories, making it no longer sensitive that way. Fix will be to use lstat I believe. And I'll just report symlinks to be regular files. And opening them can fail with file not found... which I'm sure will break something somewhere -- enumerated files no longer necessarily exist... Probably no win. Probably the original interfaces didn't consider symlinks, since they aren't portable. Yet without considering them, and composing rmrec on lower level suppostedly portable interfaces..you can't ignore them. Can't win. ?- Jay From jay.krell at cornell.edu Tue Aug 3 11:50:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 3 Aug 2010 09:50:32 +0000 Subject: [M3devel] m3 mailing lists? Message-ID: Are m3commit or m3devel working? I know there was scheduled maintenance but I figured that'd be under a day. ?- Jay From jay.krell at cornell.edu Wed Aug 4 05:53:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 03:53:47 +0000 Subject: [M3devel] m3override In-Reply-To: <20100730215051.GA23133@topoi.pooq.com> References: , , <20100730215051.GA23133@topoi.pooq.com> Message-ID: > I remember using an override somewhere ... but I don't remember where or > why now. So..it sounds like maybe you don't know what overrides are. That is ok. But you can't then reason about changes to them. Including claiming that all changes are scary or bad. Not that you did, but many people are prone to that way of thinking. > But I'd worry if this change broke something. Sure. You should sorry about anything that breaks anything. But this doesn't break anything. And, if it did, you'd have to apply context-sensitive heuristics. Does it break anything that matters? Matters much? What is the cost of maintaining the code to preserve "everything" "working"? Were the definitions of "working" correct in the first place? Does widespread expectation make something correct? Realize that for nearly any given change, I can tell you something that it breaks. rmrec wasn't working. But I could easily theorize code that depended on it not working. It not working was a way to detect certain characteristics of the filesystem -- presence of symlinks, possible behaviors of readdir+unlink. LONGINT didn't exist, in the base language. But I was using LONGINT as a type already, TYPE LONGINT = ARRAY [0..1] OF INTEGER. (No, I wasn't actually.) Putting it in the language broke such code. Time passing breaks code. Seriously. (Year2000, Year2038). But you can't really stop it. Except by changing the time on your computer to be wrong. In either case, I put the useless warning back and changed our master m3override to ignore it. That is *not* evidence of the utility of the warning, that it made me change code to ignore. There is not actual improvement to the code by avoiding the warning. To understand this stuff, it helps to consider make and make install and chroot. Can I run stuff I haven't run "make install" on? Sometimes. Can I build my own libc.so without chroot? Sometimes. Modula-3 merely reinveints those sorts of things itself. Those things are flawed and Modula-3 fixes some but not all of the flaws. while still leaving major problems present. It is this consistent not fixing all the problems that makes me consider it not worth being so different.. Ultimately chroot is the heavyweight reliable solution. And/or strictly building things -- everything -- from the bottom of the dependency tree and up. In the Modula-3 build system, there is a "package store". e.g. /usr/local/cm3/pkg. That contains packages, e.g. /usr/local/cm3/pkg/m3core. When you say "import(m3core)", it has to find m3core somewhere. The default is package store + package name -- e.g. /usr/local/cm3/pkg/m3core. If you are building package foo, let's say at /usr/src/foo, and you want it to use some custom m3core, which is at /usr/src/m3core then you create /usr/src/foo/src/m3overrides that says override("m3core", "/usr/src") something like that. This is deceptive though. You sort of can't actually do this. Not so easily. You can only really do it if everything in the dependency tree between foo and m3core were also built using the same overrides. You need consistent definitions of types, interfaces, etc. But granted, if you only changed implementation, you can maybe do it. Of course, static linking interferes as well. Are you using stubgen? Should it pickup the new m3core? Then you have to build it too. Which is to say, you can really only use entire alterate package stores. You can't really pick and choice packages from one place or another. Unless you are very careful. And none of our codebases are particularly large anyway. You might as well just make whatever source changes in any package and build it all to alternative package store. Even relying on good albeit buggy incrementality in cm3. Another way to view this, the way we use it in Hudson et. al. is that there are precisely two package stores. /usr/local/cm3/pkg and the "uninstalled" or "unshipped" /usr/cvs/cm3/m3-libs/m3core, /usr/cvs/cm3/m3-sys/m3quake etc. The m3overrides file points into the CVS checkout, which, regrettably, also contains all of our outputs. (see also: "read only source tree", which we sort of have, sort of are/were ahead of everyone else, but not really..) cm3 -x uses the m3overrides files. Cm3 without -x does not. And we use it as I described -- not to pick and chose packages from one place or another. But to pick and chose all packages from one overall tree or another. And then you run into the potential problem that the two directories have a different layout. So stuff like rpath $ORIGIN/../lib doesn't work. Ultimately, often people want binaries to work without running make install. And they often do. Ultimately chroot is how you really build custom stuff. But it seems onerous. I have almost never done it. We can cheat, because we don't build ld.so, libc.so. We only need "chroot" from a certain point and on up. I suggest instead of overrides, instead: 1) have the "intermediate" (not installed) files go into a layout like the current install, not next to the source as currently This is the .a/.so/.exe files, not the .o/.obj/.mo/.io files. .o/.obj/.mo/.io belong somewhere else. 2) "install" is merely deleting one root and copying or renaming the other over it 3) no more notion of overrides If you don't want to build "everything", you can instead copy or hardlink-tree the original. (symlinks won't do, not used with $ORIGIN; though maybe we should abandon $ORIGIN? So many systems don't support it, it turns out). There are tradeoffs either way. In this scheme, rpath $ORIGIN/../lib works without install. You would no longer have executables in the package store, only in cm3root/bin. We could stop statically linking anything. However you do lose "hierarchical naming". Well, maybe. Maybe executables in the package store would use rpath $ORIGIN/../../lib. Heck, maybe the model is everything is in the package store and bin and lib only contain symlinks? (the warning still hasn't been explained, or maybe I'm behind on email) - Jay > Date: Fri, 30 Jul 2010 17:50:51 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > On Fri, Jul 30, 2010 at 01:58:45AM +0000, Jay K wrote: > > > > Randy, Without reading the code, what does it mean? > > > > My first guess was I believe wrong and based on reading the code I think it is even more pointless than I previously thought. > > > > It gets printed *all the time*, when using overrides. Look at any of the Hudson logs. > > > > It wouldn't be printed so much in the older way of doing things, where overrides were applied haphazardly and incompletely. Now that they are used fairly consistently/correctly, it always triggers. I hope to eventually replace the overrides mechanism -- if we just put files into a designated root directory, with the same structure as "the install", then "override" is just setting that directory, optionally prepopulating with an entire copy of the current install -- depending on if you want to build up from scratch or selectively override. You could use hardlinks to speed it up, as long as our copy is delete + copy and not just copy (sometimes a copy will share with the original link(s), sometimes it will unshare, depending on the open flags (I think) or if you first delete). And "install" becomes just moving the install root, if the new one is complete. > > I remember using an override somewhere ... but I don't remember where or > why now. But I'd worry if this change broke something. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Aug 4 08:21:54 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 08:21:54 +0200 Subject: [M3devel] trac ticket 1147, additional info In-Reply-To: <4C575000.5000208@lcwb.coop> References: <4C575000.5000208@lcwb.coop> Message-ID: <20100804082154.isv1z0fvwoow084o@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I couldn't find any place to attach these files directly to a ticket. They > are definitely relevant. The file Test.mc, needed to rerun the error, is > 906386 bytes. Ask if you want it. Are you logged in? Probably trac doesn't allow attachments to anonymous tickets. What about this link: https://projects.elego.de/cm3/attachment/ticket/1147/?action=new ? Hope this helps, 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 Wed Aug 4 08:49:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 08:49:30 +0200 Subject: [M3devel] m3override In-Reply-To: References: , , <20100730215051.GA23133@topoi.pooq.com> Message-ID: <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com> I wouldn't worry much about the warning Jay removed. It only said that an override wasn't used, which is the default behaviour of cm3 (without -x or -override option). One could argue that if one wanted this warning, one should use an option like -warn=overrides or -warn=all (which don't actually exist (yet)). However, I'd still like others to think about the two perspectives one can take here, and what should be the direction we are tweaking our build system. Traditionally, the focus was on the package view, i.e. the view of one developer, and not a whole system. The builder was designed to work well in this setup (more or less). For one notable exception, which others have noticed (who were involved with the original design): linking has never been tried implement portably in a general way. With this focus, overrides are the sole responsibility of the developer, and one could argue that he should know exactly what he does if he uses them. In the CM3 distribution, I used the override feature to allow building the whole set of package in the workspace, which can be seen equivalent to use a completely different package pool. The scripts (which originally were only meant as a tool for the distribution maintainer) distinguish between build(local) and buildglobal (or buildship). In the first case, the global package store isn't involved at all. Jay has suggested to optimize towards building the whole distribution, but I'm not sure yet if that's the correct direction. Obviously, we need to support both perspectives. Much of the charm of the M3 build system for large projects is based on the way the work of the single developers can be split up and isolated. And in large projects there are of course more developers than build or release engineers. But then, there seems to have been no real use of CM3 for this kind of development for many years; most (all?) active users seem to work on their projects alone. So perhaps Jay is right after all? 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 Wed Aug 4 11:21:57 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 11:21:57 +0200 Subject: [M3devel] rmrec problems In-Reply-To: References: Message-ID: <20100804112157.d3anktcy5ck40gso@mail.elegosoft.com> Quoting Jay K : > There seems to another final problem, or maybe this was the problem > all along, or maybe maybe I introduced this with the previous fix (*) > stat on a symlink whose target has been deleted, apparently fails. > e.g. m3cc/target/gmp/.libs/libgmp.la -> ../libgmp.la > > *: maybe I introduced it: Well, before it might have been sensitive > to directory enumeration order. > My change deletes files and then subdirectories, making it no longer > sensitive that way. > > Fix will be to use lstat I believe. > > And I'll just report symlinks to be regular files. Treating symbolic links as files for the simple needs of the FSUtils module sounds OK, but the rm should of course only remove the link. I assume that's what you've done though, as removing the real file would require computing the real path. > And opening them can fail with file not found... which I'm sure will > break something somewhere -- enumerated files no longer necessarily > exist... Sounds OK, too. > Probably no win. > > Probably the original interfaces didn't consider symlinks, since > they aren't portable. > Yet without considering them, and composing rmrec on lower level > suppostedly portable interfaces..you can't ignore them. > Can't win. Yes, the old interface are portable, but not really sufficient for more sophisticated file systems which are more or less standard these days. Perhaps a careful review/redesign of this area would be a good idea, too. 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 Wed Aug 4 12:42:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 10:42:42 +0000 Subject: [M3devel] rmrec problems In-Reply-To: <20100804112157.d3anktcy5ck40gso@mail.elegosoft.com> References: , <20100804112157.d3anktcy5ck40gso@mail.elegosoft.com> Message-ID: > Treating symbolic links as files for the simple needs of the FSUtils > module sounds OK, but the rm should of course only remove the link. Right: my understanding and intent is that just the link, not the link target, is deleted. I can't guarantee at this point, but that was my understanding and intent. There was already *some* existing behavior. If you just delete the link, it'd do something. What didn't work is enumerating/stat'ing a link whose target doesn't exist, en route to deleting the link. (In our actual use, we do delete the target, because what we are enumerating and deleting both of the link and its target.) > for more sophisticated file systems which are more or less standard > these days. Perhaps a careful review/redesign of this area would be > a good idea, too. Even if they aren't "standard" -- even if not every host has them -- certainly many hosts do. I have done so much programming in the absence of symbolic links..I'm very uncertain how to reason about them. They allow for infinite loops in the namespace. Hardlinks too add additional confusion/meaning. Possible problem is that historically a symlink to an existing directory was reported as a directory. Now it is reported as a file. We could, expensively, first try stat, and if it fails for file/path not found, lstat instead. That might work. But I'd rather leave it as is. Maybe add another bit to the file status to indicate it is a symlink. Or possibly return the type as a new type, symlink, but no existing caller would know how to handle that. Probably adding another bit is reasonable, and update the Trestle file open dialogs to use a different icon. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Aug 4 12:56:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 10:56:13 +0000 Subject: [M3devel] m3override In-Reply-To: <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com> References: , , , , <20100730215051.GA23133@topoi.pooq.com>, , <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com> Message-ID: Specifically it is a warning about overriding the package you are building. The thing is, isn't the "bits and pieces overridden" model prone to just not work? Which pieces do you build vs. which do you leave alone? You need "everything" to be "fairly" consistent, for some definition of "everything" and "fairly". There is a larger unsolved problem here -- which parts of a system can you change independently of which parts? There are two extremes: one thing at a time, or everything at a time. The truth is generally in between: some things at a time. Which? "Everything" at a time is more difficult the larger you define "everything". "one" thing at a time, and again "one" possibly varies -- maybe you distribute .o files? "one" thing at at time leads to a combinatorial explosion of combination of "things" that are "supposed" to work. With some (enough?) runtime checking that a valid composition has been made. (Certainly Modula-3 tries much harder here than C.) I kind of espouse a model of "everything at time", but you can "pre-seed" the new package store/install with a copy/link of the original (as long you delete before writing over links). > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. Do you mean like, regarding $ORIGIN? Or something else? I'm too blame for giving us $ORIGIN, and I'm now very ambivalent about it. libtool + relink upon install seems the better approach and is widely used in practise. e.g. OpenBSD. This has a side benefit that uninstalled/unshipped dynamic binaries do work. I do suspect $ORIGIN was an improvement, since we don't relink upon install. There is also a hybrid suggestion of what I have suggested and the current model. You can still "build" into a new empty directory, with a hierarchy matching the install, leaving open either later install in-place or "reroot". I think, really, I have to back down from $ORIGIN, which restores "pick and chose" to work when it can, we can still, as I said, build into an install-like structure, and install by "reroot" or "delete and copy". I think the key is doing relink upon install. Along with, no longer distributing fully built binaries. There is a big task here but I think we have seen enough real problems and discussed enough the theory, to end up at a conclusion -- no $ORIGIN, no binaries, distribute C source, assembly source (or maybe .o files), and do final link on the target. We can distribute some common binaries, like with hardcoded install location. The hudon builds might be tricky, since if we build binaries to install to /usr/local/cm3, we can't then install and test them. Unless maybe chroot is possible as non-root?? Possibly Hudson builds would install to $HOME/... and just the final distribution wouldn't. Probably. I kind of..can't think of the word...really don't like this conclusion. Am nervous. How many people install binaries vs. compile/link? This would be signing up for much additional headache all around? Compile/link would fail for lots of people and we'd have to help them a lot more? Or it's not that bad and we just have to do it? - Jay > Date: Wed, 4 Aug 2010 08:49:30 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3override > > I wouldn't worry much about the warning Jay removed. > It only said that an override wasn't used, which is the default > behaviour of cm3 (without -x or -override option). One could argue > that if one wanted this warning, one should use an option like > -warn=overrides or -warn=all (which don't actually exist (yet)). > > However, I'd still like others to think about the two perspectives > one can take here, and what should be the direction we are tweaking > our build system. > > Traditionally, the focus was on the package view, i.e. the view of > one developer, and not a whole system. The builder was designed to > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. > With this focus, overrides are the sole responsibility of the > developer, and one could argue that he should know exactly what > he does if he uses them. > > In the CM3 distribution, I used the override feature to allow > building the whole set of package in the workspace, which can be > seen equivalent to use a completely different package pool. > The scripts (which originally were only meant as a tool for the > distribution maintainer) distinguish between build(local) and > buildglobal (or buildship). In the first case, the global package > store isn't involved at all. > > Jay has suggested to optimize towards building the whole distribution, > but I'm not sure yet if that's the correct direction. Obviously, > we need to support both perspectives. Much of the charm of the > M3 build system for large projects is based on the way the work > of the single developers can be split up and isolated. And in large > projects there are of course more developers than build or release > engineers. But then, there seems to have been no real use of CM3 for this > kind of development for many years; most (all?) active users seem to > work on their projects alone. So perhaps Jay is right after all? > > 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 Wed Aug 4 13:31:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 11:31:56 +0000 Subject: [M3devel] m3override In-Reply-To: References: , ,,, , , <20100730215051.GA23133@topoi.pooq.com>, , , , <20100804084930.j3w397hzr4wwc0go@mail.elegosoft.com>, Message-ID: ps: another suggestion here: Don't use overrides in Hudson or package building. Instead either build from scratch or with a new install that is a copy of the current (ie. of m3core/libm3). I alread automated this in make-dist.py, which is a based on some other *.sh. And then copy/swap at the end, or after some testing. Except, er, um, either this is with $ORIGIN, or with relink upon install -- not just copy/swap. The central sticking point in "all" this, in software configuration in general -- is "run path". And then, delete all the m3overrides files in the tree. And then optionally remove the entire mechanism, or leave it alone, unused, to bitrot. To some extent this is: don't bother implementing a mechanism in cm3, just do it in scripts. > M3 build system for large projects is based on the way the work > of the single developers can be split up and isolated. And in large Imagine a system composed of five pieces: bottom, almost bottom, middle, almost top, top. The developer of "top" has it easy, he uses the "existing" bottom, almost bottom, middle, almost top. What are the developers of any other piece to do? There are at least two factors to consider: run path public interfaces Even if public interfaces are unchanged, developer building a new "almost top", must either put it where "top" expects, or rebuild top to get it from the new location. It has been said that LD_LIBRARY_PATH is for development scenarios. So maybe that is the answer. To whatever extent systems are composed of just bottom and top and nobody changes bottom, which I think is actually pretty common, no problem, and people don't even understand the potential problem (I theorize). But that seems..wrong. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 4 Aug 2010 10:56:13 +0000 Subject: Re: [M3devel] m3override Specifically it is a warning about overriding the package you are building. The thing is, isn't the "bits and pieces overridden" model prone to just not work? Which pieces do you build vs. which do you leave alone? You need "everything" to be "fairly" consistent, for some definition of "everything" and "fairly". There is a larger unsolved problem here -- which parts of a system can you change independently of which parts? There are two extremes: one thing at a time, or everything at a time. The truth is generally in between: some things at a time. Which? "Everything" at a time is more difficult the larger you define "everything". "one" thing at a time, and again "one" possibly varies -- maybe you distribute .o files? "one" thing at at time leads to a combinatorial explosion of combination of "things" that are "supposed" to work. With some (enough?) runtime checking that a valid composition has been made. (Certainly Modula-3 tries much harder here than C.) I kind of espouse a model of "everything at time", but you can "pre-seed" the new package store/install with a copy/link of the original (as long you delete before writing over links). > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. Do you mean like, regarding $ORIGIN? Or something else? I'm too blame for giving us $ORIGIN, and I'm now very ambivalent about it. libtool + relink upon install seems the better approach and is widely used in practise. e.g. OpenBSD. This has a side benefit that uninstalled/unshipped dynamic binaries do work. I do suspect $ORIGIN was an improvement, since we don't relink upon install. There is also a hybrid suggestion of what I have suggested and the current model. You can still "build" into a new empty directory, with a hierarchy matching the install, leaving open either later install in-place or "reroot". I think, really, I have to back down from $ORIGIN, which restores "pick and chose" to work when it can, we can still, as I said, build into an install-like structure, and install by "reroot" or "delete and copy". I think the key is doing relink upon install. Along with, no longer distributing fully built binaries. There is a big task here but I think we have seen enough real problems and discussed enough the theory, to end up at a conclusion -- no $ORIGIN, no binaries, distribute C source, assembly source (or maybe .o files), and do final link on the target. We can distribute some common binaries, like with hardcoded install location. The hudon builds might be tricky, since if we build binaries to install to /usr/local/cm3, we can't then install and test them. Unless maybe chroot is possible as non-root?? Possibly Hudson builds would install to $HOME/... and just the final distribution wouldn't. Probably. I kind of..can't think of the word...really don't like this conclusion. Am nervous. How many people install binaries vs. compile/link? This would be signing up for much additional headache all around? Compile/link would fail for lots of people and we'd have to help them a lot more? Or it's not that bad and we just have to do it? - Jay > Date: Wed, 4 Aug 2010 08:49:30 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3override > > I wouldn't worry much about the warning Jay removed. > It only said that an override wasn't used, which is the default > behaviour of cm3 (without -x or -override option). One could argue > that if one wanted this warning, one should use an option like > -warn=overrides or -warn=all (which don't actually exist (yet)). > > However, I'd still like others to think about the two perspectives > one can take here, and what should be the direction we are tweaking > our build system. > > Traditionally, the focus was on the package view, i.e. the view of > one developer, and not a whole system. The builder was designed to > work well in this setup (more or less). For one notable exception, > which others have noticed (who were involved with the original design): > linking has never been tried implement portably in a general way. > With this focus, overrides are the sole responsibility of the > developer, and one could argue that he should know exactly what > he does if he uses them. > > In the CM3 distribution, I used the override feature to allow > building the whole set of package in the workspace, which can be > seen equivalent to use a completely different package pool. > The scripts (which originally were only meant as a tool for the > distribution maintainer) distinguish between build(local) and > buildglobal (or buildship). In the first case, the global package > store isn't involved at all. > > Jay has suggested to optimize towards building the whole distribution, > but I'm not sure yet if that's the correct direction. Obviously, > we need to support both perspectives. Much of the charm of the > M3 build system for large projects is based on the way the work > of the single developers can be split up and isolated. And in large > projects there are of course more developers than build or release > engineers. But then, there seems to have been no real use of CM3 for this > kind of development for many years; most (all?) active users seem to > work on their projects alone. So perhaps Jay is right after all? > > 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 wagner at elegosoft.com Wed Aug 4 14:58:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 14:58:30 +0200 Subject: [M3devel] m3override Message-ID: <20100804145830.yz17as1yo04sgc0s@mail.elegosoft.com> Quoting Jay K : > ps: another suggestion here: > Don't use overrides in Hudson or package building. > Instead either build from scratch or with a new install that is a > copy of the current (ie. of m3core/libm3). I alread automated this > in make-dist.py, which is a based on some other *.sh. > And then copy/swap at the end, or after some testing. > Except, er, um, either this is with $ORIGIN, or with relink upon > install -- not just copy/swap. > > The central sticking point in "all" this, in software configuration > in general -- is "run path". > > And then, delete all the m3overrides files in the tree. And then > optionally remove the entire mechanism, or leave it alone, unused, > to bitrot. > > To some extent this is: don't bother implementing a mechanism in > cm3, just do it in scripts. I've got no time for large changes, so we'll see if anybody cares to implement anything. >> M3 build system for large projects is based on the way the work >> of the single developers can be split up and isolated. And in large > > Imagine a system composed of five pieces: bottom, almost bottom, > middle, almost top, top. > The developer of "top" has it easy, he uses the "existing" bottom, > almost bottom, middle, almost top. > What are the developers of any other piece to do? > There are at least two factors to consider: > run path > public interfaces > > Even if public interfaces are unchanged, developer building a new > "almost top", must either put it where "top" expects, or rebuild top > to get it from the new location. > > It has been said that LD_LIBRARY_PATH is for development scenarios. > So maybe that is the answer. > > To whatever extent systems are composed of just bottom and top and > nobody changes bottom, which I think is actually pretty common, no > problem, and people don't even understand the potential problem (I > theorize). But that seems..wrong. Well, you see I've got the view of somebody building very large systems (much larger than the CM3 distribution) for commerical use. I've been working in such projects for the recent years; they're programmed in C/C++ and Java (and make and ClearCase and Perl scripts and ...), and build management and correct dependency tracking and use is always a nightmare. M3 with its powerful abstractions would be a great improvement there, but of course that's completely out of the question. But nonetheless it's still interesting to think about how M3 would actually compete in this domain. From a manager and user point of view, there are business functions which may be attached to some real or virtual machine or to some computing farm. From an architects view there are software layers, components with interfaces and implementations, containers for running processes and threads etc. And of course there are large external systems that are used or with which data must be exchanged. From a build and release engineers point of view, there are hundred thousands of files most of which exist in several hundred versions of which about a dozen or more are part of valid and still supported or actively developed configurations, that must build and play together consistently. And these must be unit tested, integration tested, system tested and performance tested. Everything (more or less) changes continually, starting with the requirements :-) Nobody has a complete overview, but the developers must be isolated and given a usable working configuration and setup to accomplish their tasks. This is where abstraction and information hiding show the biggest benefits. No developer here is able to build the whole system; most are even not allowed to read most of the code (if by accident or on purpose isn't always clear). And of course development teams are distributed to several sites around the world. So I'm not thinking about minor technical issues like $ORIGIN or LD_LIBRARY_PATH or about how we are best able to distribute the cm3 packages, but rather about M3 and its package and other abstraction mechanisms would stand its ground in such a project. And if we should really consider that or just be satisfied with our small CM3 community and use cases. 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 Wed Aug 4 15:37:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 4 Aug 2010 13:37:48 +0000 Subject: [M3devel] m3cc package failures ignored? Message-ID: There's some problem, I've been noticing a while on my machine(s) where failure to build m3cc isn't noticed. e.g.: http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/21/console ??? ... -rw-r--r-- 1 hudson hudson??? 6872 2010-07-28 13:47 xstrerror.o -rw-r--r-- 1 hudson hudson??? 6736 2010-07-28 13:47 xstrndup.o ./libiberty/testsuite: total 4 -rw-r--r-- 1 hudson hudson 2722 2010-07-28 13:44 Makefile Fatal Error: package build failed ?==> m3-sys/m3cc done -- and then it keeps going -- === package m3-libs/m3core === ?+++ cm3 -build -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3' $RARGS? && cm3 -ship $RARGS -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3'? +++ From wagner at elegosoft.com Wed Aug 4 17:26:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 04 Aug 2010 17:26:34 +0200 Subject: [M3devel] m3cc package failures ignored? In-Reply-To: References: Message-ID: <20100804172634.tt8y73lcwk8k40cg@mail.elegosoft.com> Quoting Jay K : > There's some problem, I've been noticing a while on my machine(s) > where failure to build m3cc isn't noticed. > > e.g.: > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/21/console > ... > -rw-r--r-- 1 hudson hudson??? 6872 2010-07-28 13:47 xstrerror.o > -rw-r--r-- 1 hudson hudson??? 6736 2010-07-28 13:47 xstrndup.o > > ./libiberty/testsuite: > total 4 > -rw-r--r-- 1 hudson hudson 2722 2010-07-28 13:44 Makefile > Fatal Error: package build failed > ?==> m3-sys/m3cc done > > -- and then it keeps going -- > > === package m3-libs/m3core === > ?+++ cm3 -build > -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3' $RARGS? && cm3 -ship $RARGS -DROOT='/usr/local/hudson/.hudson/jobs/cm3-current-build-AMD64_LINUX/workspace/cm3'? > +++ That's probably due to a typo in the pkgmap script: Index: scripts/pkgmap.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/pkgmap.sh,v retrieving revision 1.58 diff -u -u -r1.58 pkgmap.sh --- scripts/pkgmap.sh 23 Jul 2010 16:08:08 -0000 1.58 +++ scripts/pkgmap.sh 4 Aug 2010 15:23:58 -0000 @@ -532,4 +532,4 @@ fi fi -[ -n "${OK}" ] || exit `printf "{$REDPKGS}" | wc | awk '{print $1}'` +[ -n "${OK}" ] || exit `printf "${REDPKGS}" | wc | awk '{print $1}'` Let me know when you see that again, 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 Aug 5 14:43:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 12:43:15 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? Message-ID: Olaf, this looks maybe like over aggressive manual cleanup on your part?? http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console S=/Volumes/maxstore1/home/hudson/workspace/cm3-current-build-PPC_DARWIN LASTREL=5.4.0 INSTROOT_REL=/Users/hudson/work/cm3-inst/apple/rel-5.4.0 INSTROOT_POK=/Users/hudson/work/cm3-inst/apple/prev-ok INSTROOT_LOK=/Users/hudson/work/cm3-inst/apple/last-ok INSTROOT_CUR=/Users/hudson/work/cm3-inst/apple/current CM3_OSTYPE=POSIX CM3_TARGET=PPC_DARWIN BINDISTMIN=/Users/hudson/work/cm3-min-POSIX-PPC_DARWIN-5.4.0.tgz CM3CVSSERVER=birch.elegosoft.com CM3CVSROOT=birch.elegosoft.com:/usr/cvs BINDISTMIN_NAME=cm3-min-POSIX-PPC_DARWIN-5.4.0.tgz BINDISTMIN=/Users/hudson/work/cm3-min-POSIX-PPC_DARWIN-5.4.0.tgz CM3CVSUSER= testing ssh birch.elegosoft.com.. ssh birch.elegosoft.com ok deleting outdated packages cache /Volumes/maxstore1/home/hudson/workspace/cm3-current-build-PPC_DARWIN/cm3/scripts/PKGS cp: /Users/hudson/work/cm3-inst/apple/last-ok: No such file or directory Finished: FAILURE ?- Jay From wagner at elegosoft.com Thu Aug 5 15:06:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 05 Aug 2010 15:06:13 +0200 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: Message-ID: <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com> Quoting Jay K : > Olaf, this looks maybe like over aggressive manual cleanup on your part?? > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console Well, kind of auto-cleanup actually :-) The external disk of that machine failed several days ago. I haven't got round to buy a new one, but tried to set up NFS access to my FreeBSD machine in a hurry this morning. That went well, but all the cm3 data are lost, so I had to install a compiler from release 5.8.6 (succeeded) and then boot the regression testing setup again (failed), see: http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console It's the gcc -m 32 issue again; I don't know yet if it's using the wrong C compiler, or something has changed in the config again, as I haven't direct access now. Maybe this evening. 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 Aug 5 15:54:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 13:54:24 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com> References: , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com> Message-ID: Ah, can you send the output of gcc -gstabs+ -fPIC -m32 -c -x c /dev/null gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null and try the updated Darwin.common? Thanks, ?- Jay ---------------------------------------- > Date: Thu, 5 Aug 2010 15:06:13 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: PPC_DARWIN failure missing last-ok? > > Quoting Jay K : > > > Olaf, this looks maybe like over aggressive manual cleanup on your part?? > > > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > > Well, kind of auto-cleanup actually :-) > > The external disk of that machine failed several days ago. I haven't > got round to buy a new one, but tried to set up NFS access to my FreeBSD > machine in a hurry this morning. That went well, but all the cm3 data > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > and then boot the regression testing setup again (failed), see: > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > C compiler, or something has changed in the config again, as I haven't > direct access now. Maybe this evening. > > 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 Aug 5 15:58:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 13:58:33 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, Message-ID: (and ssh access would help) ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Thu, 5 Aug 2010 13:54:24 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? > > > Ah, can you send the output of > > gcc -gstabs+ -fPIC -m32 -c -x c /dev/null > gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null > > and try the updated Darwin.common? > > Thanks, > - Jay > > ---------------------------------------- > > Date: Thu, 5 Aug 2010 15:06:13 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: PPC_DARWIN failure missing last-ok? > > > > Quoting Jay K : > > > > > Olaf, this looks maybe like over aggressive manual cleanup on your part?? > > > > > > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > > > > Well, kind of auto-cleanup actually :-) > > > > The external disk of that machine failed several days ago. I haven't > > got round to buy a new one, but tried to set up NFS access to my FreeBSD > > machine in a hurry this morning. That went well, but all the cm3 data > > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > > and then boot the regression testing setup again (failed), see: > > > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > > > > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > > C compiler, or something has changed in the config again, as I haven't > > direct access now. Maybe this evening. > > > > 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 Thu Aug 5 16:14:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 05 Aug 2010 16:14:15 +0200 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, Message-ID: <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com> Quoting Jay K : > (and ssh access would help) I just added your gcc lines below to the boot job; I also changed the checkout of the release branch to the trunk (maybe it will work now). The job is still running. See http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/4/console You should be able to access the machine as user hudson from birch (if you can su to hudson there) at port 223 at luthien.dyndns.org if I remember correctly. If you cannot su to hudson, I need to place your public ssh key on the machine, but cannot do that before this evening, too. As usual, only HTTP access from here. Olaf > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> Date: Thu, 5 Aug 2010 13:54:24 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? >> >> >> Ah, can you send the output of >> >> gcc -gstabs+ -fPIC -m32 -c -x c /dev/null >> gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null >> >> and try the updated Darwin.common? >> >> Thanks, >> - Jay >> >> ---------------------------------------- >> > Date: Thu, 5 Aug 2010 15:06:13 +0200 >> > From: wagner at elegosoft.com >> > To: jay.krell at cornell.edu >> > CC: m3devel at elegosoft.com >> > Subject: Re: PPC_DARWIN failure missing last-ok? >> > >> > Quoting Jay K : >> > >> > > Olaf, this looks maybe like over aggressive manual cleanup on >> your part?? >> > > >> > > >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console >> > >> > Well, kind of auto-cleanup actually :-) >> > >> > The external disk of that machine failed several days ago. I haven't >> > got round to buy a new one, but tried to set up NFS access to my FreeBSD >> > machine in a hurry this morning. That went well, but all the cm3 data >> > are lost, so I had to install a compiler from release 5.8.6 (succeeded) >> > and then boot the regression testing setup again (failed), see: >> > >> > >> http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console >> > >> > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong >> > C compiler, or something has changed in the config again, as I haven't >> > direct access now. Maybe this evening. >> > >> > 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 >> > >> > -- 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 Aug 5 16:20:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:20:23 +0000 Subject: [M3devel] linuxlibc6 crashing Message-ID: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-LINUXLIBC6/52/console cm3 is /home/hudson/work/cm3-inst/xlin2/last-ok/bin/cm3 *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 *** ./defs.sh: line 728: 14797 Aborted cm3 -version *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 *** >>> test_m3tests error extract: /usr/bin/find: `LINUXLIBC6': No such file or directory >>> OK test_m3tests 2010-08-05-14-07-28 /home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6 === 2010-08-05 14:07:31 cm3 m3tests run done cp: cannot stat `/home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6/cm3/m3-sys/m3tests/m3tests.html': No such file or directory I'm aware, not sure what the problem is, not sure it is widespread. Seems kind of like struct stat overflow..and the recent change from stat to lstat, but really..seems corect as well... Might have to intervene manually..but I don't know what the fix is yet. ?- Jay From jay.krell at cornell.edu Thu Aug 5 16:19:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:19:13 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com> References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, , , <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com> Message-ID: Cool. I think manually updating the config might be required. We'll see. I'm going to have reduced hours here for about 10 days soon.. Thanks, ?- Jay ---------------------------------------- > Date: Thu, 5 Aug 2010 16:14:15 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] PPC_DARWIN failure missing last-ok? > > Quoting Jay K : > > > (and ssh access would help) > > I just added your gcc lines below to the boot job; I also changed > the checkout of the release branch to the trunk (maybe it will work > now). The job is still running. See > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/4/console > > You should be able to access the machine as user hudson from birch > (if you can su to hudson there) at port 223 at luthien.dyndns.org > if I remember correctly. > > If you cannot su to hudson, I need to place your public ssh key on > the machine, but cannot do that before this evening, too. As usual, > only HTTP access from here. > > Olaf > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: wagner at elegosoft.com > >> Date: Thu, 5 Aug 2010 13:54:24 +0000 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? > >> > >> > >> Ah, can you send the output of > >> > >> gcc -gstabs+ -fPIC -m32 -c -x c /dev/null > >> gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null > >> > >> and try the updated Darwin.common? > >> > >> Thanks, > >> - Jay > >> > >> ---------------------------------------- > >> > Date: Thu, 5 Aug 2010 15:06:13 +0200 > >> > From: wagner at elegosoft.com > >> > To: jay.krell at cornell.edu > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: PPC_DARWIN failure missing last-ok? > >> > > >> > Quoting Jay K : > >> > > >> > > Olaf, this looks maybe like over aggressive manual cleanup on > >> your part?? > >> > > > >> > > > >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > >> > > >> > Well, kind of auto-cleanup actually :-) > >> > > >> > The external disk of that machine failed several days ago. I haven't > >> > got round to buy a new one, but tried to set up NFS access to my FreeBSD > >> > machine in a hurry this morning. That went well, but all the cm3 data > >> > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > >> > and then boot the regression testing setup again (failed), see: > >> > > >> > > >> http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > >> > > >> > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > >> > C compiler, or something has changed in the config again, as I haven't > >> > direct access now. Maybe this evening. > >> > > >> > 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 > >> > > >> > > > > > > -- > 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 Aug 5 16:41:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:41:37 +0000 Subject: [M3devel] PPC_DARWIN failure missing last-ok? In-Reply-To: References: , , <20100805150613.epz7aikp44wc8w0c@mail.elegosoft.com>, , , <20100805161415.c2fc7ve5ckw008gk@mail.elegosoft.com>, Message-ID: ok I manually fixed it up. pwd /Users/hudson/work/cm3-inst/apple/rel-5.8.6/bin/config mv Darwin.common Darwin.common.1 vi Darwin.common diff Darwin.common.1 Darwin.common Something like: released 5.8.6 doesn't work on PPC_DARWIN 10.3, needs slight config edit. Fixed perhaps in head. We'll see. gcc_select 4.0 as root would fix it. Given that -arch is supported, probably no point to -m32/64. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] PPC_DARWIN failure missing last-ok? > Date: Thu, 5 Aug 2010 14:19:13 +0000 > > > Cool. I think manually updating the config might be required. We'll see. > I'm going to have reduced hours here for about 10 days soon.. > > Thanks, > - Jay > > ---------------------------------------- > > Date: Thu, 5 Aug 2010 16:14:15 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] PPC_DARWIN failure missing last-ok? > > > > Quoting Jay K : > > > > > (and ssh access would help) > > > > I just added your gcc lines below to the boot job; I also changed > > the checkout of the release branch to the trunk (maybe it will work > > now). The job is still running. See > > > > http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/4/console > > > > You should be able to access the machine as user hudson from birch > > (if you can su to hudson there) at port 223 at luthien.dyndns.org > > if I remember correctly. > > > > If you cannot su to hudson, I need to place your public ssh key on > > the machine, but cannot do that before this evening, too. As usual, > > only HTTP access from here. > > > > Olaf > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: wagner at elegosoft.com > > >> Date: Thu, 5 Aug 2010 13:54:24 +0000 > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] PPC_DARWIN failure missing last-ok? > > >> > > >> > > >> Ah, can you send the output of > > >> > > >> gcc -gstabs+ -fPIC -m32 -c -x c /dev/null > > >> gcc -gstabs+ -fPIC -arch ppc -c -x c /dev/null > > >> > > >> and try the updated Darwin.common? > > >> > > >> Thanks, > > >> - Jay > > >> > > >> ---------------------------------------- > > >> > Date: Thu, 5 Aug 2010 15:06:13 +0200 > > >> > From: wagner at elegosoft.com > > >> > To: jay.krell at cornell.edu > > >> > CC: m3devel at elegosoft.com > > >> > Subject: Re: PPC_DARWIN failure missing last-ok? > > >> > > > >> > Quoting Jay K : > > >> > > > >> > > Olaf, this looks maybe like over aggressive manual cleanup on > > >> your part?? > > >> > > > > >> > > > > >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_DARWIN/36/console > > >> > > > >> > Well, kind of auto-cleanup actually :-) > > >> > > > >> > The external disk of that machine failed several days ago. I haven't > > >> > got round to buy a new one, but tried to set up NFS access to my FreeBSD > > >> > machine in a hurry this morning. That went well, but all the cm3 data > > >> > are lost, so I had to install a compiler from release 5.8.6 (succeeded) > > >> > and then boot the regression testing setup again (failed), see: > > >> > > > >> > > > >> http://hudson.modula3.com:8080/view/PPC_DARWIN/job/boot-PPC_DARWIN/1/console > > >> > > > >> > It's the gcc -m 32 issue again; I don't know yet if it's using the wrong > > >> > C compiler, or something has changed in the config again, as I haven't > > >> > direct access now. Maybe this evening. > > >> > > > >> > 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 > > >> > > > >> > > > > > > > > > > > -- > > 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 Aug 5 16:48:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 5 Aug 2010 14:48:08 +0000 Subject: [M3devel] linuxlibc6 crashing In-Reply-To: References: Message-ID: (manual intervention) I cross built cm3 and copied that over the crashing one. We'll see. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Thu, 5 Aug 2010 14:20:23 +0000 > Subject: [M3devel] linuxlibc6 crashing > > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-LINUXLIBC6/52/console > > cm3 is /home/hudson/work/cm3-inst/xlin2/last-ok/bin/cm3 > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > *** > > ./defs.sh: line 728: 14797 Aborted cm3 -version > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > *** > > >>> test_m3tests error extract: > /usr/bin/find: `LINUXLIBC6': No such file or directory > >>> OK test_m3tests 2010-08-05-14-07-28 /home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6 > === 2010-08-05 14:07:31 cm3 m3tests run done > cp: cannot stat `/home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6/cm3/m3-sys/m3tests/m3tests.html': No such file or directory > > > I'm aware, not sure what the problem is, not sure it is widespread. > > Seems kind of like struct stat overflow..and the recent change from stat to lstat, but really..seems corect as well... > Might have to intervene manually..but I don't know what the fix is yet. > > - Jay > > > > > From jay.krell at cornell.edu Fri Aug 6 11:23:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 6 Aug 2010 09:23:16 +0000 Subject: [M3devel] Hudson/PPC_DARWIN Message-ID: http://hudson.modula3.com:8080/job/cm3-current-m3cc-PPC_DARWIN/19/console config.status: linking ../../gcc/gmp/mpn/generic/gmp-mparam.h to gmp-mparam.h make[1]: Entering directory `/Volumes/luthien/home/hudson2/workspace/cm3-m3cc-PPC_DARWIN/cm3/m3-sys/m3cc/PPC_DARWIN/gmp' gcc `test -f 'gen-fac_ui.c' || echo '../../gcc/gmp/'`gen-fac_ui.c -o gen-fac_ui /var/tmp//ccZolN95.s:unknown:FATAL:can't write output file $TMPDIR not placed well? ? - Jay From jay.krell at cornell.edu Fri Aug 6 11:24:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 6 Aug 2010 09:24:36 +0000 Subject: [M3devel] Hudson/NT386 Message-ID: NT386 node offline? Then again, it is in good shape: http://hudson.modula3.com:8080/job/cm3-current-build-NT386/25/console still need to clean this up: P m3-sys/cminstall/src/config-no-install/MIPS64EL_OPENBSD cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' on a few machines. ?- Jay From wagner at elegosoft.com Fri Aug 6 12:04:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 06 Aug 2010 12:04:59 +0200 Subject: [M3devel] Hudson/PPC_DARWIN In-Reply-To: References: Message-ID: <20100806120459.edxuddkg000sksos@mail.elegosoft.com> Quoting Jay K : > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-PPC_DARWIN/19/console > > config.status: linking ../../gcc/gmp/mpn/generic/gmp-mparam.h to gmp-mparam.h > make[1]: Entering directory > `/Volumes/luthien/home/hudson2/workspace/cm3-m3cc-PPC_DARWIN/cm3/m3-sys/m3cc/PPC_DARWIN/gmp' > gcc `test -f 'gen-fac_ui.c' || echo '../../gcc/gmp/'`gen-fac_ui.c -o > gen-fac_ui > /var/tmp//ccZolN95.s:unknown:FATAL:can't write output file > > > $TMPDIR not placed well? No, Hudson had a wrong root path configured, which was now accidentally on the root disk with the external mount missing, so it didn't really use the space on the NFS. I've fixed it now. 1.5 GB are free again on root and should stay so. 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 Aug 6 12:11:01 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 06 Aug 2010 12:11:01 +0200 Subject: [M3devel] Hudson/NT386 In-Reply-To: References: Message-ID: <20100806121101.ikn8jhkxs0cgo088@mail.elegosoft.com> Quoting Jay K : > NT386 node offline? The connection to this machine is still unstable, it goes offline whenever I turn my eyes. I'm afraid Elego won't be able to provide something better here, so other resources for continous integration on Windows would still be welcome. 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 Fri Aug 6 12:20:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 6 Aug 2010 10:20:07 +0000 Subject: [M3devel] hudson nodes Message-ID: most/all of my Hudson nodes will be down August 6 - 15. I'll probably leave just Linux/x86. They will all be back late August 15. - Jay From jay.krell at cornell.edu Sat Aug 7 08:21:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 06:21:44 +0000 Subject: [M3devel] Hudson/CVS/Tag release Message-ID: We should delete these checkouts/workspaces to remove any doubt about targeting head? (just the last two, mainly, but the timestamps being back in July is a bit off) I was looking into the: cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' stuff, which I've been cleaning up just by deleting. % ls -l? */cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21? 7 Aug 08:03 cm3-current-build-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21 18 Jul 22:46 cm3-current-m3cc-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21? 6 Aug 20:40 cm3-current-test-all-pkgs-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 21 19 Jul 23:28 cm3-current-test-m3tests-FreeBSD4/cm3/CVS/Tag -rw-rw-r--? 1 hudson? Ghudson? 19? 8 Jul 17:34 cm3-makedist-FreeBSD4/cm3/CVS/Tag -rw-rw----? 1 hudson? Ghudson? 24? 9 Jul 12:22 cm3-test-all-pkgs-FreeBSD4/cm3/CVS/Tag new.elego.de [~/workspace] hudson % cat */cm3/CVS/Tag D2010.08.07.05.59.47 D2010.07.18.20.45.58 D2010.08.06.18.37.22 D2010.07.19.21.28.10 Nrelease_CM3_5_8_6 Trelease_branch_cm3_5_8 new.elego.de [~/workspace] hudson % hostname new.elego.de new.elego.de [~/workspace] hudson % pwd /pub/users/hudson/workspace new.elego.de [~/workspace] hudson % uname -a FreeBSD new.elego.de 6.4-RELEASE-p5 FreeBSD 6.4-RELEASE-p5 #1: Sun Jun 14 14:03:37 CEST 2009???? root at new.elego.de:/usr/obj/usr/src/sys/GENERIC? i386 new.elego.de [~/workspace] hudson From jay.krell at cornell.edu Sat Aug 7 08:27:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 06:27:07 +0000 Subject: [M3devel] linuxlibc6 crashing In-Reply-To: References: , Message-ID: same thing here: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/15/consoleFull but it went away: ? http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/16/consoleFull ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] linuxlibc6 crashing > Date: Thu, 5 Aug 2010 14:48:08 +0000 > > > (manual intervention) > I cross built cm3 and copied that over the crashing one. We'll see. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Thu, 5 Aug 2010 14:20:23 +0000 > > Subject: [M3devel] linuxlibc6 crashing > > > > > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-LINUXLIBC6/52/console > > > > cm3 is /home/hudson/work/cm3-inst/xlin2/last-ok/bin/cm3 > > > > > > *** > > *** runtime error: > > *** Segmentation violation - possible attempt to dereference NIL > > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > > *** > > > > ./defs.sh: line 728: 14797 Aborted cm3 -version > > > > > > *** > > *** runtime error: > > *** Segmentation violation - possible attempt to dereference NIL > > *** pc = 0x80f11e6 = TryConfig + 0x150 in ../src/MxConfig.m3 > > *** > > > > >>> test_m3tests error extract: > > /usr/bin/find: `LINUXLIBC6': No such file or directory > > >>> OK test_m3tests 2010-08-05-14-07-28 /home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6 > > === 2010-08-05 14:07:31 cm3 m3tests run done > > cp: cannot stat `/home/hudson/workspace/cm3-current-test-m3tests-LINUXLIBC6/cm3/m3-sys/m3tests/m3tests.html': No such file or directory > > > > > > I'm aware, not sure what the problem is, not sure it is widespread. > > > > Seems kind of like struct stat overflow..and the recent change from stat to lstat, but really..seems corect as well... > > Might have to intervene manually..but I don't know what the fix is yet. > > > > - Jay > > > > > > > > > > > From wagner at elegosoft.com Sat Aug 7 09:05:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 07 Aug 2010 09:05:26 +0200 Subject: [M3devel] Hudson/CVS/Tag release In-Reply-To: References: Message-ID: <20100807090526.9a6odj4lwsowkc8s@mail.elegosoft.com> Quoting Jay K : > We should delete these checkouts/workspaces to remove any doubt > about targeting head? The last 2 were last used to build on the release branch. Those for the trunk all have the -current- in the name. You may remove them if you need space. The last contains some HTML results that might be worth to preserve though. Why is there any doubt which jobs follow head and which don't? Olaf > (just the last two, mainly, but the timestamps being back in July is > a bit off) > I was looking into the: > > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for > `m3-sys/m3cc/gcc/fixincludes' > > stuff, which I've been cleaning up just by deleting. > > % ls -l? */cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21? 7 Aug 08:03 > cm3-current-build-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21 18 Jul 22:46 > cm3-current-m3cc-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21? 6 Aug 20:40 > cm3-current-test-all-pkgs-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 21 19 Jul 23:28 > cm3-current-test-m3tests-FreeBSD4/cm3/CVS/Tag > -rw-rw-r--? 1 hudson? Ghudson? 19? 8 Jul 17:34 > cm3-makedist-FreeBSD4/cm3/CVS/Tag > -rw-rw----? 1 hudson? Ghudson? 24? 9 Jul 12:22 > cm3-test-all-pkgs-FreeBSD4/cm3/CVS/Tag > new.elego.de [~/workspace] hudson > % cat */cm3/CVS/Tag > D2010.08.07.05.59.47 > D2010.07.18.20.45.58 > D2010.08.06.18.37.22 > D2010.07.19.21.28.10 > Nrelease_CM3_5_8_6 > Trelease_branch_cm3_5_8 > new.elego.de [~/workspace] hudson > % hostname > new.elego.de > new.elego.de [~/workspace] hudson > % pwd > /pub/users/hudson/workspace > new.elego.de [~/workspace] hudson > % uname -a > FreeBSD new.elego.de 6.4-RELEASE-p5 FreeBSD 6.4-RELEASE-p5 #1: Sun > Jun 14 14:03:37 CEST 2009???? > root at new.elego.de:/usr/obj/usr/src/sys/GENERIC? i386 > new.elego.de [~/workspace] hudson > > -- 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 Sat Aug 7 16:30:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 14:30:19 +0000 Subject: [M3devel] more Hudson nodes? more help in general? Message-ID: Hey, I'm hoping we can get more people helping more. Coding, features, fixing bugs, etc. However one of the easiest things I'd like to see is a few more Hudson nodes. Is anyone out there running e.g. NetBSD on x86 or AMD64? ? They would be the easiest, sort of, to setup. I will help anyone. ? Or Solaris on SPARC (replace mine) or x86? (Yes I know about opencsw, but the network ? topology is seemingly difficult.) Or heck, Linux or OpenBSD on x86? (replace mine) x86/AMD64 in particular has better availability of Java VMs, which we need. Or, Linux now has good across the board Java support. And can setup dynamic DNS or has static IP? We could use NT386 but I know the setup might not be so easy. There are other viable machines, e.g. one of the new or old Linux/mips. Or likely some of the obscure systems like HP-UX, AIX, Irix. If anyone here is actively running one of these, keeps machine on, speak up. (At some point, I'd like to have Hudson wake-on-lan the machines, or have the machines scheduled to wake up daily check for work, and then back to sleep after completing any queued work; the second option doesn't require Hudson support.) The machine can be quite low end. Many of mine are old laptops, or very old either way. Around $200, years ago. Any other projects in the system people are interested in helping out on, with ? time/coding, please speak up if you need help. If you need ideas, or assistance, etc. Thanks, ?- Jay From jay.krell at cornell.edu Sat Aug 7 16:53:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 14:53:12 +0000 Subject: [M3devel] build_platform in archive names In-Reply-To: <20100807105849.2B48724740EC@birch.elegosoft.com> References: <20100807105849.2B48724740EC@birch.elegosoft.com> Message-ID: Thanks! I want something slightly different for NT platforms. NT doesn't have the binary incompatibility and cross-build problem of Unix, at the OS level. ? (and commercial Unix isn't so bad either I think these days) However it does sort of have it at the C runtime level. i.e. There is no need to say e.g. XP/Vista/Win7/NT5.1/6.0/6.1, but there is a need to say e.g. msvc70/71/80/90/100. And there probably is a need for Cygwin-1.5 vs. Cygwin-1.7 (ie. exactly what you have). You can see in pylib.py: def FormInstallRoot(PackageSetName): ??? AltConfig = {"NT386":"x86"}.get(Config, Config) ??? a = os.path.join(GetStage(), "cm3-" + PackageSetName + "-" + AltConfig + "-" + CM3VERSION) ??? if Config == "NT386" or Config == "I386_NT": ??????? a = a + "-VC" + GetVisualCPlusPlusVersion() ??? else: ??????? b = os.popen("uname -sr").read() ??????? b = re.sub("Linux 2.4\..+$", "Linux2.4", b) ??????? b = re.sub("Linux 2.6\..+$", "", b) ??????? b = re.sub("-.+$", "", b) ??????? b = re.sub("SunOS", "Solaris", b) ??????? b = re.sub("[ \r\n]", "", b) ??????? a = a + "-" + b ??? a = a + "-" + time.strftime("%Y%m%d") ??? return a uname -p redundant with $(TARGET), er..the other way around.. config.guess/uname maybe is the preferable way. I guess that's a bigger leap right now, and it isn't entirely true, e.g. on "biarch" systems, e.g. AMD64_{DARWIN,SOLARIS}, SPARC64_SOLARIS, PPC64_DARWIN, etc.. def GetVisualCPlusPlusVersion(): ??? a = os.popen("cl 2>&1 >nul").read().lower() ??? if a.find("9.00") != -1: ??????? return "20" ??? if a.find("10.00") != -1: ??????? return "40" ??? if a.find("10.10") != -1: ??????? return "41" ??? if a.find("10.20") != -1: ??????? return "42" ??? if a.find("11.00") != -1: ??????? return "50" ??? if a.find("12.00") != -1: ??????? return "60" ??? if a.find("13.00") != -1: ??????? return "70" ??? if a.find("13.10") != -1: ??????? return "71" ??? if a.find("14.00") != -1: ??????? return "80" ??? if a.find("15.00") != -1: ??????? return "90" ??? if a.find("16.00") != -1: ??????? return "100" ??? FatalError("unable to detect Visual C++ version, maybe cl is not in %PATH%?") but I'm just talking..need to try to work it in to your *.sh. ?- Jay ---------------------------------------- > Date: Sat, 7 Aug 2010 12:58:48 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 10/08/07 12:58:48 > > Modified files: > cm3/scripts/: make-bin-dist-min.sh make-dist.sh sysinfo.sh > cm3/scripts/regression/: update_snapshot_status.sh > > Log message: > fix snapshot support and add build_platform > From wagner at elegosoft.com Sat Aug 7 16:59:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 07 Aug 2010 16:59:43 +0200 Subject: [M3devel] build_platform in archive names In-Reply-To: References: <20100807105849.2B48724740EC@birch.elegosoft.com> Message-ID: <20100807165943.ygl506lqo80kokok@mail.elegosoft.com> I've left out Windows, because I wasn't sure what exactly was needed there. Feel free to add an appropriate string for all Windows-based target platforms! Olaf Quoting Jay K : > Thanks! > I want something slightly different for NT platforms. > NT doesn't have the binary incompatibility and cross-build problem > of Unix, at the OS level. > ? (and commercial Unix isn't so bad either I think these days) > However it does sort of have it at the C runtime level. > i.e. There is no need to say e.g. XP/Vista/Win7/NT5.1/6.0/6.1, but > there is a need to say e.g. msvc70/71/80/90/100. > And there probably is a need for Cygwin-1.5 vs. Cygwin-1.7 (ie. > exactly what you have). > > You can see in pylib.py: > > def FormInstallRoot(PackageSetName): > ??? AltConfig = {"NT386":"x86"}.get(Config, Config) > ??? a = os.path.join(GetStage(), "cm3-" + PackageSetName + "-" + > AltConfig + "-" + CM3VERSION) > ??? if Config == "NT386" or Config == "I386_NT": > ??????? a = a + "-VC" + GetVisualCPlusPlusVersion() > ??? else: > ??????? b = os.popen("uname -sr").read() > ??????? b = re.sub("Linux 2.4\..+$", "Linux2.4", b) > ??????? b = re.sub("Linux 2.6\..+$", "", b) > ??????? b = re.sub("-.+$", "", b) > ??????? b = re.sub("SunOS", "Solaris", b) > ??????? b = re.sub("[ \r\n]", "", b) > ??????? a = a + "-" + b > ??? a = a + "-" + time.strftime("%Y%m%d") > ??? return a > > > uname -p redundant with $(TARGET), er..the other way around.. > config.guess/uname maybe is the preferable way. > I guess that's a bigger leap right now, and it isn't entirely true, > e.g. on "biarch" systems, e.g. AMD64_{DARWIN,SOLARIS}, > SPARC64_SOLARIS, PPC64_DARWIN, etc.. > > > def GetVisualCPlusPlusVersion(): > ??? a = os.popen("cl 2>&1 >nul").read().lower() > ??? if a.find("9.00") != -1: > ??????? return "20" > ??? if a.find("10.00") != -1: > ??????? return "40" > ??? if a.find("10.10") != -1: > ??????? return "41" > ??? if a.find("10.20") != -1: > ??????? return "42" > ??? if a.find("11.00") != -1: > ??????? return "50" > ??? if a.find("12.00") != -1: > ??????? return "60" > ??? if a.find("13.00") != -1: > ??????? return "70" > ??? if a.find("13.10") != -1: > ??????? return "71" > ??? if a.find("14.00") != -1: > ??????? return "80" > ??? if a.find("15.00") != -1: > ??????? return "90" > ??? if a.find("16.00") != -1: > ??????? return "100" > ??? FatalError("unable to detect Visual C++ version, maybe cl is not > in %PATH%?") > > > but I'm just talking..need to try to work it in to your *.sh. > > > ?- Jay > > ---------------------------------------- >> Date: Sat, 7 Aug 2010 12:58:48 +0000 >> To: m3commit at elegosoft.com >> From: wagner at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: wagner at birch. 10/08/07 12:58:48 >> >> Modified files: >> cm3/scripts/: make-bin-dist-min.sh make-dist.sh sysinfo.sh >> cm3/scripts/regression/: update_snapshot_status.sh >> >> Log message: >> fix snapshot support and add build_platform >> > -- 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 Sat Aug 7 21:51:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 19:51:26 +0000 Subject: [M3devel] elego compact In-Reply-To: <20100807161924.5CA4924740DC@birch.elegosoft.com> References: <20100807161924.5CA4924740DC@birch.elegosoft.com> Message-ID: Cool. Notice the derived files (directory AMD64_FREEBSD) got imported. - Jay ---------------------------------------- > Date: Sat, 7 Aug 2010 18:19:23 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 10/08/07 18:19:23 > > cm3/elego > > Update of /usr/cvs/cm3/elego > In directory birch:/tmp/cvs-serv13035 > > Log Message: > Stripped-down version of Elego ComPact; software developed and used > at Elego years ago. I put it under the same copyright as the other > Modula-3 sources from DEC and Critical Mass. > > Included is package version management based on CVS and build and > version management for sets of packages, called `project management' > in ComPact. > > Not included is the general package manager for C/C++/Java/M3, and the > ComPact GUI. > > It is contributed in the hope that it may be useful in whole or parts > for the CM3 project or any other users. > > The command line interface consists of the programs pkgvm and prjm, > which include complete manuals as well as short usage help: > > pkgvm -help | -man > prjm -help | -man > > The sources have been successfully compiled with a current cm3 (d5.9.0) > by prjm with > > prjm -D ROOT=$HOME/work/cm3 -buildglobal > > The project definition is contained in the file elego/PrjDesc. > > To compile everything with the CM3 srcipts, use > > ~/work/cm3/scripts/do-pkg.sh buildship langutils graphicutils tuple depgraph miniscan fsfind fileinfo filepool pkgversions compact-copyright rsrcservice compact-client compactrc pkg_base pkg_vc m3makefile m3dep m3dir m3err m3msh m3ovr pkgvm prjbase prjm > > Several things may still be wrong and need to be adapted for use with > the current CM3, but the ComPact tools should be quite flexible and > configurable. > > As all free software, this comes without any guarantee that it will > be useful in any way. Use at your own risk. > > Olaf Wagner / Elego Software Solutions GmbH, Berlin, Germany, 2010-08-07 > > > Status: > > Vendor Tag: elego-compact-free-1-0 > Release Tags: rel-compact-free-1-0 > > N cm3/elego/DepGraph > N cm3/elego/quake.elego > N cm3/elego/PrjDesc > N cm3/elego/srcs > N cm3/elego/compact-copyright/PkgTags > N cm3/elego/compact-copyright/PkgErr > N cm3/elego/compact-copyright/src/Copyright.m3 > N cm3/elego/compact-copyright/src/Release.m3 > N cm3/elego/compact-copyright/src/m3overrides > N cm3/elego/compact-copyright/src/ProgramVersion.i3 > N cm3/elego/compact-copyright/src/Version.i3 > N cm3/elego/compact-copyright/src/Release.i3 > N cm3/elego/compact-copyright/src/compact-copyrights.txt > N cm3/elego/compact-copyright/src/m3makefile > N cm3/elego/compact-copyright/src/Copyright.i3 > N cm3/elego/compact-copyright/src/ProgramVersion.m3 > N cm3/elego/compact-copyright/src/get-licences > N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.io > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.io > N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.so.5 > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.i3 > N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.io > N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3SHIP > N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.mo > N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.m3x > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.m3 > N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.mo > N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3WEB > N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.mo > N cm3/elego/filepool/PkgTags > N cm3/elego/filepool/PkgErr > N cm3/elego/filepool/src/m3overrides > N cm3/elego/filepool/src/FilePool.m3 > N cm3/elego/filepool/src/m3makefile > N cm3/elego/filepool/src/FilePool.i3 > N cm3/elego/filepool/test/src/Main.m3 > N cm3/elego/filepool/test/src/m3makefile > N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.so.5 > N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.m3x > N cm3/elego/filepool/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/filepool/AMD64_FREEBSD/.M3SHIP > N cm3/elego/filepool/AMD64_FREEBSD/FilePool.io > N cm3/elego/filepool/AMD64_FREEBSD/.M3WEB > N cm3/elego/filepool/AMD64_FREEBSD/FilePool.mo > N cm3/elego/m3err/PkgTags > N cm3/elego/m3err/m3err.gmon > N cm3/elego/m3err/PkgErr > N cm3/elego/m3err/src/m3overrides > N cm3/elego/m3err/src/m3err.m3 > N cm3/elego/m3err/src/m3makefile > N cm3/elego/m3err/AMD64_FREEBSD/m3err > N cm3/elego/m3err/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3err/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3err/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3err/AMD64_FREEBSD/m3err.mo > N cm3/elego/m3err/AMD64_FREEBSD/m3err.mx > N cm3/elego/m3err/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3err/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3err/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3err/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3err/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3err/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3err/AMD64_FREEBSD/Creation.io > N cm3/elego/prjbase/PkgTags > N cm3/elego/prjbase/PkgErr > N cm3/elego/prjbase/snaps/snaps.idx > N cm3/elego/prjbase/src/PrjDesc.i3 > N cm3/elego/prjbase/src/ChangeSet.i3 > N cm3/elego/prjbase/src/Checkpoint.i3 > N cm3/elego/prjbase/src/PrjDesc.m3 > N cm3/elego/prjbase/src/Snapshots.i3 > N cm3/elego/prjbase/src/Snapshots.m3 > N cm3/elego/prjbase/src/ChangeSet.m3 > N cm3/elego/prjbase/src/m3overrides > N cm3/elego/prjbase/src/RCS_Date.i3 > N cm3/elego/prjbase/src/PoolSet.i3 > N cm3/elego/prjbase/src/RCS_Date.m3 > N cm3/elego/prjbase/src/PoolSet.m3 > N cm3/elego/prjbase/src/Checkpoint.m3 > N cm3/elego/prjbase/src/rcsdate.patch > N cm3/elego/prjbase/src/m3makefile > N cm3/elego/prjbase/src/m3browser.html > N cm3/elego/prjbase/test/src/PrjDesc1 > N cm3/elego/prjbase/test/src/PrjDesc2 > N cm3/elego/prjbase/test/src/Main.m3 > N cm3/elego/prjbase/test/src/m3makefile > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.io > N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.mo > N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.io > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.m3x > N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.io > N cm3/elego/prjbase/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/.M3SHIP > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.so.5 > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.io > N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/.M3WEB > N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.m3 > N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.io > N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.mo > N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.i3 > N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.io > N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.i3 > N cm3/elego/tuple/PkgTags > N cm3/elego/tuple/PkgErr > N cm3/elego/tuple/src/TextTuple.m3 > N cm3/elego/tuple/src/TextTuple.i3 > N cm3/elego/tuple/src/Dummy.i3 > N cm3/elego/tuple/src/m3overrides > N cm3/elego/tuple/src/Tuple.mg > N cm3/elego/tuple/src/Tuple.ig > N cm3/elego/tuple/src/m3makefile > N cm3/elego/tuple/src/Dummy.m3 > N cm3/elego/tuple/src/HeteroTuple.mg > N cm3/elego/tuple/src/HeteroTuple.ig > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.i3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.io > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.io > N cm3/elego/tuple/AMD64_FREEBSD/libtuple.so.5 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.i3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.io > N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.mo > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.mo > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.i3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.mo > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.io > N cm3/elego/tuple/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/tuple/AMD64_FREEBSD/.M3SHIP > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.io > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.m3 > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.m3 > N cm3/elego/tuple/AMD64_FREEBSD/.M3WEB > N cm3/elego/tuple/AMD64_FREEBSD/libtuple.m3x > N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.i3 > N cm3/elego/langutils/PkgTags > N cm3/elego/langutils/PkgErr > N cm3/elego/langutils/src/m3overrides > N cm3/elego/langutils/src/SimpleValueEnv.m3 > N cm3/elego/langutils/src/SimpleValueEnv.i3 > N cm3/elego/langutils/src/m3makefile > N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.m3x > N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.mo > N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.so.5 > N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.io > N cm3/elego/langutils/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/langutils/AMD64_FREEBSD/.M3SHIP > N cm3/elego/langutils/AMD64_FREEBSD/.M3WEB > N cm3/elego/prjm/PkgTags > N cm3/elego/prjm/PrjDesc > N cm3/elego/prjm/stat > N cm3/elego/prjm/PkgErr > N cm3/elego/prjm/src/m3overrides > N cm3/elego/prjm/src/Copyright > N cm3/elego/prjm/src/PrjmGUI.fv > N cm3/elego/prjm/src/m3makefile > N cm3/elego/prjm/src/ProjectManager.m3 > N cm3/elego/prjm/src/ShortUsageHelp > N cm3/elego/prjm/src/UsageHelp > N cm3/elego/prjm/src/compactrc > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.io > N cm3/elego/prjm/AMD64_FREEBSD/prjm.mx > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.i3 > N cm3/elego/prjm/AMD64_FREEBSD/_m3main.mc > N cm3/elego/prjm/AMD64_FREEBSD/Creation.i3 > N cm3/elego/prjm/AMD64_FREEBSD/prjm > N cm3/elego/prjm/AMD64_FREEBSD/Creation.m3 > N cm3/elego/prjm/AMD64_FREEBSD/Creation.mo > N cm3/elego/prjm/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/prjm/AMD64_FREEBSD/.M3SHIP > N cm3/elego/prjm/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManager.mo > N cm3/elego/prjm/AMD64_FREEBSD/.M3WEB > N cm3/elego/prjm/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.mo > N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.m3 > N cm3/elego/prjm/AMD64_FREEBSD/Creation.io > N cm3/elego/pkg_vc/PkgTags > N cm3/elego/pkg_vc/TODO > N cm3/elego/pkg_vc/PkgDesc > N cm3/elego/pkg_vc/PkgErr > N cm3/elego/pkg_vc/src/PkgVC.i3 > N cm3/elego/pkg_vc/src/CVS.i3 > N cm3/elego/pkg_vc/src/FileRevision.i3 > N cm3/elego/pkg_vc/src/m3overrides > N cm3/elego/pkg_vc/src/FileObj.i3 > N cm3/elego/pkg_vc/src/ProcessPosixOS2.m3 > N cm3/elego/pkg_vc/src/PkgVCUtils.m3 > N cm3/elego/pkg_vc/src/VCIF.i3 > N cm3/elego/pkg_vc/src/OpResultCache.m3 > N cm3/elego/pkg_vc/src/VCUtils.i3 > N cm3/elego/pkg_vc/src/gnats-commit-check.sh > N cm3/elego/pkg_vc/src/Process2.i3 > N cm3/elego/pkg_vc/src/PkgVCUtils.i3 > N cm3/elego/pkg_vc/src/m3makefile > N cm3/elego/pkg_vc/src/FileObj.m3 > N cm3/elego/pkg_vc/src/PkgVC.m3 > N cm3/elego/pkg_vc/src/VCUtils.m3 > N cm3/elego/pkg_vc/src/CVS_st.m3 > N cm3/elego/pkg_vc/src/CVSLockInfo.i3 > N cm3/elego/pkg_vc/src/OpResultCache.i3 > N cm3/elego/pkg_vc/tests/src/m3overrides > N cm3/elego/pkg_vc/tests/src/Main.m3 > N cm3/elego/pkg_vc/tests/src/m3makefile > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.m3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/VCIF.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.m3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS_st.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.so.5 > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfo.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.m3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.m3x > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevision.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.i3 > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.io > N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.mo > N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS.io > N cm3/elego/m3ovr/PkgTags > N cm3/elego/m3ovr/PkgErr > N cm3/elego/m3ovr/src/m3overrides > N cm3/elego/m3ovr/src/Main.m3 > N cm3/elego/m3ovr/src/m3makefile > N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr.mx > N cm3/elego/m3ovr/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3ovr/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3ovr/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3ovr/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.io > N cm3/elego/m3ovr/AMD64_FREEBSD/Main.mo > N cm3/elego/compact-client/PkgTags > N cm3/elego/compact-client/PkgErr > N cm3/elego/compact-client/src/m3overrides > N cm3/elego/compact-client/src/CompactClient.m3 > N cm3/elego/compact-client/src/m3makefile > N cm3/elego/compact-client/src/CompactClient.i3 > N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.so.5 > N cm3/elego/compact-client/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/compact-client/AMD64_FREEBSD/.M3SHIP > N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.mo > N cm3/elego/compact-client/AMD64_FREEBSD/.M3WEB > N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.m3x > N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.io > N cm3/elego/fileinfo/PkgTags > N cm3/elego/fileinfo/PkgErr > N cm3/elego/fileinfo/src/FileDir.m3 > N cm3/elego/fileinfo/src/FileStatus.i3 > N cm3/elego/fileinfo/src/DirTree.m3 > N cm3/elego/fileinfo/src/Dummy.i3 > N cm3/elego/fileinfo/src/FileStamp.i3 > N cm3/elego/fileinfo/src/m3overrides > N cm3/elego/fileinfo/src/DirTree.i3 > N cm3/elego/fileinfo/src/APN.i3 > N cm3/elego/fileinfo/src/FileDir.i3 > N cm3/elego/fileinfo/src/FileInfo.i3 > N cm3/elego/fileinfo/src/PathnameStatusTable.i3 > N cm3/elego/fileinfo/src/FileStatus.m3 > N cm3/elego/fileinfo/src/m3makefile > N cm3/elego/fileinfo/src/Dummy.m3 > N cm3/elego/fileinfo/src/FileSystem.m3 > N cm3/elego/fileinfo/src/FileSystem.i3 > N cm3/elego/fileinfo/src/PathnameStatusTable.m3 > N cm3/elego/fileinfo/src/FileInfo.m3 > N cm3/elego/fileinfo/src/APN.m3 > N cm3/elego/fileinfo/src/TreeStamp.i3 > N cm3/elego/fileinfo/src/FileStamp.m3 > N cm3/elego/fileinfo/tests/PkgTags > N cm3/elego/fileinfo/tests/src/m3overrides > N cm3/elego/fileinfo/tests/src/Main.m3 > N cm3/elego/fileinfo/tests/src/m3makefile > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.io > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.m3x > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.so.5 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.io > N cm3/elego/fileinfo/AMD64_FREEBSD/APN.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.io > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/.M3SHIP > N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APN.io > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.io > N cm3/elego/fileinfo/AMD64_FREEBSD/.M3WEB > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.m3 > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.i3 > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.io > N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.io > N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.mo > N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.io > N cm3/elego/pkgvm/PkgTags > N cm3/elego/pkgvm/PkgErr > N cm3/elego/pkgvm/src/m3overrides > N cm3/elego/pkgvm/src/Main.m3 > N cm3/elego/pkgvm/src/pkgvm.desc > N cm3/elego/pkgvm/src/m3makefile > N cm3/elego/pkgvm/src/pkgvm.help > N cm3/elego/pkgvm/src/compactrc > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.i3 > N cm3/elego/pkgvm/AMD64_FREEBSD/_m3main.mc > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.i3 > N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm.mx > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.m3 > N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.io > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.m3 > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.mo > N cm3/elego/pkgvm/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkgvm/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/pkgvm/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.io > N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.mo > N cm3/elego/pkgvm/AMD64_FREEBSD/Main.mo > N cm3/elego/graphicutils/PkgTags > N cm3/elego/graphicutils/PkgErr > N cm3/elego/graphicutils/src/RsrcUtils.i3 > N cm3/elego/graphicutils/src/m3overrides > N cm3/elego/graphicutils/src/RsrcUtils.m3 > N cm3/elego/graphicutils/src/RsrcFilter.m3 > N cm3/elego/graphicutils/src/StdFontsX.m3 > N cm3/elego/graphicutils/src/StdFonts.m3 > N cm3/elego/graphicutils/src/m3makefile > N cm3/elego/graphicutils/src/RsrcFilter.i3 > N cm3/elego/graphicutils/src/StdFontsWin32.m3 > N cm3/elego/graphicutils/src/StdFonts.i3 > N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.m3x > N cm3/elego/graphicutils/AMD64_FREEBSD/StdFonts.io > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.mo > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.mo > N cm3/elego/graphicutils/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/graphicutils/AMD64_FREEBSD/StdFontsX.mo > N cm3/elego/graphicutils/AMD64_FREEBSD/.M3SHIP > N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.so.5 > N cm3/elego/graphicutils/AMD64_FREEBSD/.M3WEB > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.io > N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.io > N cm3/elego/m3dep/PkgTags > N cm3/elego/m3dep/PkgErr > N cm3/elego/m3dep/src/m3overrides > N cm3/elego/m3dep/src/Main.m3 > N cm3/elego/m3dep/src/m3makefile > N cm3/elego/m3dep/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3dep/AMD64_FREEBSD/m3dep > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3dep/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3dep/AMD64_FREEBSD/m3dep.mx > N cm3/elego/m3dep/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3dep/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3dep/AMD64_FREEBSD/Creation.io > N cm3/elego/m3dep/AMD64_FREEBSD/Main.mo > N cm3/elego/pkgversions/PkgTags > N cm3/elego/pkgversions/PkgErr > N cm3/elego/pkgversions/src/TagSort.m3 > N cm3/elego/pkgversions/src/Version.m3 > N cm3/elego/pkgversions/src/m3overrides > N cm3/elego/pkgversions/src/TagSort.i3 > N cm3/elego/pkgversions/src/Version.i3 > N cm3/elego/pkgversions/src/m3makefile > N cm3/elego/pkgversions/src/Tag.m3 > N cm3/elego/pkgversions/src/Tag.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/Version.io > N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.m3 > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.io > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.m3x > N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.so.5 > N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.io > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.io > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.io > N cm3/elego/pkgversions/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkgversions/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.io > N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.i3 > N cm3/elego/pkgversions/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.io > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.m3 > N cm3/elego/pkgversions/AMD64_FREEBSD/Version.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.mo > N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.i3 > N cm3/elego/m3makefile/PkgTags > N cm3/elego/m3makefile/PkgErr > N cm3/elego/m3makefile/src/m3overrides > N cm3/elego/m3makefile/src/QCompiler.i3 > N cm3/elego/m3makefile/src/QCompiler.m3 > N cm3/elego/m3makefile/src/m3makefile > N cm3/elego/m3makefile/src/M3makefile.m3 > N cm3/elego/m3makefile/src/M3makefile.i3 > N cm3/elego/m3makefile/test/src/Main.m3 > N cm3/elego/m3makefile/test/src/m3makefile > N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.m3x > N cm3/elego/m3makefile/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.mo > N cm3/elego/m3makefile/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.so.5 > N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.io > N cm3/elego/m3makefile/AMD64_FREEBSD/.M3WEB > N cm3/elego/rsrcservice/PkgTags > N cm3/elego/rsrcservice/PkgErr > N cm3/elego/rsrcservice/src/RsrcService.i3 > N cm3/elego/rsrcservice/src/m3overrides > N cm3/elego/rsrcservice/src/m3makefile > N cm3/elego/rsrcservice/src/ConfigRsrcService.m3 > N cm3/elego/rsrcservice/src/ConfigRsrcService.i3 > N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.mo > N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.so.5 > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.mo > N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.io > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.io > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3IMPTAB > N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.m3x > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3SHIP > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService.io > N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3WEB > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.m3 > N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.i3 > N cm3/elego/pkg_base/PkgTags > N cm3/elego/pkg_base/TODO > N cm3/elego/pkg_base/PkgDesc > N cm3/elego/pkg_base/PkgErr > N cm3/elego/pkg_base/src/m3overrides > N cm3/elego/pkg_base/src/PkgKindData.i3 > N cm3/elego/pkg_base/src/PkgBase.DefaultData > N cm3/elego/pkg_base/src/PkgBase.i3 > N cm3/elego/pkg_base/src/m3makefile > N cm3/elego/pkg_base/src/PkgKindData.m3 > N cm3/elego/pkg_base/src/PkgBase.m3 > N cm3/elego/pkg_base/src/PkgError.i3 > N cm3/elego/pkg_base/test0/src/Main.m3 > N cm3/elego/pkg_base/test0/src/kinds > N cm3/elego/pkg_base/test0/src/m3makefile > N cm3/elego/pkg_base/test0/src/dummy/bla > N cm3/elego/pkg_base/test0/src/dummy/dummy-a/hugo > N cm3/elego/pkg_base/test0/src/dummy/dummy-a/susi > N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.m3x > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.i3 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.i3 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgError.io > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.m3 > N cm3/elego/pkg_base/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/pkg_base/AMD64_FREEBSD/.M3SHIP > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.m3 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.mo > N cm3/elego/pkg_base/AMD64_FREEBSD/.M3WEB > N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.so.5 > N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.io > N cm3/elego/fsfind/PkgTags > N cm3/elego/fsfind/PkgErr > N cm3/elego/fsfind/src/FSFind.i3 > N cm3/elego/fsfind/src/m3overrides > N cm3/elego/fsfind/src/FileClassification.m3 > N cm3/elego/fsfind/src/FindExecRec.m3 > N cm3/elego/fsfind/src/FindExpr.i3 > N cm3/elego/fsfind/src/FSFind.m3 > N cm3/elego/fsfind/src/FindExecRec.i3 > N cm3/elego/fsfind/src/FileClassification.i3 > N cm3/elego/fsfind/src/FindExpr.m3 > N cm3/elego/fsfind/src/FSFindError.i3 > N cm3/elego/fsfind/src/m3makefile > N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.m3 > N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FSFindError.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.i3 > N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.m3x > N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.io > N cm3/elego/fsfind/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/fsfind/AMD64_FREEBSD/.M3SHIP > N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.mo > N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.io > N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.so.5 > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.mo > N cm3/elego/fsfind/AMD64_FREEBSD/.M3WEB > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.i3 > N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.io > N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.io > N cm3/elego/m3msh/PkgTags > N cm3/elego/m3msh/PkgErr > N cm3/elego/m3msh/src/m3overrides > N cm3/elego/m3msh/src/m3msh.desc > N cm3/elego/m3msh/src/m3makefile > N cm3/elego/m3msh/src/m3msh.help > N cm3/elego/m3msh/src/M3MiniShell.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.mo > N cm3/elego/m3msh/AMD64_FREEBSD/m3msh.mx > N cm3/elego/m3msh/AMD64_FREEBSD/M3MiniShell.mo > N cm3/elego/m3msh/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.io > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3msh/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3msh/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3msh/AMD64_FREEBSD/m3msh > N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.i3 > N cm3/elego/m3msh/AMD64_FREEBSD/Creation.io > N cm3/elego/m3dir/PkgTags > N cm3/elego/m3dir/PkgErr > N cm3/elego/m3dir/src/m3overrides > N cm3/elego/m3dir/src/M3Dir.m3 > N cm3/elego/m3dir/src/m3makefile > N cm3/elego/m3dir/AMD64_FREEBSD/m3dir.mx > N cm3/elego/m3dir/AMD64_FREEBSD/_m3main.mc > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.i3 > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.m3 > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.mo > N cm3/elego/m3dir/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/m3dir/AMD64_FREEBSD/.M3SHIP > N cm3/elego/m3dir/AMD64_FREEBSD/M3Dir.mo > N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.i3 > N cm3/elego/m3dir/AMD64_FREEBSD/.M3WEB > N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.m3 > N cm3/elego/m3dir/AMD64_FREEBSD/Creation.io > N cm3/elego/m3dir/AMD64_FREEBSD/m3dir > N cm3/elego/miniscan/PkgTags > N cm3/elego/miniscan/PkgErr > N cm3/elego/miniscan/src/m3overrides > N cm3/elego/miniscan/src/ScanToken.i3 > N cm3/elego/miniscan/src/m3makefile > N cm3/elego/miniscan/src/SimpleScanner.i3 > N cm3/elego/miniscan/src/SimpleScanner.m3 > N cm3/elego/miniscan/src/ScanToken.m3 > N cm3/elego/miniscan/test/src/m3overrides > N cm3/elego/miniscan/test/src/Main.m3 > N cm3/elego/miniscan/test/src/m3makefile > N cm3/elego/miniscan/test/src/otto > N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.io > N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.mo > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.io > N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.mo > N cm3/elego/miniscan/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/miniscan/AMD64_FREEBSD/.M3SHIP > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.i3 > N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.io > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.io > N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.so.5 > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.i3 > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.m3 > N cm3/elego/miniscan/AMD64_FREEBSD/.M3WEB > N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.m3x > N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.mo > N cm3/elego/compactrc/PkgTags > N cm3/elego/compactrc/PkgErr > N cm3/elego/compactrc/src/m3overrides > N cm3/elego/compactrc/src/CompactRC.m3 > N cm3/elego/compactrc/src/CompactRC.i3 > N cm3/elego/compactrc/src/compactrc.README > N cm3/elego/compactrc/src/MiniEnv.i3 > N cm3/elego/compactrc/src/compactrc.default > N cm3/elego/compactrc/src/m3makefile > N cm3/elego/compactrc/src/CompactEnvName.i3 > N cm3/elego/compactrc/src/MiniEnv.m3 > N cm3/elego/compactrc/src/compactrc.cd > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.mo > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.io > N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.io > N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.io > N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.so.5 > N cm3/elego/compactrc/AMD64_FREEBSD/CompactEnvName.io > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.m3 > N cm3/elego/compactrc/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/compactrc/AMD64_FREEBSD/.M3SHIP > N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.m3x > N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.i3 > N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.mo > N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.mo > N cm3/elego/compactrc/AMD64_FREEBSD/.M3WEB > N cm3/elego/depgraph/PkgTags > N cm3/elego/depgraph/PkgErr > N cm3/elego/depgraph/src/StdDepGraph.m3 > N cm3/elego/depgraph/src/DependencyGraph.i3 > N cm3/elego/depgraph/src/StdDepGraphNode.m3 > N cm3/elego/depgraph/src/m3overrides > N cm3/elego/depgraph/src/StdDepGraph.i3 > N cm3/elego/depgraph/src/StdDepGraphEdge.i3 > N cm3/elego/depgraph/src/DependencyGraph.m3 > N cm3/elego/depgraph/src/m3makefile > N cm3/elego/depgraph/src/StdDepGraphNode.i3 > N cm3/elego/depgraph/src/StdDepGraphEdge.m3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.mo > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.mo > N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.m3x > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.m3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.mo > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.m3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.i3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.io > N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.so.5 > N cm3/elego/depgraph/AMD64_FREEBSD/.M3EXPORTS > N cm3/elego/depgraph/AMD64_FREEBSD/.M3SHIP > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.mo > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.i3 > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.io > N cm3/elego/depgraph/AMD64_FREEBSD/.M3WEB > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.mo > N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.mo > N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.io > N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.i3 > > No conflicts created by this import > From wagner at elegosoft.com Sat Aug 7 22:16:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 07 Aug 2010 22:16:39 +0200 Subject: [M3devel] elego compact In-Reply-To: References: <20100807161924.5CA4924740DC@birch.elegosoft.com> Message-ID: <20100807221639.cfa70r5ttwgos040@mail.elegosoft.com> Quoting Jay K : > Cool. Notice the derived files (directory AMD64_FREEBSD) got imported. Yes. But I immediately removed them again on birch. Stupid pilot error :-/ Actually this project was lying around here for about two years now... I thought today would be a good day to finish it :-) It took me most of the day to make everything compile again (several LONGINT changes, M3Config gone etc.). Olaf > - Jay > > ---------------------------------------- >> Date: Sat, 7 Aug 2010 18:19:23 +0000 >> To: m3commit at elegosoft.com >> From: wagner at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: wagner at birch. 10/08/07 18:19:23 >> >> cm3/elego >> >> Update of /usr/cvs/cm3/elego >> In directory birch:/tmp/cvs-serv13035 >> >> Log Message: >> Stripped-down version of Elego ComPact; software developed and used >> at Elego years ago. I put it under the same copyright as the other >> Modula-3 sources from DEC and Critical Mass. >> >> Included is package version management based on CVS and build and >> version management for sets of packages, called `project management' >> in ComPact. >> >> Not included is the general package manager for C/C++/Java/M3, and the >> ComPact GUI. >> >> It is contributed in the hope that it may be useful in whole or parts >> for the CM3 project or any other users. >> >> The command line interface consists of the programs pkgvm and prjm, >> which include complete manuals as well as short usage help: >> >> pkgvm -help | -man >> prjm -help | -man >> >> The sources have been successfully compiled with a current cm3 (d5.9.0) >> by prjm with >> >> prjm -D ROOT=$HOME/work/cm3 -buildglobal >> >> The project definition is contained in the file elego/PrjDesc. >> >> To compile everything with the CM3 srcipts, use >> >> ~/work/cm3/scripts/do-pkg.sh buildship langutils graphicutils tuple >> depgraph miniscan fsfind fileinfo filepool pkgversions >> compact-copyright rsrcservice compact-client compactrc pkg_base >> pkg_vc m3makefile m3dep m3dir m3err m3msh m3ovr pkgvm prjbase prjm >> >> Several things may still be wrong and need to be adapted for use with >> the current CM3, but the ComPact tools should be quite flexible and >> configurable. >> >> As all free software, this comes without any guarantee that it will >> be useful in any way. Use at your own risk. >> >> Olaf Wagner / Elego Software Solutions GmbH, Berlin, Germany, 2010-08-07 >> >> >> Status: >> >> Vendor Tag: elego-compact-free-1-0 >> Release Tags: rel-compact-free-1-0 >> >> N cm3/elego/DepGraph >> N cm3/elego/quake.elego >> N cm3/elego/PrjDesc >> N cm3/elego/srcs >> N cm3/elego/compact-copyright/PkgTags >> N cm3/elego/compact-copyright/PkgErr >> N cm3/elego/compact-copyright/src/Copyright.m3 >> N cm3/elego/compact-copyright/src/Release.m3 >> N cm3/elego/compact-copyright/src/m3overrides >> N cm3/elego/compact-copyright/src/ProgramVersion.i3 >> N cm3/elego/compact-copyright/src/Version.i3 >> N cm3/elego/compact-copyright/src/Release.i3 >> N cm3/elego/compact-copyright/src/compact-copyrights.txt >> N cm3/elego/compact-copyright/src/m3makefile >> N cm3/elego/compact-copyright/src/Copyright.i3 >> N cm3/elego/compact-copyright/src/ProgramVersion.m3 >> N cm3/elego/compact-copyright/src/get-licences >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.io >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.io >> N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.so.5 >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.i3 >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.io >> N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Copyright.mo >> N cm3/elego/compact-copyright/AMD64_FREEBSD/libcompact-copyright.m3x >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.m3 >> N cm3/elego/compact-copyright/AMD64_FREEBSD/CopyrightBundle.mo >> N cm3/elego/compact-copyright/AMD64_FREEBSD/.M3WEB >> N cm3/elego/compact-copyright/AMD64_FREEBSD/Release.mo >> N cm3/elego/filepool/PkgTags >> N cm3/elego/filepool/PkgErr >> N cm3/elego/filepool/src/m3overrides >> N cm3/elego/filepool/src/FilePool.m3 >> N cm3/elego/filepool/src/m3makefile >> N cm3/elego/filepool/src/FilePool.i3 >> N cm3/elego/filepool/test/src/Main.m3 >> N cm3/elego/filepool/test/src/m3makefile >> N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.so.5 >> N cm3/elego/filepool/AMD64_FREEBSD/libfilepool.m3x >> N cm3/elego/filepool/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/filepool/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/filepool/AMD64_FREEBSD/FilePool.io >> N cm3/elego/filepool/AMD64_FREEBSD/.M3WEB >> N cm3/elego/filepool/AMD64_FREEBSD/FilePool.mo >> N cm3/elego/m3err/PkgTags >> N cm3/elego/m3err/m3err.gmon >> N cm3/elego/m3err/PkgErr >> N cm3/elego/m3err/src/m3overrides >> N cm3/elego/m3err/src/m3err.m3 >> N cm3/elego/m3err/src/m3makefile >> N cm3/elego/m3err/AMD64_FREEBSD/m3err >> N cm3/elego/m3err/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3err/AMD64_FREEBSD/m3err.mo >> N cm3/elego/m3err/AMD64_FREEBSD/m3err.mx >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3err/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3err/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3err/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3err/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3err/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3err/AMD64_FREEBSD/Creation.io >> N cm3/elego/prjbase/PkgTags >> N cm3/elego/prjbase/PkgErr >> N cm3/elego/prjbase/snaps/snaps.idx >> N cm3/elego/prjbase/src/PrjDesc.i3 >> N cm3/elego/prjbase/src/ChangeSet.i3 >> N cm3/elego/prjbase/src/Checkpoint.i3 >> N cm3/elego/prjbase/src/PrjDesc.m3 >> N cm3/elego/prjbase/src/Snapshots.i3 >> N cm3/elego/prjbase/src/Snapshots.m3 >> N cm3/elego/prjbase/src/ChangeSet.m3 >> N cm3/elego/prjbase/src/m3overrides >> N cm3/elego/prjbase/src/RCS_Date.i3 >> N cm3/elego/prjbase/src/PoolSet.i3 >> N cm3/elego/prjbase/src/RCS_Date.m3 >> N cm3/elego/prjbase/src/PoolSet.m3 >> N cm3/elego/prjbase/src/Checkpoint.m3 >> N cm3/elego/prjbase/src/rcsdate.patch >> N cm3/elego/prjbase/src/m3makefile >> N cm3/elego/prjbase/src/m3browser.html >> N cm3/elego/prjbase/test/src/PrjDesc1 >> N cm3/elego/prjbase/test/src/PrjDesc2 >> N cm3/elego/prjbase/test/src/Main.m3 >> N cm3/elego/prjbase/test/src/m3makefile >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.io >> N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/RCS_Date.io >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/PoolSet.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.m3x >> N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/Checkpoint.io >> N cm3/elego/prjbase/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextPrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/libprjbase.so.5 >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/PrjDesc.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TimeChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/.M3WEB >> N cm3/elego/prjbase/AMD64_FREEBSD/TimePrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimeChangeSetTbl.m3 >> N cm3/elego/prjbase/AMD64_FREEBSD/ChangeSet.io >> N cm3/elego/prjbase/AMD64_FREEBSD/Snapshots.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTimePrjDescTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/SortedTextChangeSetTbl.mo >> N cm3/elego/prjbase/AMD64_FREEBSD/TextTextTextTbl.i3 >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPrjDescTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextPkgVCTbl.io >> N cm3/elego/prjbase/AMD64_FREEBSD/TextChangeSetTbl.i3 >> N cm3/elego/tuple/PkgTags >> N cm3/elego/tuple/PkgErr >> N cm3/elego/tuple/src/TextTuple.m3 >> N cm3/elego/tuple/src/TextTuple.i3 >> N cm3/elego/tuple/src/Dummy.i3 >> N cm3/elego/tuple/src/m3overrides >> N cm3/elego/tuple/src/Tuple.mg >> N cm3/elego/tuple/src/Tuple.ig >> N cm3/elego/tuple/src/m3makefile >> N cm3/elego/tuple/src/Dummy.m3 >> N cm3/elego/tuple/src/HeteroTuple.mg >> N cm3/elego/tuple/src/HeteroTuple.ig >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.i3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.io >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.io >> N cm3/elego/tuple/AMD64_FREEBSD/libtuple.so.5 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.i3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.io >> N cm3/elego/tuple/AMD64_FREEBSD/TextTuple.mo >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.mo >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeqRep.i3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.mo >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.io >> N cm3/elego/tuple/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/tuple/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqRep.io >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeq.m3 >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.m3 >> N cm3/elego/tuple/AMD64_FREEBSD/.M3WEB >> N cm3/elego/tuple/AMD64_FREEBSD/libtuple.m3x >> N cm3/elego/tuple/AMD64_FREEBSD/TextTupleSeqSeq.i3 >> N cm3/elego/langutils/PkgTags >> N cm3/elego/langutils/PkgErr >> N cm3/elego/langutils/src/m3overrides >> N cm3/elego/langutils/src/SimpleValueEnv.m3 >> N cm3/elego/langutils/src/SimpleValueEnv.i3 >> N cm3/elego/langutils/src/m3makefile >> N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.m3x >> N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.mo >> N cm3/elego/langutils/AMD64_FREEBSD/liblangutils.so.5 >> N cm3/elego/langutils/AMD64_FREEBSD/SimpleValueEnv.io >> N cm3/elego/langutils/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/langutils/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/langutils/AMD64_FREEBSD/.M3WEB >> N cm3/elego/prjm/PkgTags >> N cm3/elego/prjm/PrjDesc >> N cm3/elego/prjm/stat >> N cm3/elego/prjm/PkgErr >> N cm3/elego/prjm/src/m3overrides >> N cm3/elego/prjm/src/Copyright >> N cm3/elego/prjm/src/PrjmGUI.fv >> N cm3/elego/prjm/src/m3makefile >> N cm3/elego/prjm/src/ProjectManager.m3 >> N cm3/elego/prjm/src/ShortUsageHelp >> N cm3/elego/prjm/src/UsageHelp >> N cm3/elego/prjm/src/compactrc >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.io >> N cm3/elego/prjm/AMD64_FREEBSD/prjm.mx >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.i3 >> N cm3/elego/prjm/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/prjm/AMD64_FREEBSD/prjm >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.mo >> N cm3/elego/prjm/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/prjm/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/prjm/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManager.mo >> N cm3/elego/prjm/AMD64_FREEBSD/.M3WEB >> N cm3/elego/prjm/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.mo >> N cm3/elego/prjm/AMD64_FREEBSD/ProjectManagerBundle.m3 >> N cm3/elego/prjm/AMD64_FREEBSD/Creation.io >> N cm3/elego/pkg_vc/PkgTags >> N cm3/elego/pkg_vc/TODO >> N cm3/elego/pkg_vc/PkgDesc >> N cm3/elego/pkg_vc/PkgErr >> N cm3/elego/pkg_vc/src/PkgVC.i3 >> N cm3/elego/pkg_vc/src/CVS.i3 >> N cm3/elego/pkg_vc/src/FileRevision.i3 >> N cm3/elego/pkg_vc/src/m3overrides >> N cm3/elego/pkg_vc/src/FileObj.i3 >> N cm3/elego/pkg_vc/src/ProcessPosixOS2.m3 >> N cm3/elego/pkg_vc/src/PkgVCUtils.m3 >> N cm3/elego/pkg_vc/src/VCIF.i3 >> N cm3/elego/pkg_vc/src/OpResultCache.m3 >> N cm3/elego/pkg_vc/src/VCUtils.i3 >> N cm3/elego/pkg_vc/src/gnats-commit-check.sh >> N cm3/elego/pkg_vc/src/Process2.i3 >> N cm3/elego/pkg_vc/src/PkgVCUtils.i3 >> N cm3/elego/pkg_vc/src/m3makefile >> N cm3/elego/pkg_vc/src/FileObj.m3 >> N cm3/elego/pkg_vc/src/PkgVC.m3 >> N cm3/elego/pkg_vc/src/VCUtils.m3 >> N cm3/elego/pkg_vc/src/CVS_st.m3 >> N cm3/elego/pkg_vc/src/CVSLockInfo.i3 >> N cm3/elego/pkg_vc/src/OpResultCache.i3 >> N cm3/elego/pkg_vc/tests/src/m3overrides >> N cm3/elego/pkg_vc/tests/src/Main.m3 >> N cm3/elego/pkg_vc/tests/src/m3makefile >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.m3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/VCIF.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.m3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS_st.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/OpResultCache.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.so.5 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfo.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.m3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkg_vc/AMD64_FREEBSD/libpkg_vc.m3x >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileObj.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevision.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/VCUtils.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkg_vc/AMD64_FREEBSD/TextLockInfoTbl.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.i3 >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeqRep.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeq.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVSLockInfoSeqRep.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVC.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/PkgVCUtils.io >> N cm3/elego/pkg_vc/AMD64_FREEBSD/FileRevisionSeq.mo >> N cm3/elego/pkg_vc/AMD64_FREEBSD/CVS.io >> N cm3/elego/m3ovr/PkgTags >> N cm3/elego/m3ovr/PkgErr >> N cm3/elego/m3ovr/src/m3overrides >> N cm3/elego/m3ovr/src/Main.m3 >> N cm3/elego/m3ovr/src/m3makefile >> N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr.mx >> N cm3/elego/m3ovr/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/m3ovr >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3ovr/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3ovr/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3ovr/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3ovr/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3ovr/AMD64_FREEBSD/Main.mo >> N cm3/elego/compact-client/PkgTags >> N cm3/elego/compact-client/PkgErr >> N cm3/elego/compact-client/src/m3overrides >> N cm3/elego/compact-client/src/CompactClient.m3 >> N cm3/elego/compact-client/src/m3makefile >> N cm3/elego/compact-client/src/CompactClient.i3 >> N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.so.5 >> N cm3/elego/compact-client/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/compact-client/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.mo >> N cm3/elego/compact-client/AMD64_FREEBSD/.M3WEB >> N cm3/elego/compact-client/AMD64_FREEBSD/libcompact-client.m3x >> N cm3/elego/compact-client/AMD64_FREEBSD/CompactClient.io >> N cm3/elego/fileinfo/PkgTags >> N cm3/elego/fileinfo/PkgErr >> N cm3/elego/fileinfo/src/FileDir.m3 >> N cm3/elego/fileinfo/src/FileStatus.i3 >> N cm3/elego/fileinfo/src/DirTree.m3 >> N cm3/elego/fileinfo/src/Dummy.i3 >> N cm3/elego/fileinfo/src/FileStamp.i3 >> N cm3/elego/fileinfo/src/m3overrides >> N cm3/elego/fileinfo/src/DirTree.i3 >> N cm3/elego/fileinfo/src/APN.i3 >> N cm3/elego/fileinfo/src/FileDir.i3 >> N cm3/elego/fileinfo/src/FileInfo.i3 >> N cm3/elego/fileinfo/src/PathnameStatusTable.i3 >> N cm3/elego/fileinfo/src/FileStatus.m3 >> N cm3/elego/fileinfo/src/m3makefile >> N cm3/elego/fileinfo/src/Dummy.m3 >> N cm3/elego/fileinfo/src/FileSystem.m3 >> N cm3/elego/fileinfo/src/FileSystem.i3 >> N cm3/elego/fileinfo/src/PathnameStatusTable.m3 >> N cm3/elego/fileinfo/src/FileInfo.m3 >> N cm3/elego/fileinfo/src/APN.m3 >> N cm3/elego/fileinfo/src/TreeStamp.i3 >> N cm3/elego/fileinfo/src/FileStamp.m3 >> N cm3/elego/fileinfo/tests/PkgTags >> N cm3/elego/fileinfo/tests/src/m3overrides >> N cm3/elego/fileinfo/tests/src/Main.m3 >> N cm3/elego/fileinfo/tests/src/m3makefile >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.m3x >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirTree.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/libfileinfo.so.5 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileStatus.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/APN.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/Dummy.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/fileinfo/AMD64_FREEBSD/DirectoryTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APN.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeq.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNHashTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNStatusTbl.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/.M3WEB >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.m3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.i3 >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeqRep.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileInfo.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/FileSystem.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/BoolSeqRep.io >> N cm3/elego/fileinfo/AMD64_FREEBSD/TextHashTbl.mo >> N cm3/elego/fileinfo/AMD64_FREEBSD/APNSeq.io >> N cm3/elego/pkgvm/PkgTags >> N cm3/elego/pkgvm/PkgErr >> N cm3/elego/pkgvm/src/m3overrides >> N cm3/elego/pkgvm/src/Main.m3 >> N cm3/elego/pkgvm/src/pkgvm.desc >> N cm3/elego/pkgvm/src/m3makefile >> N cm3/elego/pkgvm/src/pkgvm.help >> N cm3/elego/pkgvm/src/compactrc >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.i3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm.mx >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/pkgvm >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.io >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.m3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.mo >> N cm3/elego/pkgvm/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkgvm/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkgvm/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/pkgvm/AMD64_FREEBSD/Creation.io >> N cm3/elego/pkgvm/AMD64_FREEBSD/PkgVMBundle.mo >> N cm3/elego/pkgvm/AMD64_FREEBSD/Main.mo >> N cm3/elego/graphicutils/PkgTags >> N cm3/elego/graphicutils/PkgErr >> N cm3/elego/graphicutils/src/RsrcUtils.i3 >> N cm3/elego/graphicutils/src/m3overrides >> N cm3/elego/graphicutils/src/RsrcUtils.m3 >> N cm3/elego/graphicutils/src/RsrcFilter.m3 >> N cm3/elego/graphicutils/src/StdFontsX.m3 >> N cm3/elego/graphicutils/src/StdFonts.m3 >> N cm3/elego/graphicutils/src/m3makefile >> N cm3/elego/graphicutils/src/RsrcFilter.i3 >> N cm3/elego/graphicutils/src/StdFontsWin32.m3 >> N cm3/elego/graphicutils/src/StdFonts.i3 >> N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.m3x >> N cm3/elego/graphicutils/AMD64_FREEBSD/StdFonts.io >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.mo >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.mo >> N cm3/elego/graphicutils/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/graphicutils/AMD64_FREEBSD/StdFontsX.mo >> N cm3/elego/graphicutils/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/graphicutils/AMD64_FREEBSD/libgraphicutils.so.5 >> N cm3/elego/graphicutils/AMD64_FREEBSD/.M3WEB >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcFilter.io >> N cm3/elego/graphicutils/AMD64_FREEBSD/RsrcUtils.io >> N cm3/elego/m3dep/PkgTags >> N cm3/elego/m3dep/PkgErr >> N cm3/elego/m3dep/src/m3overrides >> N cm3/elego/m3dep/src/Main.m3 >> N cm3/elego/m3dep/src/m3makefile >> N cm3/elego/m3dep/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3dep/AMD64_FREEBSD/m3dep >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3dep/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3dep/AMD64_FREEBSD/m3dep.mx >> N cm3/elego/m3dep/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3dep/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3dep/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3dep/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3dep/AMD64_FREEBSD/Main.mo >> N cm3/elego/pkgversions/PkgTags >> N cm3/elego/pkgversions/PkgErr >> N cm3/elego/pkgversions/src/TagSort.m3 >> N cm3/elego/pkgversions/src/Version.m3 >> N cm3/elego/pkgversions/src/m3overrides >> N cm3/elego/pkgversions/src/TagSort.i3 >> N cm3/elego/pkgversions/src/Version.i3 >> N cm3/elego/pkgversions/src/m3makefile >> N cm3/elego/pkgversions/src/Tag.m3 >> N cm3/elego/pkgversions/src/Tag.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/Version.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.m3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeqRep.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.m3x >> N cm3/elego/pkgversions/AMD64_FREEBSD/libpkgversions.so.5 >> N cm3/elego/pkgversions/AMD64_FREEBSD/Tag.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkgversions/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/VersionSeq.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.i3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.io >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeq.m3 >> N cm3/elego/pkgversions/AMD64_FREEBSD/Version.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSort.mo >> N cm3/elego/pkgversions/AMD64_FREEBSD/TagSeqRep.i3 >> N cm3/elego/m3makefile/PkgTags >> N cm3/elego/m3makefile/PkgErr >> N cm3/elego/m3makefile/src/m3overrides >> N cm3/elego/m3makefile/src/QCompiler.i3 >> N cm3/elego/m3makefile/src/QCompiler.m3 >> N cm3/elego/m3makefile/src/m3makefile >> N cm3/elego/m3makefile/src/M3makefile.m3 >> N cm3/elego/m3makefile/src/M3makefile.i3 >> N cm3/elego/m3makefile/test/src/Main.m3 >> N cm3/elego/m3makefile/test/src/m3makefile >> N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.m3x >> N cm3/elego/m3makefile/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.mo >> N cm3/elego/m3makefile/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3makefile/AMD64_FREEBSD/libm3makefile.so.5 >> N cm3/elego/m3makefile/AMD64_FREEBSD/M3makefile.io >> N cm3/elego/m3makefile/AMD64_FREEBSD/.M3WEB >> N cm3/elego/rsrcservice/PkgTags >> N cm3/elego/rsrcservice/PkgErr >> N cm3/elego/rsrcservice/src/RsrcService.i3 >> N cm3/elego/rsrcservice/src/m3overrides >> N cm3/elego/rsrcservice/src/m3makefile >> N cm3/elego/rsrcservice/src/ConfigRsrcService.m3 >> N cm3/elego/rsrcservice/src/ConfigRsrcService.i3 >> N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.mo >> N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.so.5 >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.mo >> N cm3/elego/rsrcservice/AMD64_FREEBSD/ConfigRsrcService.io >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.io >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3IMPTAB >> N cm3/elego/rsrcservice/AMD64_FREEBSD/librsrcservice.m3x >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService.io >> N cm3/elego/rsrcservice/AMD64_FREEBSD/.M3WEB >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.m3 >> N cm3/elego/rsrcservice/AMD64_FREEBSD/RsrcService_T_v1.i3 >> N cm3/elego/pkg_base/PkgTags >> N cm3/elego/pkg_base/TODO >> N cm3/elego/pkg_base/PkgDesc >> N cm3/elego/pkg_base/PkgErr >> N cm3/elego/pkg_base/src/m3overrides >> N cm3/elego/pkg_base/src/PkgKindData.i3 >> N cm3/elego/pkg_base/src/PkgBase.DefaultData >> N cm3/elego/pkg_base/src/PkgBase.i3 >> N cm3/elego/pkg_base/src/m3makefile >> N cm3/elego/pkg_base/src/PkgKindData.m3 >> N cm3/elego/pkg_base/src/PkgBase.m3 >> N cm3/elego/pkg_base/src/PkgError.i3 >> N cm3/elego/pkg_base/test0/src/Main.m3 >> N cm3/elego/pkg_base/test0/src/kinds >> N cm3/elego/pkg_base/test0/src/m3makefile >> N cm3/elego/pkg_base/test0/src/dummy/bla >> N cm3/elego/pkg_base/test0/src/dummy/dummy-a/hugo >> N cm3/elego/pkg_base/test0/src/dummy/dummy-a/susi >> N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.m3x >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.i3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBase.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.i3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgError.io >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.m3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/pkg_base/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindDataTbl.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgBaseBundle.m3 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.mo >> N cm3/elego/pkg_base/AMD64_FREEBSD/.M3WEB >> N cm3/elego/pkg_base/AMD64_FREEBSD/libpkgbase.so.5 >> N cm3/elego/pkg_base/AMD64_FREEBSD/PkgKindData.io >> N cm3/elego/fsfind/PkgTags >> N cm3/elego/fsfind/PkgErr >> N cm3/elego/fsfind/src/FSFind.i3 >> N cm3/elego/fsfind/src/m3overrides >> N cm3/elego/fsfind/src/FileClassification.m3 >> N cm3/elego/fsfind/src/FindExecRec.m3 >> N cm3/elego/fsfind/src/FindExpr.i3 >> N cm3/elego/fsfind/src/FSFind.m3 >> N cm3/elego/fsfind/src/FindExecRec.i3 >> N cm3/elego/fsfind/src/FileClassification.i3 >> N cm3/elego/fsfind/src/FindExpr.m3 >> N cm3/elego/fsfind/src/FSFindError.i3 >> N cm3/elego/fsfind/src/m3makefile >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.m3 >> N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FSFindError.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExpr.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.i3 >> N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.m3x >> N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FileClassification.io >> N cm3/elego/fsfind/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/fsfind/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/FSFind.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.io >> N cm3/elego/fsfind/AMD64_FREEBSD/libfsfind.so.5 >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.mo >> N cm3/elego/fsfind/AMD64_FREEBSD/.M3WEB >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeqRep.i3 >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExprSeq.io >> N cm3/elego/fsfind/AMD64_FREEBSD/FindExecRec.io >> N cm3/elego/m3msh/PkgTags >> N cm3/elego/m3msh/PkgErr >> N cm3/elego/m3msh/src/m3overrides >> N cm3/elego/m3msh/src/m3msh.desc >> N cm3/elego/m3msh/src/m3makefile >> N cm3/elego/m3msh/src/m3msh.help >> N cm3/elego/m3msh/src/M3MiniShell.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.mo >> N cm3/elego/m3msh/AMD64_FREEBSD/m3msh.mx >> N cm3/elego/m3msh/AMD64_FREEBSD/M3MiniShell.mo >> N cm3/elego/m3msh/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.io >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3msh/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3msh/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3msh/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3msh/AMD64_FREEBSD/m3msh >> N cm3/elego/m3msh/AMD64_FREEBSD/MiniShellBundle.i3 >> N cm3/elego/m3msh/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3dir/PkgTags >> N cm3/elego/m3dir/PkgErr >> N cm3/elego/m3dir/src/m3overrides >> N cm3/elego/m3dir/src/M3Dir.m3 >> N cm3/elego/m3dir/src/m3makefile >> N cm3/elego/m3dir/AMD64_FREEBSD/m3dir.mx >> N cm3/elego/m3dir/AMD64_FREEBSD/_m3main.mc >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.i3 >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.m3 >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.mo >> N cm3/elego/m3dir/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/m3dir/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/m3dir/AMD64_FREEBSD/M3Dir.mo >> N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.i3 >> N cm3/elego/m3dir/AMD64_FREEBSD/.M3WEB >> N cm3/elego/m3dir/AMD64_FREEBSD/.Creation.m3 >> N cm3/elego/m3dir/AMD64_FREEBSD/Creation.io >> N cm3/elego/m3dir/AMD64_FREEBSD/m3dir >> N cm3/elego/miniscan/PkgTags >> N cm3/elego/miniscan/PkgErr >> N cm3/elego/miniscan/src/m3overrides >> N cm3/elego/miniscan/src/ScanToken.i3 >> N cm3/elego/miniscan/src/m3makefile >> N cm3/elego/miniscan/src/SimpleScanner.i3 >> N cm3/elego/miniscan/src/SimpleScanner.m3 >> N cm3/elego/miniscan/src/ScanToken.m3 >> N cm3/elego/miniscan/test/src/m3overrides >> N cm3/elego/miniscan/test/src/Main.m3 >> N cm3/elego/miniscan/test/src/m3makefile >> N cm3/elego/miniscan/test/src/otto >> N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.io >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.mo >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.io >> N cm3/elego/miniscan/AMD64_FREEBSD/SimpleScanner.mo >> N cm3/elego/miniscan/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/miniscan/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeqRep.i3 >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanToken.io >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.io >> N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.so.5 >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.i3 >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.m3 >> N cm3/elego/miniscan/AMD64_FREEBSD/.M3WEB >> N cm3/elego/miniscan/AMD64_FREEBSD/libminiscan.m3x >> N cm3/elego/miniscan/AMD64_FREEBSD/ScanTokenSeq.mo >> N cm3/elego/compactrc/PkgTags >> N cm3/elego/compactrc/PkgErr >> N cm3/elego/compactrc/src/m3overrides >> N cm3/elego/compactrc/src/CompactRC.m3 >> N cm3/elego/compactrc/src/CompactRC.i3 >> N cm3/elego/compactrc/src/compactrc.README >> N cm3/elego/compactrc/src/MiniEnv.i3 >> N cm3/elego/compactrc/src/compactrc.default >> N cm3/elego/compactrc/src/m3makefile >> N cm3/elego/compactrc/src/CompactEnvName.i3 >> N cm3/elego/compactrc/src/MiniEnv.m3 >> N cm3/elego/compactrc/src/compactrc.cd >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.mo >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.io >> N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.io >> N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.io >> N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.so.5 >> N cm3/elego/compactrc/AMD64_FREEBSD/CompactEnvName.io >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.m3 >> N cm3/elego/compactrc/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/compactrc/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/compactrc/AMD64_FREEBSD/libcompactrc.m3x >> N cm3/elego/compactrc/AMD64_FREEBSD/TextTextTupleSeqTbl.i3 >> N cm3/elego/compactrc/AMD64_FREEBSD/CompactRC.mo >> N cm3/elego/compactrc/AMD64_FREEBSD/MiniEnv.mo >> N cm3/elego/compactrc/AMD64_FREEBSD/.M3WEB >> N cm3/elego/depgraph/PkgTags >> N cm3/elego/depgraph/PkgErr >> N cm3/elego/depgraph/src/StdDepGraph.m3 >> N cm3/elego/depgraph/src/DependencyGraph.i3 >> N cm3/elego/depgraph/src/StdDepGraphNode.m3 >> N cm3/elego/depgraph/src/m3overrides >> N cm3/elego/depgraph/src/StdDepGraph.i3 >> N cm3/elego/depgraph/src/StdDepGraphEdge.i3 >> N cm3/elego/depgraph/src/DependencyGraph.m3 >> N cm3/elego/depgraph/src/m3makefile >> N cm3/elego/depgraph/src/StdDepGraphNode.i3 >> N cm3/elego/depgraph/src/StdDepGraphEdge.m3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.m3x >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.m3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.m3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.i3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraph.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdNameNodeTbl.io >> N cm3/elego/depgraph/AMD64_FREEBSD/libdepgraph.so.5 >> N cm3/elego/depgraph/AMD64_FREEBSD/.M3EXPORTS >> N cm3/elego/depgraph/AMD64_FREEBSD/.M3SHIP >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNode.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeqRep.i3 >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.io >> N cm3/elego/depgraph/AMD64_FREEBSD/.M3WEB >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.mo >> N cm3/elego/depgraph/AMD64_FREEBSD/DependencyGraph.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphEdge.io >> N cm3/elego/depgraph/AMD64_FREEBSD/StdDepGraphNodeSeq.i3 >> >> No conflicts created by this import >> > -- 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 mika at async.async.caltech.edu Sun Aug 8 00:32:16 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 07 Aug 2010 15:32:16 -0700 Subject: [M3devel] more problems upgrading Message-ID: <20100807223216.78F951A20AD@async.async.caltech.edu> Hello m3devel, I'm running into problems again. Now I'm trying to upgrade CM3 on a FreeBSD 5 machine (248)rover:~/cm3/scripts>uname -a FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #0: Sat May 24 10:13:58 PDT 2008 root at rover:/usr/src/sys/i386/compile/ROVERSMP i386 (250)rover:~/cm3/scripts>cm3 -version Critical Mass Modula-3 version d5.8.1 last updated: 2009-05-16 compiled: 2009-06-16 20:34:18 configuration: /usr/local/cm3/bin/cm3.cfg target: FreeBSD4 upgrade.sh runs for a while then dies at: === package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3 === +++ cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' +++ --- building in FreeBSD4 --- ignoring ../src/m3overrides Fatal Error: duplicate link info: M3Path.i3 *** execution of cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' failed *** The reason I'm doing this, by the way, is that I'm having trouble sharing pickles between an amd64 and i386 system and wanted to ensure I have recent CM3 distributions on both systems before starting to debug the problem. It appears I can write pickles on i386 and read them on amd64 without trouble, but not the other way around (and I am not using any out-of-range values, I don't think). Mika From mika at async.async.caltech.edu Sun Aug 8 01:01:11 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 07 Aug 2010 16:01:11 -0700 Subject: [M3devel] more problems upgrading In-Reply-To: <20100807223216.78F951A20AD@async.async.caltech.edu> References: <20100807223216.78F951A20AD@async.async.caltech.edu> Message-ID: <20100807230111.66FC31A20AF@async.async.caltech.edu> Sorry to spam the list, this was user error. Mika Nystrom writes: >Hello m3devel, > >I'm running into problems again. Now I'm trying to upgrade CM3 on >a FreeBSD 5 machine > >(248)rover:~/cm3/scripts>uname -a >FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #0: Sat May 24 10:13:58 PDT 2008 > root at rover:/usr/src/sys/i386/compile/ROVERSMP i386 >(250)rover:~/cm3/scripts>cm3 -version >Critical Mass Modula-3 version d5.8.1 > last updated: 2009-05-16 > compiled: 2009-06-16 20:34:18 > configuration: /usr/local/cm3/bin/cm3.cfg > target: FreeBSD4 > >upgrade.sh runs for a while then dies at: > >=== package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3 === > +++ cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $R >ARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' +++ >--- building in FreeBSD4 --- > >ignoring ../src/m3overrides > > >Fatal Error: duplicate link info: M3Path.i3 > > *** execution of cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && > cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' failed *** > > >The reason I'm doing this, by the way, is that I'm having trouble >sharing pickles between an amd64 and i386 system and wanted to ensure I >have recent CM3 distributions on both systems before starting to debug >the problem. > >It appears I can write pickles on i386 and read them on amd64 without >trouble, but not the other way around (and I am not using any out-of-range >values, I don't think). > > Mika From jay.krell at cornell.edu Sun Aug 8 01:30:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 7 Aug 2010 23:30:17 +0000 Subject: [M3devel] more problems upgrading In-Reply-To: <20100807230111.66FC31A20AF@async.async.caltech.edu> References: <20100807223216.78F951A20AD@async.async.caltech.edu>, <20100807230111.66FC31A20AF@async.async.caltech.edu> Message-ID: I believe I moved M3Path.*, like from cm3 to m3quake. There is a bug; this requires clean. I don't know if upgrade.sh gets any use these days. I use upgrade.py often. Note that upgrade.py does not rebuild entire system, just compiler. E.g. . /upgrade.py skipgcc && ./do-cm3-all.py skipgcc realclean && ./do-cm3-all.py skipgcc buildship - Jay/phone > To: m3devel at elegosoft.com > Date: Sat, 7 Aug 2010 16:01:11 -0700 > From: mika at async.async.caltech.edu > Subject: Re: [M3devel] more problems upgrading > > Sorry to spam the list, this was user error. > > Mika Nystrom writes: > >Hello m3devel, > > > >I'm running into problems again. Now I'm trying to upgrade CM3 on > >a FreeBSD 5 machine > > > >(248)rover:~/cm3/scripts>uname -a > >FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #0: Sat May 24 10:13:58 PDT 2008 > > root at rover:/usr/src/sys/i386/compile/ROVERSMP i386 > >(250)rover:~/cm3/scripts>cm3 -version > >Critical Mass Modula-3 version d5.8.1 > > last updated: 2009-05-16 > > compiled: 2009-06-16 20:34:18 > > configuration: /usr/local/cm3/bin/cm3.cfg > > target: FreeBSD4 > > > >upgrade.sh runs for a while then dies at: > > > >=== package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3 === > > +++ cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && cm3 -ship $R > >ARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' +++ > >--- building in FreeBSD4 --- > > > >ignoring ../src/m3overrides > > > > > >Fatal Error: duplicate link info: M3Path.i3 > > > > *** execution of cm3 -build -DROOT='/big/home2/mika/2/cm3-cvs/cm3' $RARGS && > > cm3 -ship $RARGS -DROOT='/big/home2/mika/2/cm3-cvs/cm3' failed *** > > > > > >The reason I'm doing this, by the way, is that I'm having trouble > >sharing pickles between an amd64 and i386 system and wanted to ensure I > >have recent CM3 distributions on both systems before starting to debug > >the problem. > > > >It appears I can write pickles on i386 and read them on amd64 without > >trouble, but not the other way around (and I am not using any out-of-range > >values, I don't think). > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 8 01:44:57 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 7 Aug 2010 19:44:57 -0400 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: References: Message-ID: <15EA2A2D-8D4F-4749-9FA1-0C58BC2690FE@cs.purdue.edu> I can add a few Hudson nodes sometime. Both AMD64 Linux and Solaris Sparc. 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 7 Aug 2010, at 10:30, Jay K wrote: > > Hey, I'm hoping we can get more people helping more. > > Coding, features, fixing bugs, etc. > > > However one of the easiest things I'd like to see is a few more Hudson nodes. > > > Is anyone out there running e.g. NetBSD on x86 or AMD64? > They would be the easiest, sort of, to setup. I will help anyone. > Or Solaris on SPARC (replace mine) or x86? (Yes I know about opencsw, but the network > topology is seemingly difficult.) > > > Or heck, Linux or OpenBSD on x86? (replace mine) > > > x86/AMD64 in particular has better availability of Java VMs, which we need. > Or, Linux now has good across the board Java support. > > > And can setup dynamic DNS or has static IP? > > > We could use NT386 but I know the setup might not be so easy. > > > There are other viable machines, e.g. one of the new or old Linux/mips. > Or likely some of the obscure systems like HP-UX, AIX, Irix. > If anyone here is actively running one of these, keeps machine on, speak up. > (At some point, I'd like to have Hudson wake-on-lan the machines, > or have the machines scheduled to wake up daily check for work, and then > back to sleep after completing any queued work; the second option > doesn't require Hudson support.) > > > The machine can be quite low end. > Many of mine are old laptops, or very old either way. > Around $200, years ago. > > > Any other projects in the system people are interested in helping out on, with > time/coding, please speak up if you need help. If you need ideas, or assistance, etc. > > > Thanks, > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Sun Aug 8 04:51:30 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sat, 07 Aug 2010 19:51:30 -0700 Subject: [M3devel] CM3 problems Message-ID: <20100808025130.354B71A20BC@async.async.caltech.edu> With what I found in CVS today, I see the following for a program of mine I'm trying to compile: new source -> compiling Main.m3 "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr 3 warnings encountered ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:225: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:225: error: this is the insn: (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ (set (reg:SI 112) (const_int 0 [0x0])) (set (reg:SI 110) (plus:SI (ashift:SI (reg:SI 112) (const_int 2 [0x2])) (reg:SI 110))) (set (reg:SI 111) (plus:SI (ashift:SI (reg:SI 112) (const_int 2 [0x2])) (reg:SI 111))) (set (mem/s/c:BLK (reg:SI 110) [0 M3_A91vEE_trade+0 S24 A64]) (mem/s/c:BLK (reg:SI 111) [0 M3_A91vEE_trade+0 S24 A32])) (use (reg:SI 112)) ]) 586 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 112) (expr_list:REG_UNUSED (reg:SI 111) (expr_list:REG_UNUSED (reg:SI 110) (nil))))) ../src/Main.m3:225: confused by earlier errors, bailing out m3_backend => 4 m3cc (aka cm3cg) failed compiling: Main.mc compilation failed => not building program "ximport" Fatal Error: package build failed Any hints as to how to deal with this? I have optimization turned off. Mika From jay.krell at cornell.edu Sun Aug 8 05:09:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 8 Aug 2010 03:09:07 +0000 Subject: [M3devel] CM3 problems In-Reply-To: <20100808025130.354B71A20BC@async.async.caltech.edu> References: <20100808025130.354B71A20BC@async.async.caltech.edu> Message-ID: Not very useful of me, but standard questions: Is this your code? Can we see it? Is cm3cg current? Can you try with optimization? ?-O1, -O2, -O3 cheating perhaps to use optimization? ?? They should all generally work..though you should also generally never see such errors.. Tony might ask to see the IR via ? rm -rf FreeBSD4? ? cm3 -keep ? ordinarily the *.mc files are deleted? ? cm3cg -y FreeBSD4/Main.mc?? (it goes to stderr not stdout)? ?or more accurately (at least for other purposes)? ? rm -rf FreeBSD4? ? cm3 -keep -commands? ? find the cm3cg command? ? cd FreBSD4 ? rerun cm3cg command but with -y added? though I probably won't be able to glean anything from it. Is cm3cg 4.3.0 or 4.3.5? I'm curious. I upgraded is recently to 4.3.5. ? I don't know of any problems it fixed or caused. cm3cg -v will tell you. This is FreeBSD5/x86, right? Can you try on any other machines? e.g. your Alpha? eh. that's probably changing too much. x86 is by far the register-poorest. Search the web for this error? Maybe it occurs using C as well with "similar" code? ?- Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Sat, 7 Aug 2010 19:51:30 -0700 > From: mika at async.async.caltech.edu > Subject: [M3devel] CM3 problems > > With what I found in CVS today, I see the following for a program > of mine I'm trying to compile: > > > new source -> compiling Main.m3 > "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr > 3 warnings encountered > ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': > ../src/Main.m3:225: error: unable to find a register to spill in class 'CREG' > ../src/Main.m3:225: error: this is the insn: > (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ > (set (reg:SI 112) > (const_int 0 [0x0])) > (set (reg:SI 110) > (plus:SI (ashift:SI (reg:SI 112) > (const_int 2 [0x2])) > (reg:SI 110))) > (set (reg:SI 111) > (plus:SI (ashift:SI (reg:SI 112) > (const_int 2 [0x2])) > (reg:SI 111))) > (set (mem/s/c:BLK (reg:SI 110) [0 M3_A91vEE_trade+0 S24 A64]) > (mem/s/c:BLK (reg:SI 111) [0 M3_A91vEE_trade+0 S24 A32])) > (use (reg:SI 112)) > ]) 586 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 112) > (expr_list:REG_UNUSED (reg:SI 111) > (expr_list:REG_UNUSED (reg:SI 110) > (nil))))) > ../src/Main.m3:225: confused by earlier errors, bailing out > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: Main.mc > compilation failed => not building program "ximport" > Fatal Error: package build failed > > Any hints as to how to deal with this? I have optimization turned off. > > Mika > > From mika at async.async.caltech.edu Sun Aug 8 16:58:57 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Sun, 08 Aug 2010 07:58:57 -0700 Subject: [M3devel] CM3 problems In-Reply-To: References: <20100808025130.354B71A20BC@async.async.caltech.edu> Message-ID: <20100808145857.3D7D41A20AF@async.async.caltech.edu> I ran upgrade.sh before compiling, so everything should be up to date. I'd be happy to give you the code (yes it's mine) but I'm not sure how many libraries it depends on. Same thing happens with optimization (-O2). (133)rover:~/u/calarm/regress/ximport/FreeBSD4>/usr/local/cm3//bin/cm3cg -march=i586 -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m32 -O3 -Wuninitialized -gstabs+ Main.mc -o Main.ms ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:225: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:225: error: this is the insn: (insn:HI 5 4 6 2 ../src/Main.m3:204 (parallel [ (set (reg:SI 0 ax [69]) (const_int 0 [0x0])) (set (reg:SI 5 di [67]) (plus:SI (ashift:SI (reg:SI 0 ax [69]) (const_int 2 [0x2])) (reg:SI 5 di [67]))) (set (reg/f:SI 4 si [68]) (plus:SI (ashift:SI (reg:SI 0 ax [69]) (const_int 2 [0x2])) (reg/f:SI 16 argp))) (set (mem/s/c:BLK (reg:SI 5 di [67]) [0 M3_A91vEE_trade+0 S24 A64]) (mem/s/c:BLK (reg/f:SI 16 argp) [0 M3_A91vEE_trade+0 S24 A32])) (use (reg:SI 0 ax [69])) ]) 586 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [69]) (expr_list:REG_UNUSED (reg/f:SI 4 si [68]) (expr_list:REG_UNUSED (reg:SI 5 di [67]) (nil))))) ../src/Main.m3:225: confused by earlier errors, bailing out I copied the derived directory (after running cm3 -x -keep) to http://rover.gcapltd.com/~mika/ximport-bug-FreeBSD4/ in case anyone wants to peek at it. I also put Main.m3 in there so you can see what's going on. Nested procedures... but nothing that looks too weird to me. Mika Jay K writes: > >Not very useful of me=2C but standard questions: > > >Is this your code? >Can we see it? >Is cm3cg current? >Can you try with optimization? >=A0-O1=2C -O2=2C -O3 cheating perhaps to use optimization=A0=20 >=A0=A0 They should all generally work..though you should also generally nev= >er see such errors.. >Tony might ask to see the IR via=20 >=A0 rm -rf FreeBSD4=A0=20 >=A0 cm3 -keep =A0 ordinarily the *.mc files are deleted=A0=20 >=A0 cm3cg -y FreeBSD4/Main.mc=A0=A0 (it goes to stderr not stdout)=A0=20 >=A0or more accurately (at least for other purposes)=A0=20 >=A0 rm -rf FreeBSD4=A0=20 > >=A0 cm3 -keep -commands=A0=20 >=A0 find the cm3cg command=A0=20 >=A0 cd FreBSD4=20 >=A0 rerun cm3cg command but with -y added=A0=20 From wagner at elegosoft.com Mon Aug 9 10:21:36 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 10:21:36 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Message-ID: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> After several weeks (months?) of little activity I was able to setup some more build and regression test jobs on the opencsw.org machines. There are now sets of jobs for SOLsun built on Solaris 10 (works) run on current10s.opencsw.org SOLsun built on Solaris 9 (seems now to work, too) run on current9s I386_SOLARIS built on Solaris 10 (still several problems) run on current10x For the instruction and exhilaration of those willing to read on I'll give some details. One of the problems was entirely my own fault. In the regression defs.sh script, about a dozen error messages were written to 1>2 instead of 1>&2. The second correct form redirects stdout to stderr, while the first just writes the contents to a file named 2 :-/ It's not that I haven't got enough experience with writing shell scripts (in fact I've done that hundreds of times), but I must have made a typo in one place in the original file version and copied that to many other locations. It is interesting that I didn't notice that for years, though I've looked at it all the time. I was getting desparate about unexplained stops in the scripts tonight when finally a veil seems to have been removed from my eyes. Currently I know of two other problems running our builds and tests on the opencsw machines. 1. cvs update does not work on current10x (Solaris on x86) when run from Hudson. It does work on current10s and current9s. It does work if I disable compression (but can do that only for all jobs, which would be a bad pessimization). It does work if I run it from the command line. cvs co in Hudson works OK, too. All attempts to update workspaces by Hudson fail with [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 8:59:46 PM UTC" ... cvs [update aborted]: end of file from server (consult above messages if any) FATAL: CVS failed. exit code=1 Obviously, there are no above messages to consult. If anybody has any ideas what could be causing this, I'd like to hear it. Without update, all the jobs will run rather long on that machine. All machines run exactly the same version of CVS. 2. Copying any archive files out again via ssh and scp has not worked yet. I still need to investigate this, but have hope that I can make this work. Builds for more target platforms should be setup on those machines, but it's tedious work. If anybody wants to take a try, that will be appreciated. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 9 11:36:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 9 Aug 2010 09:36:39 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: Very nice. Copying & cvs could be separate tasks, run on login? ("login" being a machine, not a "time"). In fact these all share one filesystem & could share workspaces, albeit with serialization? The problem isn't sharing without serialization? The other interesting platforms are AMD64_SOLARIS and SPARC64_SOLARIS. Should consider SPARC32_SOLARIS & drop SOLgnu & SOLsun. It is already implemented. Thanks, - Jay/phone > Date: Mon, 9 Aug 2010 10:21:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > After several weeks (months?) of little activity I was able to setup > some more build and regression test jobs on the opencsw.org machines. > > There are now sets of jobs for > > SOLsun built on Solaris 10 (works) run on current10s.opencsw.org > SOLsun built on Solaris 9 (seems now to work, too) run on current9s > I386_SOLARIS built on Solaris 10 (still several problems) run on current10x > > For the instruction and exhilaration of those willing to read on I'll > give some details. > > One of the problems was entirely my own fault. In the regression defs.sh > script, about a dozen error messages were written to 1>2 instead of 1>&2. > The second correct form redirects stdout to stderr, while the first just > writes the contents to a file named 2 :-/ It's not that I haven't got > enough experience with writing shell scripts (in fact I've done that > hundreds of times), but I must have made a typo in one place in the > original file version and copied that to many other locations. It is > interesting that I didn't notice that for years, though I've looked > at it all the time. I was getting desparate about unexplained stops > in the scripts tonight when finally a veil seems to have been removed > from my eyes. > > Currently I know of two other problems running our builds and tests > on the opencsw machines. > > 1. cvs update does not work on current10x (Solaris on x86) when run from > Hudson. > It does work on current10s and current9s. > It does work if I disable compression (but can do that only for all jobs, > which would be a bad pessimization). > It does work if I run it from the command line. > cvs co in Hudson works OK, too. > > All attempts to update workspaces by Hudson fail with > > [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 8:59:46 PM UTC" > ... > cvs [update aborted]: end of file from server (consult above > messages if any) > FATAL: CVS failed. exit code=1 > > Obviously, there are no above messages to consult. > If anybody has any ideas what could be causing this, I'd like to > hear it. Without update, all the jobs will run rather long on that > machine. > All machines run exactly the same version of CVS. > > 2. Copying any archive files out again via ssh and scp has not worked > yet. I still need to investigate this, but have hope that I can make > this work. > > Builds for more target platforms should be setup on those machines, > but it's tedious work. If anybody wants to take a try, that will be > appreciated. > > 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 wagner at elegosoft.com Mon Aug 9 12:28:56 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 12:28:56 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: <20100809122856.m94sq8ulss4scwgo@mail.elegosoft.com> Quoting Jay K : > Very nice. > > Copying & cvs could be separate tasks, run on login? ("login" being > a machine, not a "time"). Copying out will probably be no problem, but CVS is tightly integrated into Hudson and needs to be (for impact tracking). I already considered running cvs on login.opencsw.org, but don't know how to configure that. > In fact these all share one filesystem & could share workspaces, > albeit with serialization? The problem isn't sharing without > serialization? No, the workspaces are different (hostname in paths). That would be an imaginable setup, too. But Hudson likes to keep jobs separate and isolated, so it would be even more work I think. > The other interesting platforms are AMD64_SOLARIS and > SPARC64_SOLARIS. Should consider SPARC32_SOLARIS & drop SOLgnu & > SOLsun. It is already implemented. Yes, I should have used SPARC32_SOLARIS instead of SOLsun; will change that at the next opportunity. Do I just need to set the TARGET to compile for those platforms (including AMD64/SPARC64) on those machines? Olaf >> Date: Mon, 9 Aug 2010 10:21:36 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] Short status of CM3 Hudson regression testing >> on opencsw.org machines >> >> After several weeks (months?) of little activity I was able to setup >> some more build and regression test jobs on the opencsw.org machines. >> >> There are now sets of jobs for >> >> SOLsun built on Solaris 10 (works) run on current10s.opencsw.org >> SOLsun built on Solaris 9 (seems now to work, too) run on current9s >> I386_SOLARIS built on Solaris 10 (still several problems) run on >> current10x >> >> For the instruction and exhilaration of those willing to read on I'll >> give some details. >> >> One of the problems was entirely my own fault. In the regression defs.sh >> script, about a dozen error messages were written to 1>2 instead of 1>&2. >> The second correct form redirects stdout to stderr, while the first just >> writes the contents to a file named 2 :-/ It's not that I haven't got >> enough experience with writing shell scripts (in fact I've done that >> hundreds of times), but I must have made a typo in one place in the >> original file version and copied that to many other locations. It is >> interesting that I didn't notice that for years, though I've looked >> at it all the time. I was getting desparate about unexplained stops >> in the scripts tonight when finally a veil seems to have been removed >> from my eyes. >> >> Currently I know of two other problems running our builds and tests >> on the opencsw machines. >> >> 1. cvs update does not work on current10x (Solaris on x86) when run from >> Hudson. >> It does work on current10s and current9s. >> It does work if I disable compression (but can do that only for >> all jobs, >> which would be a bad pessimization). >> It does work if I run it from the command line. >> cvs co in Hudson works OK, too. >> >> All attempts to update workspaces by Hudson fail with >> >> [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 >> 8:59:46 PM UTC" >> ... >> cvs [update aborted]: end of file from server (consult above >> messages if any) >> FATAL: CVS failed. exit code=1 >> >> Obviously, there are no above messages to consult. >> If anybody has any ideas what could be causing this, I'd like to >> hear it. Without update, all the jobs will run rather long on that >> machine. >> All machines run exactly the same version of CVS. >> >> 2. Copying any archive files out again via ssh and scp has not worked >> yet. I still need to investigate this, but have hope that I can make >> this work. >> >> Builds for more target platforms should be setup on those machines, >> but it's tedious work. If anybody wants to take a try, that will be >> appreciated. >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 9 12:48:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 9 Aug 2010 10:48:31 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809122856.m94sq8ulss4scwgo@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com>, , <20100809122856.m94sq8ulss4scwgo@mail.elegosoft.com> Message-ID: Do I just need to set the TARGET to compile for those platforms (including AMD64/SPARC64) on those machines? Um, yes, should just work? (famous lie..). Should even be able to use the same cm3cg. - Jay > Date: Mon, 9 Aug 2010 12:28:56 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting Jay K : > > > Very nice. > > > > Copying & cvs could be separate tasks, run on login? ("login" being > > a machine, not a "time"). > Copying out will probably be no problem, but CVS is tightly integrated > into Hudson and needs to be (for impact tracking). I already considered > running cvs on login.opencsw.org, but don't know how to configure that. > > > In fact these all share one filesystem & could share workspaces, > > albeit with serialization? The problem isn't sharing without > > serialization? > > No, the workspaces are different (hostname in paths). > > That would be an imaginable setup, too. But Hudson likes to keep > jobs separate and isolated, so it would be even more work I think. > > > The other interesting platforms are AMD64_SOLARIS and > > SPARC64_SOLARIS. Should consider SPARC32_SOLARIS & drop SOLgnu & > > SOLsun. It is already implemented. > > Yes, I should have used SPARC32_SOLARIS instead of SOLsun; will change > that at the next opportunity. > > Do I just need to set the TARGET to compile for those platforms (including > AMD64/SPARC64) on those machines? > > Olaf > > >> Date: Mon, 9 Aug 2010 10:21:36 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> > >> After several weeks (months?) of little activity I was able to setup > >> some more build and regression test jobs on the opencsw.org machines. > >> > >> There are now sets of jobs for > >> > >> SOLsun built on Solaris 10 (works) run on current10s.opencsw.org > >> SOLsun built on Solaris 9 (seems now to work, too) run on current9s > >> I386_SOLARIS built on Solaris 10 (still several problems) run on > >> current10x > >> > >> For the instruction and exhilaration of those willing to read on I'll > >> give some details. > >> > >> One of the problems was entirely my own fault. In the regression defs.sh > >> script, about a dozen error messages were written to 1>2 instead of 1>&2. > >> The second correct form redirects stdout to stderr, while the first just > >> writes the contents to a file named 2 :-/ It's not that I haven't got > >> enough experience with writing shell scripts (in fact I've done that > >> hundreds of times), but I must have made a typo in one place in the > >> original file version and copied that to many other locations. It is > >> interesting that I didn't notice that for years, though I've looked > >> at it all the time. I was getting desparate about unexplained stops > >> in the scripts tonight when finally a veil seems to have been removed > >> from my eyes. > >> > >> Currently I know of two other problems running our builds and tests > >> on the opencsw machines. > >> > >> 1. cvs update does not work on current10x (Solaris on x86) when run from > >> Hudson. > >> It does work on current10s and current9s. > >> It does work if I disable compression (but can do that only for > >> all jobs, > >> which would be a bad pessimization). > >> It does work if I run it from the command line. > >> cvs co in Hudson works OK, too. > >> > >> All attempts to update workspaces by Hudson fail with > >> > >> [cm3] $ cvs -q -z3 update -PdC -D "Sunday, August 8, 2010 > >> 8:59:46 PM UTC" > >> ... > >> cvs [update aborted]: end of file from server (consult above > >> messages if any) > >> FATAL: CVS failed. exit code=1 > >> > >> Obviously, there are no above messages to consult. > >> If anybody has any ideas what could be causing this, I'd like to > >> hear it. Without update, all the jobs will run rather long on that > >> machine. > >> All machines run exactly the same version of CVS. > >> > >> 2. Copying any archive files out again via ssh and scp has not worked > >> yet. I still need to investigate this, but have hope that I can make > >> this work. > >> > >> Builds for more target platforms should be setup on those machines, > >> but it's tedious work. If anybody wants to take a try, that will be > >> appreciated. > >> > >> 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 dam at opencsw.org Mon Aug 9 13:47:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Aug 2010 13:47:12 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: Hi Olaf, Am 09.08.2010 um 10:21 schrieb Olaf Wagner: > Currently I know of two other problems running our builds and tests > on the opencsw machines. > > 1. cvs update does not work on current10x (Solaris on x86) when run > from > Hudson. > It does work on current10s and current9s. Interesting. current*s are all running on the same physical machine as zones, whereas current*x are located on a vSphere farm. Do you have a specific command sequence which I can try to reproduce the problem? Are you using cvs stable (1.11.23) or feature (1.12.13)? > It does work if I disable compression (but can do that only for > all jobs, > which would be a bad pessimization). > It does work if I run it from the command line. > cvs co in Hudson works OK, too. This sounds like a strange and subtle bug... Best regards -- Dago From rcolebur at SCIRES.COM Mon Aug 9 16:27:24 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 9 Aug 2010 10:27:24 -0400 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: References: Message-ID: Windows is my current platform for Modula-3. I can make available machines for various flavors of Windows. I don't understand much about the current Hudson automation, but I am willing to learn and to do some customization for support on Windows. I also have some old Apple iBook notebooks that I could enlist, if these would help. I also have a very old HP-UX machine that would need some work to get running again. I also have a Sun workstation that hasn't been booted up in a few years. I think it has Solaris 9 on it, but I am pretty sure we could replace the OS with Solaris 10 or something else. Let me know if any of these are needed. Regards, Randy -----Original Message----- From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Saturday, August 07, 2010 10:30 AM To: m3devel Subject: [M3devel] more Hudson nodes? more help in general? Hey, I'm hoping we can get more people helping more. Coding, features, fixing bugs, etc. However one of the easiest things I'd like to see is a few more Hudson nodes. Is anyone out there running e.g. NetBSD on x86 or AMD64? ? They would be the easiest, sort of, to setup. I will help anyone. ? Or Solaris on SPARC (replace mine) or x86? (Yes I know about opencsw, but the network ? topology is seemingly difficult.) Or heck, Linux or OpenBSD on x86? (replace mine) x86/AMD64 in particular has better availability of Java VMs, which we need. Or, Linux now has good across the board Java support. And can setup dynamic DNS or has static IP? We could use NT386 but I know the setup might not be so easy. There are other viable machines, e.g. one of the new or old Linux/mips. Or likely some of the obscure systems like HP-UX, AIX, Irix. If anyone here is actively running one of these, keeps machine on, speak up. (At some point, I'd like to have Hudson wake-on-lan the machines, or have the machines scheduled to wake up daily check for work, and then back to sleep after completing any queued work; the second option doesn't require Hudson support.) The machine can be quite low end. Many of mine are old laptops, or very old either way. Around $200, years ago. Any other projects in the system people are interested in helping out on, with ? time/coding, please speak up if you need help. If you need ideas, or assistance, etc. Thanks, ?- Jay From wagner at elegosoft.com Mon Aug 9 17:01:24 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 17:01:24 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> Message-ID: <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> Quoting Dagobert Michelsen : > Hi Olaf, > > Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >> Currently I know of two other problems running our builds and tests >> on the opencsw machines. >> >> 1. cvs update does not work on current10x (Solaris on x86) when run from >> Hudson. >> It does work on current10s and current9s. > > Interesting. current*s are all running on the same physical machine as zones, > whereas current*x are located on a vSphere farm. Do you have a specific > command sequence which I can try to reproduce the problem? I'm not yet able to reproduce it manually; I only see it in the Hudson jobs (failing right away when computing the changelog). If you want, I can setup a job for test purposes and you can get Hudson access. > Are you using cvs stable (1.11.23) or feature (1.12.13)? Stable. I'll try with 1.12.13, too (haven't seen that around). Is it installed anywhere?? >> It does work if I disable compression (but can do that only for all jobs, >> which would be a bad pessimization). >> It does work if I run it from the command line. >> cvs co in Hudson works OK, too. > > This sounds like a strange and subtle bug... Yep. 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 Mon Aug 9 17:13:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 09 Aug 2010 17:13:30 +0200 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: References: Message-ID: <20100809171330.fe3pc7nwgwosg4wg@mail.elegosoft.com> Quoting "Coleburn, Randy" : > Windows is my current platform for Modula-3. I can make available > machines for various flavors of Windows. > > I don't understand much about the current Hudson automation, but I > am willing to learn and to do some customization for support on > Windows. > > I also have some old Apple iBook notebooks that I could enlist, if > these would help. I also have a very old HP-UX machine that would > need some work to get running again. > > I also have a Sun workstation that hasn't been booted up in a few > years. I think it has Solaris 9 on it, but I am pretty sure we > could replace the OS with Solaris 10 or something else. > > Let me know if any of these are needed. Another (more reliable) Windows client would be great, but be forwarned that it won't be easy to get it running in combination with the existing scripts. We had to get another commercial ssh daemon IIRC, and me and Jay have hunted down failures for weeks. The Apple iBook may also be of interest (if it is not too slow). What version of MacOS is it running? My own old Powerbook (400 MHz) is currently running the PPC_DARWIN tests. Sun should be fairly well covered, if we succeed with all the opencsw.org machines, and Antony Hosking has also a machine currently running the tinderbox tests, IIRC. IMO we could probably do without Tinderbox soon. I'm not sure if anybody is really interested in HPUX. For me this seems to have mostly hostorical value :-) I may be wrong there of course... Olaf > Regards, > Randy > > > -----Original Message----- > From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K > Sent: Saturday, August 07, 2010 10:30 AM > To: m3devel > Subject: [M3devel] more Hudson nodes? more help in general? > > > Hey, I'm hoping we can get more people helping more. > > Coding, features, fixing bugs, etc. > > > However one of the easiest things I'd like to see is a few more Hudson nodes. > > > Is anyone out there running e.g. NetBSD on x86 or AMD64? > ? They would be the easiest, sort of, to setup. I will help anyone. > ? Or Solaris on SPARC (replace mine) or x86? (Yes I know about > opencsw, but the network > ? topology is seemingly difficult.) > > > Or heck, Linux or OpenBSD on x86? (replace mine) > > > x86/AMD64 in particular has better availability of Java VMs, which we need. > Or, Linux now has good across the board Java support. > > > And can setup dynamic DNS or has static IP? > > > We could use NT386 but I know the setup might not be so easy. > > > There are other viable machines, e.g. one of the new or old Linux/mips. > Or likely some of the obscure systems like HP-UX, AIX, Irix. > If anyone here is actively running one of these, keeps machine on, speak up. > (At some point, I'd like to have Hudson wake-on-lan the machines, > or have the machines scheduled to wake up daily check for work, and then > back to sleep after completing any queued work; the second option > doesn't require Hudson support.) > > > The machine can be quite low end. > Many of mine are old laptops, or very old either way. > Around $200, years ago. > > > Any other projects in the system people are interested in helping > out on, with > ? time/coding, please speak up if you need help. If you need ideas, > or assistance, etc. > > > Thanks, > ?- 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 m3 at sol42.com Mon Aug 9 22:17:35 2010 From: m3 at sol42.com (m3 at sol42.com) Date: Mon, 9 Aug 2010 22:17:35 +0200 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: <20100809171330.fe3pc7nwgwosg4wg@mail.elegosoft.com> References: <20100809171330.fe3pc7nwgwosg4wg@mail.elegosoft.com> Message-ID: Hello. I know we are talking about machines that would be running 24/7, but maybe is there a way for a machine to automatically join a Hudson server and do some work when it is booted say twice a week (which I concede is the opposite of continuous integration)? I have some machines that might be of help, but I don't do much with them nowadays and cannot afford to keep them up all the time: - mostly silent: a Mac mini G4, 1,5GHz, 1GB RAM, Mac OS X 10.5.8; - somewhat noisy: a Sun Ultra 60, 2*450 MHz, 2GB RAM, Solaris 10 from some time before Oracle changed Solaris terms (meaning it won't be upgraded, but I keep the JDK current); - like having an airport inside the room: an IRIX machine Hudson will not run on due to lack of a 1.5 JRE :( but if I keep it on in winter then I can turn off heating. Regards. -Daniel From dabenavidesd at yahoo.es Tue Aug 10 01:00:49 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 9 Aug 2010 23:00:49 +0000 (GMT) Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: Message-ID: <573133.51461.qm@web29705.mail.ird.yahoo.com> Hi all: well in that case it would be probably less efficient to have running over and over probably if you are brave enough to virtualize it might be possible to load a good server with some virtual machines which later you can teleport like Vbox over a net and run for testing of the concept like you say twice a week. Tere is one in aprticular probably useful for the Irix the SimOS, which run natevely in the IRIX and others now, also other platforms like DEC Alpha and power PC. I have downloaded an article from computer world library so you can check for details in the efficient virtualization affairs, it requires sign up to grab it (see http://www.vision6.com.au/ch/21104/2d34n3v/1289505/1b836s789.html ) so you can have it from here (just accept secure certificate and agree to add an exception): https://168.176.86.16/~danielb/Virtualization_APC.pdf As for the JVM you can have Loongson JVM for free ( http://debian.printk.org/software-loongson/jvm/jdk15_mips_080103.tar.gz ) in those machines to do the JVM part of the job, though not sure if hat works for your needs and available resources and system implementation. Thanks in advance --- El lun, 9/8/10, m3 at sol42.com escribi?: > De: m3 at sol42.com > Asunto: Re: [M3devel] more Hudson nodes? more help in general? > Para: "m3devel" > Fecha: lunes, 9 de agosto, 2010 15:17 > Hello. I know we are talking > about machines that would be running 24/7, but maybe is > there a way for a machine to automatically join a Hudson > server and do some work when it is booted say twice a week > (which I concede is the opposite of continuous > integration)? > I have some machines that might be of help, but I don't do > much with them nowadays and cannot afford to keep them up > all the time: > - mostly silent: a Mac mini G4, 1,5GHz, 1GB RAM, Mac OS X > 10.5.8; > - somewhat noisy: a Sun Ultra 60, 2*450 MHz, 2GB RAM, > Solaris 10 from some time before Oracle changed Solaris > terms (meaning it won't be upgraded, but I keep the JDK > current); > - like having an airport inside the room: an IRIX machine > Hudson will not run on due to lack of a 1.5 JRE :( but if I > keep it on in winter then I can turn off heating. > Regards. > -Daniel From jay.krell at cornell.edu Tue Aug 10 02:29:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 10 Aug 2010 00:29:20 +0000 Subject: [M3devel] more Hudson nodes? more help in general? In-Reply-To: <573133.51461.qm@web29705.mail.ird.yahoo.com> References: , <573133.51461.qm@web29705.mail.ird.yahoo.com> Message-ID: Virtualization works great for x86, AMD64. Less so for others. There is "gxemul" but it is less widely used, probably harder to use, I haven't tried it yet. It might work for MIPS esp. There was a project to remove the assembly code from Sun's Java. As a result, Java is well available on any architecture on Linux. e.g. we have Linux/powerpc, Linux/sparc, and I expect we'll soon have Linux/mips, in Hudson. But so far it is Linux-only where this work can be used, as far as I know. I was thinking we could move the Elego NT386 VM. Probably should run sysprep /generalize on it first. Sparc, PowerPC do have some sorts of virtualization, but it is kind of more esoteric and I suspect harder to use. e.g. on Solaris, on AIX. I hadn't heard of SimOS and maybe others. More research to do.. Thanks, - Jay > Date: Mon, 9 Aug 2010 23:00:49 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; m3 at sol42.com > Subject: Re: [M3devel] more Hudson nodes? more help in general? > > Hi all: > well in that case it would be probably less efficient to have running over and over probably if you are brave enough to virtualize it might be possible to load a good server with some virtual machines which later you can teleport like Vbox over a net and run for testing of the concept like you say twice a week. Tere is one in aprticular probably useful for the Irix the SimOS, which run natevely in the IRIX and others now, also other platforms like DEC Alpha and power PC. > I have downloaded an article from computer world library so you can check for details in the efficient virtualization affairs, it requires sign up to grab it (see http://www.vision6.com.au/ch/21104/2d34n3v/1289505/1b836s789.html ) so you can have it from here (just accept secure certificate and agree to add an exception): > https://168.176.86.16/~danielb/Virtualization_APC.pdf > As for the JVM you can have Loongson JVM for free ( http://debian.printk.org/software-loongson/jvm/jdk15_mips_080103.tar.gz ) in those machines to do the JVM part of the job, though not sure if hat works for your needs and available resources and system implementation. > > Thanks in advance > > > --- El lun, 9/8/10, m3 at sol42.com escribi?: > > > De: m3 at sol42.com > > Asunto: Re: [M3devel] more Hudson nodes? more help in general? > > Para: "m3devel" > > Fecha: lunes, 9 de agosto, 2010 15:17 > > Hello. I know we are talking > > about machines that would be running 24/7, but maybe is > > there a way for a machine to automatically join a Hudson > > server and do some work when it is booted say twice a week > > (which I concede is the opposite of continuous > > integration)? > > I have some machines that might be of help, but I don't do > > much with them nowadays and cannot afford to keep them up > > all the time: > > - mostly silent: a Mac mini G4, 1,5GHz, 1GB RAM, Mac OS X > > 10.5.8; > > - somewhat noisy: a Sun Ultra 60, 2*450 MHz, 2GB RAM, > > Solaris 10 from some time before Oracle changed Solaris > > terms (meaning it won't be upgraded, but I keep the JDK > > current); > > - like having an airport inside the room: an IRIX machine > > Hudson will not run on due to lack of a 1.5 JRE :( but if I > > keep it on in winter then I can turn off heating. > > Regards. > > -Daniel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Aug 10 07:54:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 10 Aug 2010 07:54:30 +0200 Subject: [M3devel] assembler problems on Solaris 9 Message-ID: <20100810075430.u41viro3q8ksckcw@mail.elegosoft.com> example: assembler failed assembling: RTHeapMap.ms /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: unknown opcode ".hidden" /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: statement syntax assemble => 1 see http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/20/console 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 dam at opencsw.org Tue Aug 10 09:34:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 10 Aug 2010 09:34:23 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> Message-ID: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Hi Olaf, Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > Quoting Dagobert Michelsen : >> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>> Currently I know of two other problems running our builds and tests >>> on the opencsw machines. >>> >>> 1. cvs update does not work on current10x (Solaris on x86) when >>> run from >>> Hudson. >>> It does work on current10s and current9s. >> >> Interesting. current*s are all running on the same physical machine >> as zones, >> whereas current*x are located on a vSphere farm. Do you have a >> specific >> command sequence which I can try to reproduce the problem? > > I'm not yet able to reproduce it manually; I only see it in the > Hudson jobs (failing right away when computing the changelog). > > If you want, I can setup a job for test purposes and you can get > Hudson access. I can't promise I can fix this but if you set something up I may look in the next few days. >> Are you using cvs stable (1.11.23) or feature (1.12.13)? > > Stable. I'll try with 1.12.13, too (haven't seen that around). > Is it installed anywhere?? That is here: /opt/csw/cvs-feature/bin/cvs Best regards -- Dago From wagner at elegosoft.com Tue Aug 10 13:43:49 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 10 Aug 2010 13:43:49 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Message-ID: <20100810134349.5votgjcz48408sow@mail.elegosoft.com> Quoting Dagobert Michelsen : > Hi Olaf, > > Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> Quoting Dagobert Michelsen : >>> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>>> Currently I know of two other problems running our builds and tests >>>> on the opencsw machines. >>>> >>>> 1. cvs update does not work on current10x (Solaris on x86) when run from >>>> Hudson. >>>> It does work on current10s and current9s. >>> >>> Interesting. current*s are all running on the same physical >>> machine as zones, >>> whereas current*x are located on a vSphere farm. Do you have a specific >>> command sequence which I can try to reproduce the problem? >> >> I'm not yet able to reproduce it manually; I only see it in the >> Hudson jobs (failing right away when computing the changelog). >> >> If you want, I can setup a job for test purposes and you can get >> Hudson access. > > I can't promise I can fix this but if you set something up I may look > in the next few days. I finally managed to reproduce the problem in the build step of a Hudson job, and got this after enabling tracing: -> rename(CVS/Entries.Backup,CVS/Entries) -> unlink_file(CVS/Entries.Log) cvs update: inflate: unknown compression method cvs [update aborted]: reading from server: I/O error -> Lock_Cleanup() Finished: FAILURE Is there a different/an older gzip library on current10x? see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >>> Are you using cvs stable (1.11.23) or feature (1.12.13)? >> >> Stable. I'll try with 1.12.13, too (haven't seen that around). >> Is it installed anywhere?? > > That is here: > /opt/csw/cvs-feature/bin/cvs Will it help if I try that, or does it use the same gzip lib? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 10 15:33:04 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 10 Aug 2010 15:33:04 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100810134349.5votgjcz48408sow@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> <20100810134349.5votgjcz48408sow@mail.elegosoft.com> Message-ID: <20100810153304.06vsgq848wcow0ok@mail.elegosoft.com> Quoting Olaf Wagner : > Quoting Dagobert Michelsen : > >> Hi Olaf, >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >>> Quoting Dagobert Michelsen : >>>> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>>>> Currently I know of two other problems running our builds and tests >>>>> on the opencsw machines. >>>>> >>>>> 1. cvs update does not work on current10x (Solaris on x86) when run from >>>>> Hudson. >>>>> It does work on current10s and current9s. >>>> >>>> Interesting. current*s are all running on the same physical >>>> machine as zones, >>>> whereas current*x are located on a vSphere farm. Do you have a specific >>>> command sequence which I can try to reproduce the problem? >>> >>> I'm not yet able to reproduce it manually; I only see it in the >>> Hudson jobs (failing right away when computing the changelog). >>> >>> If you want, I can setup a job for test purposes and you can get >>> Hudson access. >> >> I can't promise I can fix this but if you set something up I may look >> in the next few days. > > I finally managed to reproduce the problem in the build step of > a Hudson job, and got this after enabling tracing: > > -> rename(CVS/Entries.Backup,CVS/Entries) > -> unlink_file(CVS/Entries.Log) > cvs update: inflate: unknown compression method > cvs [update aborted]: reading from server: I/O error > -> Lock_Cleanup() > Finished: FAILURE > > Is there a different/an older gzip library on current10x? > > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >>>> Are you using cvs stable (1.11.23) or feature (1.12.13)? >>> >>> Stable. I'll try with 1.12.13, too (haven't seen that around). >>> Is it installed anywhere?? >> >> That is here: >> /opt/csw/cvs-feature/bin/cvs 1.12.13 says cvs update: inflate: invalid distance too far back cvs [update aborted]: reading from server: I/O error Finished: FAILURE Any ideas? 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 dabenavidesd at yahoo.es Tue Aug 10 23:04:39 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 10 Aug 2010 21:04:39 +0000 (GMT) Subject: [M3devel] assembler problems on Solaris 9 In-Reply-To: <20100810075430.u41viro3q8ksckcw@mail.elegosoft.com> Message-ID: <755920.39660.qm@web29709.mail.ird.yahoo.com> Hi all: not sure what the message meant but it seems like the code generator is broken putting labels in assembly code body. What is the assembler's version number, if it is natively generated (self-hosted not cross-assembled even from a previous other m3cg cross-assembler), assuming so, where are supposed to be placed labels to match system's assembly? Probably useful to print m3-sys/m3cgcat comparing with repository working correspondent and/or m3-tools/hexdump. Though compiler is enabled to do such a cross assembly process I wonder how that might be the result of compiling it with a different m3cg if that fails too, it might be a problem in the assembly emitting, what do you think? Thanks in advance --- El mar, 10/8/10, Olaf Wagner escribi?: > De: Olaf Wagner > Asunto: [M3devel] assembler problems on Solaris 9 > Para: m3devel at elegosoft.com > Fecha: martes, 10 de agosto, 2010 00:54 > example: > > assembler failed assembling: RTHeapMap.ms > /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: unknown > opcode ".hidden" > /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: > statement syntax > assemble => 1 > > see http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/20/console > > 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 dabenavidesd at yahoo.es Tue Aug 10 23:54:47 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 10 Aug 2010 21:54:47 +0000 (GMT) Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100810153304.06vsgq848wcow0ok@mail.elegosoft.com> Message-ID: <542991.69565.qm@web29701.mail.ird.yahoo.com> Hi all: I was rethinking but it seems you caught a bug either inside opencsw.org or elego system (incompatible versions). Probably will be a lot easier with some special techniques like this ones I assume you're not able to do that but just in case you do sshfs: http://www.linux-mag.com/id/7820 How critical is this process for it? see suggestions for it see pages 34 and 42 about centralizing control over files in contrast of distributed and the efficiency in I/O transmission and suggestions for improving it in a white "paper" book of "The Shortcut guide to Eliminating Insecure and Unreliable File Transfer Methods" if that might help (again just accept the security domain error and add the security exception) https://168.176.86.16/~danielb/SGEIU-complete.pdf downloaded from http://nexus.realtimepublishers.com/sgeiu.php you will need an account and take a survey on the topic if you might In such a case where you are allowed sshfs might be an interesting option it requires user space file system but if the performance is not critical perhaps we can think about it, can we, might be interesting for a windows setting, etc? Thanks in advance, hope it helps --- El mar, 10/8/10, Olaf Wagner escribi?: > De: Olaf Wagner > Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > Para: m3devel at elegosoft.com > Fecha: martes, 10 de agosto, 2010 08:33 > Quoting Olaf Wagner : > > > Quoting Dagobert Michelsen : > > > >> Hi Olaf, > >> > >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >>> Quoting Dagobert Michelsen : > >>>> Am 09.08.2010 um 10:21 schrieb Olaf > Wagner: > >>>>> Currently I know of two other problems > running our builds and tests > >>>>> on the opencsw machines. > >>>>> > >>>>> 1. cvs update does not work on > current10x (Solaris on x86) when run from > >>>>> Hudson. > >>>>> It does work on current10s and > current9s. > >>>> > >>>> Interesting. current*s are all running on > the same physical > >>>> machine as zones, > >>>> whereas current*x are located on a vSphere > farm. Do you have a specific > >>>> command sequence which I can try to > reproduce the problem? > >>> > >>> I'm not yet able to reproduce it manually; I > only see it in the > >>> Hudson jobs (failing right away when computing > the changelog). > >>> > >>> If you want, I can setup a job for test > purposes and you can get > >>> Hudson access. > >> > >> I can't promise I can fix this but if you set > something up I may look > >> in the next few days. > > > > I finally managed to reproduce the problem in the > build step of > > a Hudson job, and got this after enabling tracing: > > > > -> rename(CVS/Entries.Backup,CVS/Entries) > > -> unlink_file(CVS/Entries.Log) > > cvs update: inflate: unknown compression method > > cvs [update aborted]: reading from server: I/O error > > -> Lock_Cleanup() > > Finished: FAILURE > > > > Is there a different/an older gzip library on > current10x? > > > > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > > > >>>> Are you using cvs stable (1.11.23) or > feature (1.12.13)? > >>> > >>> Stable. I'll try with 1.12.13, too (haven't > seen that around). > >>> Is it installed anywhere?? > >> > >> That is here: > >> /opt/csw/cvs-feature/bin/cvs > > 1.12.13 says > > cvs update: inflate: invalid distance too far back cvs > [update > aborted]: reading from server: I/O error > Finished: FAILURE > > Any ideas? > > 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 Wed Aug 11 09:18:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 11 Aug 2010 09:18:38 +0200 Subject: [M3devel] assembler problems on Solaris 9 In-Reply-To: <755920.39660.qm@web29709.mail.ird.yahoo.com> References: <755920.39660.qm@web29709.mail.ird.yahoo.com> Message-ID: <20100811091838.u9g8wp7oso404cso@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > not sure what the message meant but it seems like the code generator > is broken putting labels in assembly code body. What is the > assembler's version number, if it is natively generated (self-hosted > not cross-assembled even from a previous other m3cg > cross-assembler), assuming so, where are supposed to be placed > labels to match system's assembly? Probably useful to print > m3-sys/m3cgcat comparing with repository working correspondent > and/or m3-tools/hexdump. Though compiler is enabled to do such a > cross assembly process I wonder how that might be the result of > compiling it with a different m3cg if that fails too, it might be a > problem in the assembly emitting, what do you think? It seems to be an incompatibility with the Solaris 9 assembler. The Solaris 10 assembler works fine. We haven't built the system on Solaris 9 for a long time I think. Or have we? Perhaps this is gcc 4.5 related? No, it's using 4.3, but in two different setups: WI=/home/m3hudson/current9s/work/cm3-inst/current9s/solsun + /home/m3hudson/current9s/work/cm3-inst/current9s/solsun/current/bin/cm3cg --version Modula-3 backend (GCC) version 4.3.5 (sparc-sun-solaris2.10) compiled by GNU C version 4.2.0 (gccfss), GMP version 4.2.1, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 + /home/m3hudson/current9s/work/cm3-inst/current9s/solsun/last-ok/bin/cm3cg --version Modula-3 backend (GCC) version 4.3.0 (sparc-sun-solaris2) compiled by GNU C version 3.4.3 (csl-sol210-3_4-branch+sol_rpath), GMP version 4.2.1, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 I guess our current configuration in m3cc/src/m3makefile is wrong for Solaris 9, or that gcc target was broken in the upgrade from 4.3.0 to 4.3.5. Olaf > Thanks in advance > > --- El mar, 10/8/10, Olaf Wagner escribi?: > >> De: Olaf Wagner >> Asunto: [M3devel] assembler problems on Solaris 9 >> Para: m3devel at elegosoft.com >> Fecha: martes, 10 de agosto, 2010 00:54 >> example: >> >> assembler failed assembling: RTHeapMap.ms >> /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: unknown >> opcode ".hidden" >> /usr/ccs/bin/as: "RTHeapRep.ms", line 1237: error: >> statement syntax >> assemble => 1 >> >> see >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/20/console >> >> 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 >> >> > > > > -- 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 Wed Aug 11 09:26:35 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 11 Aug 2010 09:26:35 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <542991.69565.qm@web29701.mail.ird.yahoo.com> References: <542991.69565.qm@web29701.mail.ird.yahoo.com> Message-ID: <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > I was rethinking but it seems you caught a bug either inside > opencsw.org or elego system (incompatible versions). There are no incompatible CVS versions. Birch is running 1.12.13, and current9s.opencsw.org is running both that and 1.11.23. Should all work fine theoretically. It may be a problem with the proxy we need to use to get out from opencsw.org, too. Olaf PS: I don't think cool user space file systems from Linux will help us on Solaris systems, nor will opencsw.org change their general setup and policies for us. > Probably will be a lot easier with some special techniques like this ones > I assume you're not able to do that but just in case you do sshfs: > http://www.linux-mag.com/id/7820 > How critical is this process for it? see suggestions for it see > pages 34 and 42 about centralizing control over files in contrast of > distributed and the efficiency in I/O transmission and suggestions > for improving it in a white "paper" book of "The Shortcut guide to > Eliminating Insecure > and Unreliable File Transfer Methods" if that might help (again just > accept the security domain error and add the security exception) > https://168.176.86.16/~danielb/SGEIU-complete.pdf > downloaded from > http://nexus.realtimepublishers.com/sgeiu.php > you will need an account and take a survey on the topic if you might > In such a case where you are allowed sshfs might be an interesting > option it requires user space file system but if the performance is > not critical perhaps we can think about it, can we, might be > interesting for a windows setting, etc? > > Thanks in advance, hope it helps > > --- El mar, 10/8/10, Olaf Wagner escribi?: > >> De: Olaf Wagner >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing >> on opencsw.org machines >> Para: m3devel at elegosoft.com >> Fecha: martes, 10 de agosto, 2010 08:33 >> Quoting Olaf Wagner : >> >> > Quoting Dagobert Michelsen : >> > >> >> Hi Olaf, >> >> >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> >>> Quoting Dagobert Michelsen : >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf >> Wagner: >> >>>>> Currently I know of two other problems >> running our builds and tests >> >>>>> on the opencsw machines. >> >>>>> >> >>>>> 1. cvs update does not work on >> current10x (Solaris on x86) when run from >> >>>>> Hudson. >> >>>>> It does work on current10s and >> current9s. >> >>>> >> >>>> Interesting. current*s are all running on >> the same physical >> >>>> machine as zones, >> >>>> whereas current*x are located on a vSphere >> farm. Do you have a specific >> >>>> command sequence which I can try to >> reproduce the problem? >> >>> >> >>> I'm not yet able to reproduce it manually; I >> only see it in the >> >>> Hudson jobs (failing right away when computing >> the changelog). >> >>> >> >>> If you want, I can setup a job for test >> purposes and you can get >> >>> Hudson access. >> >> >> >> I can't promise I can fix this but if you set >> something up I may look >> >> in the next few days. >> > >> > I finally managed to reproduce the problem in the >> build step of >> > a Hudson job, and got this after enabling tracing: >> > >> > -> rename(CVS/Entries.Backup,CVS/Entries) >> > -> unlink_file(CVS/Entries.Log) >> > cvs update: inflate: unknown compression method >> > cvs [update aborted]: reading from server: I/O error >> > -> Lock_Cleanup() >> > Finished: FAILURE >> > >> > Is there a different/an older gzip library on >> current10x? >> > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >> > >> >>>> Are you using cvs stable (1.11.23) or >> feature (1.12.13)? >> >>> >> >>> Stable. I'll try with 1.12.13, too (haven't >> seen that around). >> >>> Is it installed anywhere?? >> >> >> >> That is here: >> >> /opt/csw/cvs-feature/bin/cvs >> >> 1.12.13 says >> >> cvs update: inflate: invalid distance too far back cvs >> [update >> aborted]: reading from server: I/O error >> Finished: FAILURE >> >> Any ideas? >> >> 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 >> >> > > > > -- 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 Wed Aug 11 18:10:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 11 Aug 2010 16:10:24 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> Message-ID: Olaf I think we should do a bit more research here, but I also think we have a few easy options. - build our own cvs, put it in $HOME/bin. - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. - Jay > Date: Wed, 11 Aug 2010 09:26:35 +0200 > From: wagner at elegosoft.com > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting "Daniel Alejandro Benavides D." : > > > Hi all: > > I was rethinking but it seems you caught a bug either inside > > opencsw.org or elego system (incompatible versions). > > There are no incompatible CVS versions. Birch is running 1.12.13, > and current9s.opencsw.org is running both that and 1.11.23. Should > all work fine theoretically. > > It may be a problem with the proxy we need to use to get out from > opencsw.org, too. > > Olaf > > PS: I don't think cool user space file systems from Linux will help > us on Solaris systems, nor will opencsw.org change their general > setup and policies for us. > > > Probably will be a lot easier with some special techniques like this ones > > I assume you're not able to do that but just in case you do sshfs: > > http://www.linux-mag.com/id/7820 > > How critical is this process for it? see suggestions for it see > > pages 34 and 42 about centralizing control over files in contrast of > > distributed and the efficiency in I/O transmission and suggestions > > for improving it in a white "paper" book of "The Shortcut guide to > > Eliminating Insecure > > and Unreliable File Transfer Methods" if that might help (again just > > accept the security domain error and add the security exception) > > https://168.176.86.16/~danielb/SGEIU-complete.pdf > > downloaded from > > http://nexus.realtimepublishers.com/sgeiu.php > > you will need an account and take a survey on the topic if you might > > In such a case where you are allowed sshfs might be an interesting > > option it requires user space file system but if the performance is > > not critical perhaps we can think about it, can we, might be > > interesting for a windows setting, etc? > > > > Thanks in advance, hope it helps > > > > --- El mar, 10/8/10, Olaf Wagner escribi?: > > > >> De: Olaf Wagner > >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> Para: m3devel at elegosoft.com > >> Fecha: martes, 10 de agosto, 2010 08:33 > >> Quoting Olaf Wagner : > >> > >> > Quoting Dagobert Michelsen : > >> > > >> >> Hi Olaf, > >> >> > >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >> >>> Quoting Dagobert Michelsen : > >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf > >> Wagner: > >> >>>>> Currently I know of two other problems > >> running our builds and tests > >> >>>>> on the opencsw machines. > >> >>>>> > >> >>>>> 1. cvs update does not work on > >> current10x (Solaris on x86) when run from > >> >>>>> Hudson. > >> >>>>> It does work on current10s and > >> current9s. > >> >>>> > >> >>>> Interesting. current*s are all running on > >> the same physical > >> >>>> machine as zones, > >> >>>> whereas current*x are located on a vSphere > >> farm. Do you have a specific > >> >>>> command sequence which I can try to > >> reproduce the problem? > >> >>> > >> >>> I'm not yet able to reproduce it manually; I > >> only see it in the > >> >>> Hudson jobs (failing right away when computing > >> the changelog). > >> >>> > >> >>> If you want, I can setup a job for test > >> purposes and you can get > >> >>> Hudson access. > >> >> > >> >> I can't promise I can fix this but if you set > >> something up I may look > >> >> in the next few days. > >> > > >> > I finally managed to reproduce the problem in the > >> build step of > >> > a Hudson job, and got this after enabling tracing: > >> > > >> > -> rename(CVS/Entries.Backup,CVS/Entries) > >> > -> unlink_file(CVS/Entries.Log) > >> > cvs update: inflate: unknown compression method > >> > cvs [update aborted]: reading from server: I/O error > >> > -> Lock_Cleanup() > >> > Finished: FAILURE > >> > > >> > Is there a different/an older gzip library on > >> current10x? > >> > > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >> > > >> >>>> Are you using cvs stable (1.11.23) or > >> feature (1.12.13)? > >> >>> > >> >>> Stable. I'll try with 1.12.13, too (haven't > >> seen that around). > >> >>> Is it installed anywhere?? > >> >> > >> >> That is here: > >> >> /opt/csw/cvs-feature/bin/cvs > >> > >> 1.12.13 says > >> > >> cvs update: inflate: invalid distance too far back cvs > >> [update > >> aborted]: reading from server: I/O error > >> Finished: FAILURE > >> > >> Any ideas? > >> > >> 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 > >> > >> > > > > > > > > > > > > -- > 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 Thu Aug 12 01:42:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 11 Aug 2010 23:42:39 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, , <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com>, Message-ID: Hm, that this means by the way, I think, is the compressed data is not recognized as valid. e.g. it isn't -z3 being rejected, but the data from the server. Maybe the network is flaky and corrupting the data? That aside, I wonder if we could try -z1, -z2, -z4, -z5, etc. ay at xlin2:~/src/cvs-1.12.13/cvs-1.12.13$ grep "unknown compre" */* zlib/inflate.c: strm->msg = (char *)"unknown compression method"; zlib/inflate.c: strm->msg = (char *)"unknown compression method"; if (BITS(4) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } ... #ifdef GUNZIP case FLAGS: NEEDBITS(16); state->flags = (int)(hold); if ((state->flags & 0xff) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dabenavidesd at yahoo.es Date: Wed, 11 Aug 2010 16:10:24 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Olaf I think we should do a bit more research here, but I also think we have a few easy options. - build our own cvs, put it in $HOME/bin. - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. - Jay > Date: Wed, 11 Aug 2010 09:26:35 +0200 > From: wagner at elegosoft.com > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting "Daniel Alejandro Benavides D." : > > > Hi all: > > I was rethinking but it seems you caught a bug either inside > > opencsw.org or elego system (incompatible versions). > > There are no incompatible CVS versions. Birch is running 1.12.13, > and current9s.opencsw.org is running both that and 1.11.23. Should > all work fine theoretically. > > It may be a problem with the proxy we need to use to get out from > opencsw.org, too. > > Olaf > > PS: I don't think cool user space file systems from Linux will help > us on Solaris systems, nor will opencsw.org change their general > setup and policies for us. > > > Probably will be a lot easier with some special techniques like this ones > > I assume you're not able to do that but just in case you do sshfs: > > http://www.linux-mag.com/id/7820 > > How critical is this process for it? see suggestions for it see > > pages 34 and 42 about centralizing control over files in contrast of > > distributed and the efficiency in I/O transmission and suggestions > > for improving it in a white "paper" book of "The Shortcut guide to > > Eliminating Insecure > > and Unreliable File Transfer Methods" if that might help (again just > > accept the security domain error and add the security exception) > > https://168.176.86.16/~danielb/SGEIU-complete.pdf > > downloaded from > > http://nexus.realtimepublishers.com/sgeiu.php > > you will need an account and take a survey on the topic if you might > > In such a case where you are allowed sshfs might be an interesting > > option it requires user space file system but if the performance is > > not critical perhaps we can think about it, can we, might be > > interesting for a windows setting, etc? > > > > Thanks in advance, hope it helps > > > > --- El mar, 10/8/10, Olaf Wagner escribi?: > > > >> De: Olaf Wagner > >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> Para: m3devel at elegosoft.com > >> Fecha: martes, 10 de agosto, 2010 08:33 > >> Quoting Olaf Wagner : > >> > >> > Quoting Dagobert Michelsen : > >> > > >> >> Hi Olaf, > >> >> > >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >> >>> Quoting Dagobert Michelsen : > >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf > >> Wagner: > >> >>>>> Currently I know of two other problems > >> running our builds and tests > >> >>>>> on the opencsw machines. > >> >>>>> > >> >>>>> 1. cvs update does not work on > >> current10x (Solaris on x86) when run from > >> >>>>> Hudson. > >> >>>>> It does work on current10s and > >> current9s. > >> >>>> > >> >>>> Interesting. current*s are all running on > >> the same physical > >> >>>> machine as zones, > >> >>>> whereas current*x are located on a vSphere > >> farm. Do you have a specific > >> >>>> command sequence which I can try to > >> reproduce the problem? > >> >>> > >> >>> I'm not yet able to reproduce it manually; I > >> only see it in the > >> >>> Hudson jobs (failing right away when computing > >> the changelog). > >> >>> > >> >>> If you want, I can setup a job for test > >> purposes and you can get > >> >>> Hudson access. > >> >> > >> >> I can't promise I can fix this but if you set > >> something up I may look > >> >> in the next few days. > >> > > >> > I finally managed to reproduce the problem in the > >> build step of > >> > a Hudson job, and got this after enabling tracing: > >> > > >> > -> rename(CVS/Entries.Backup,CVS/Entries) > >> > -> unlink_file(CVS/Entries.Log) > >> > cvs update: inflate: unknown compression method > >> > cvs [update aborted]: reading from server: I/O error > >> > -> Lock_Cleanup() > >> > Finished: FAILURE > >> > > >> > Is there a different/an older gzip library on > >> current10x? > >> > > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >> > > >> >>>> Are you using cvs stable (1.11.23) or > >> feature (1.12.13)? > >> >>> > >> >>> Stable. I'll try with 1.12.13, too (haven't > >> seen that around). > >> >>> Is it installed anywhere?? > >> >> > >> >> That is here: > >> >> /opt/csw/cvs-feature/bin/cvs > >> > >> 1.12.13 says > >> > >> cvs update: inflate: invalid distance too far back cvs > >> [update > >> aborted]: reading from server: I/O error > >> Finished: FAILURE > >> > >> Any ideas? > >> > >> 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 > >> > >> > > > > > > > > > > > > -- > 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 Thu Aug 12 05:27:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 12 Aug 2010 03:27:14 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, , , <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com>, , , Message-ID: I propose this is the next thing to try: - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. thereby removing -z3 from any jobs on this node, leaving all the rest unchanged. I realize $HOME/bin might not be it, but like $HOME/$(uname -n)/bin or such. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dabenavidesd at yahoo.es Date: Wed, 11 Aug 2010 23:42:39 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Hm, that this means by the way, I think, is the compressed data is not recognized as valid. e.g. it isn't -z3 being rejected, but the data from the server. Maybe the network is flaky and corrupting the data? That aside, I wonder if we could try -z1, -z2, -z4, -z5, etc. ay at xlin2:~/src/cvs-1.12.13/cvs-1.12.13$ grep "unknown compre" */* zlib/inflate.c: strm->msg = (char *)"unknown compression method"; zlib/inflate.c: strm->msg = (char *)"unknown compression method"; if (BITS(4) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } ... #ifdef GUNZIP case FLAGS: NEEDBITS(16); state->flags = (int)(hold); if ((state->flags & 0xff) != Z_DEFLATED) { strm->msg = (char *)"unknown compression method"; state->mode = BAD; break; } - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; dabenavidesd at yahoo.es Date: Wed, 11 Aug 2010 16:10:24 +0000 CC: m3devel at elegosoft.com; dam at baltic-online.de Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines Olaf I think we should do a bit more research here, but I also think we have a few easy options. - build our own cvs, put it in $HOME/bin. - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin - drop in a stub cvs in $HOME/bin that remove the -z option and then execs the "real" cvs, like how we convince Hudson that our java -version is ok. - Jay > Date: Wed, 11 Aug 2010 09:26:35 +0200 > From: wagner at elegosoft.com > To: dabenavidesd at yahoo.es > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > Quoting "Daniel Alejandro Benavides D." : > > > Hi all: > > I was rethinking but it seems you caught a bug either inside > > opencsw.org or elego system (incompatible versions). > > There are no incompatible CVS versions. Birch is running 1.12.13, > and current9s.opencsw.org is running both that and 1.11.23. Should > all work fine theoretically. > > It may be a problem with the proxy we need to use to get out from > opencsw.org, too. > > Olaf > > PS: I don't think cool user space file systems from Linux will help > us on Solaris systems, nor will opencsw.org change their general > setup and policies for us. > > > Probably will be a lot easier with some special techniques like this ones > > I assume you're not able to do that but just in case you do sshfs: > > http://www.linux-mag.com/id/7820 > > How critical is this process for it? see suggestions for it see > > pages 34 and 42 about centralizing control over files in contrast of > > distributed and the efficiency in I/O transmission and suggestions > > for improving it in a white "paper" book of "The Shortcut guide to > > Eliminating Insecure > > and Unreliable File Transfer Methods" if that might help (again just > > accept the security domain error and add the security exception) > > https://168.176.86.16/~danielb/SGEIU-complete.pdf > > downloaded from > > http://nexus.realtimepublishers.com/sgeiu.php > > you will need an account and take a survey on the topic if you might > > In such a case where you are allowed sshfs might be an interesting > > option it requires user space file system but if the performance is > > not critical perhaps we can think about it, can we, might be > > interesting for a windows setting, etc? > > > > Thanks in advance, hope it helps > > > > --- El mar, 10/8/10, Olaf Wagner escribi?: > > > >> De: Olaf Wagner > >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing > >> on opencsw.org machines > >> Para: m3devel at elegosoft.com > >> Fecha: martes, 10 de agosto, 2010 08:33 > >> Quoting Olaf Wagner : > >> > >> > Quoting Dagobert Michelsen : > >> > > >> >> Hi Olaf, > >> >> > >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: > >> >>> Quoting Dagobert Michelsen : > >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf > >> Wagner: > >> >>>>> Currently I know of two other problems > >> running our builds and tests > >> >>>>> on the opencsw machines. > >> >>>>> > >> >>>>> 1. cvs update does not work on > >> current10x (Solaris on x86) when run from > >> >>>>> Hudson. > >> >>>>> It does work on current10s and > >> current9s. > >> >>>> > >> >>>> Interesting. current*s are all running on > >> the same physical > >> >>>> machine as zones, > >> >>>> whereas current*x are located on a vSphere > >> farm. Do you have a specific > >> >>>> command sequence which I can try to > >> reproduce the problem? > >> >>> > >> >>> I'm not yet able to reproduce it manually; I > >> only see it in the > >> >>> Hudson jobs (failing right away when computing > >> the changelog). > >> >>> > >> >>> If you want, I can setup a job for test > >> purposes and you can get > >> >>> Hudson access. > >> >> > >> >> I can't promise I can fix this but if you set > >> something up I may look > >> >> in the next few days. > >> > > >> > I finally managed to reproduce the problem in the > >> build step of > >> > a Hudson job, and got this after enabling tracing: > >> > > >> > -> rename(CVS/Entries.Backup,CVS/Entries) > >> > -> unlink_file(CVS/Entries.Log) > >> > cvs update: inflate: unknown compression method > >> > cvs [update aborted]: reading from server: I/O error > >> > -> Lock_Cleanup() > >> > Finished: FAILURE > >> > > >> > Is there a different/an older gzip library on > >> current10x? > >> > > >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console > >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console > >> > > >> >>>> Are you using cvs stable (1.11.23) or > >> feature (1.12.13)? > >> >>> > >> >>> Stable. I'll try with 1.12.13, too (haven't > >> seen that around). > >> >>> Is it installed anywhere?? > >> >> > >> >> That is here: > >> >> /opt/csw/cvs-feature/bin/cvs > >> > >> 1.12.13 says > >> > >> cvs update: inflate: invalid distance too far back cvs > >> [update > >> aborted]: reading from server: I/O error > >> Finished: FAILURE > >> > >> Any ideas? > >> > >> 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 > >> > >> > > > > > > > > > > > > -- > 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 wagner at elegosoft.com Thu Aug 12 09:12:07 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 09:12:07 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> Message-ID: <20100812091207.piy2cdcsiswoowg4@mail.elegosoft.com> Quoting Jay K : > Olaf I think we should do a bit more research here, but I also think > we have a few easy options. > > - build our own cvs, put it in $HOME/bin. > - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin > - drop in a stub cvs in $HOME/bin that remove the -z option and > then execs the "real" cvs, like how > we convince Hudson that our java -version is ok. These are not really easy, as we need to make Hudson running in the Winstone container started by ssh pick up the correct CVS. We don't want to start it explicitly in our jobs. But of course it can be done, I just haven't found the time to try. BTW, it is not evident that our self-built CVS would work better, especially, if the problem is really in the compressen library. I won't have time to do much until the weekend. Olaf > - Jay > >> Date: Wed, 11 Aug 2010 09:26:35 +0200 >> From: wagner at elegosoft.com >> To: dabenavidesd at yahoo.es >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Short status of CM3 Hudson regression >> testing on opencsw.org machines >> >> Quoting "Daniel Alejandro Benavides D." : >> >> > Hi all: >> > I was rethinking but it seems you caught a bug either inside >> > opencsw.org or elego system (incompatible versions). >> >> There are no incompatible CVS versions. Birch is running 1.12.13, >> and current9s.opencsw.org is running both that and 1.11.23. Should >> all work fine theoretically. >> >> It may be a problem with the proxy we need to use to get out from >> opencsw.org, too. >> >> Olaf >> >> PS: I don't think cool user space file systems from Linux will help >> us on Solaris systems, nor will opencsw.org change their general >> setup and policies for us. >> >> > Probably will be a lot easier with some special techniques like this ones >> > I assume you're not able to do that but just in case you do sshfs: >> > http://www.linux-mag.com/id/7820 >> > How critical is this process for it? see suggestions for it see >> > pages 34 and 42 about centralizing control over files in contrast of >> > distributed and the efficiency in I/O transmission and suggestions >> > for improving it in a white "paper" book of "The Shortcut guide to >> > Eliminating Insecure >> > and Unreliable File Transfer Methods" if that might help (again just >> > accept the security domain error and add the security exception) >> > https://168.176.86.16/~danielb/SGEIU-complete.pdf >> > downloaded from >> > http://nexus.realtimepublishers.com/sgeiu.php >> > you will need an account and take a survey on the topic if you might >> > In such a case where you are allowed sshfs might be an interesting >> > option it requires user space file system but if the performance is >> > not critical perhaps we can think about it, can we, might be >> > interesting for a windows setting, etc? >> > >> > Thanks in advance, hope it helps >> > >> > --- El mar, 10/8/10, Olaf Wagner escribi?: >> > >> >> De: Olaf Wagner >> >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing >> >> on opencsw.org machines >> >> Para: m3devel at elegosoft.com >> >> Fecha: martes, 10 de agosto, 2010 08:33 >> >> Quoting Olaf Wagner : >> >> >> >> > Quoting Dagobert Michelsen : >> >> > >> >> >> Hi Olaf, >> >> >> >> >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> >> >>> Quoting Dagobert Michelsen : >> >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf >> >> Wagner: >> >> >>>>> Currently I know of two other problems >> >> running our builds and tests >> >> >>>>> on the opencsw machines. >> >> >>>>> >> >> >>>>> 1. cvs update does not work on >> >> current10x (Solaris on x86) when run from >> >> >>>>> Hudson. >> >> >>>>> It does work on current10s and >> >> current9s. >> >> >>>> >> >> >>>> Interesting. current*s are all running on >> >> the same physical >> >> >>>> machine as zones, >> >> >>>> whereas current*x are located on a vSphere >> >> farm. Do you have a specific >> >> >>>> command sequence which I can try to >> >> reproduce the problem? >> >> >>> >> >> >>> I'm not yet able to reproduce it manually; I >> >> only see it in the >> >> >>> Hudson jobs (failing right away when computing >> >> the changelog). >> >> >>> >> >> >>> If you want, I can setup a job for test >> >> purposes and you can get >> >> >>> Hudson access. >> >> >> >> >> >> I can't promise I can fix this but if you set >> >> something up I may look >> >> >> in the next few days. >> >> > >> >> > I finally managed to reproduce the problem in the >> >> build step of >> >> > a Hudson job, and got this after enabling tracing: >> >> > >> >> > -> rename(CVS/Entries.Backup,CVS/Entries) >> >> > -> unlink_file(CVS/Entries.Log) >> >> > cvs update: inflate: unknown compression method >> >> > cvs [update aborted]: reading from server: I/O error >> >> > -> Lock_Cleanup() >> >> > Finished: FAILURE >> >> > >> >> > Is there a different/an older gzip library on >> >> current10x? >> >> > >> >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console >> >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >> >> > >> >> >>>> Are you using cvs stable (1.11.23) or >> >> feature (1.12.13)? >> >> >>> >> >> >>> Stable. I'll try with 1.12.13, too (haven't >> >> seen that around). >> >> >>> Is it installed anywhere?? >> >> >> >> >> >> That is here: >> >> >> /opt/csw/cvs-feature/bin/cvs >> >> >> >> 1.12.13 says >> >> >> >> cvs update: inflate: invalid distance too far back cvs >> >> [update >> >> aborted]: reading from server: I/O error >> >> Finished: FAILURE >> >> >> >> Any ideas? >> >> >> >> 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 >> >> >> >> >> > >> > >> > >> > >> >> >> >> -- >> 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 >> > -- 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 Thu Aug 12 09:14:19 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 09:14:19 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, , <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com>, Message-ID: <20100812091419.etw0y1yngo0ccosg@mail.elegosoft.com> We can try anything from the command line or via a build step in a Hudson job, but the configuration options for CVS in Hudson are rather limited. At least at this level... Olaf Quoting Jay K : > Hm, that this means by the way, I think, is the compressed data is > not recognized as valid. e.g. it isn't -z3 being rejected, but the > data from the server. > Maybe the network is flaky and corrupting the data? > > That aside, I wonder if we could try -z1, -z2, -z4, -z5, etc. > > ay at xlin2:~/src/cvs-1.12.13/cvs-1.12.13$ grep "unknown compre" */* > zlib/inflate.c: strm->msg = (char *)"unknown > compression method"; > zlib/inflate.c: strm->msg = (char *)"unknown > compression method"; > > > if (BITS(4) != Z_DEFLATED) { > strm->msg = (char *)"unknown compression method"; > state->mode = BAD; > break; > } > ... > #ifdef GUNZIP > case FLAGS: > NEEDBITS(16); > state->flags = (int)(hold); > if ((state->flags & 0xff) != Z_DEFLATED) { > strm->msg = (char *)"unknown compression method"; > state->mode = BAD; > break; > } > > > > - Jay > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; dabenavidesd at yahoo.es > Date: Wed, 11 Aug 2010 16:10:24 +0000 > CC: m3devel at elegosoft.com; dam at baltic-online.de > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing > on opencsw.org machines > > > > > > > > > Olaf I think we should do a bit more research here, but I also think > we have a few easy options. > > - build our own cvs, put it in $HOME/bin. > - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin > - drop in a stub cvs in $HOME/bin that remove the -z option and > then execs the "real" cvs, like how > we convince Hudson that our java -version is ok. > > - Jay > >> Date: Wed, 11 Aug 2010 09:26:35 +0200 >> From: wagner at elegosoft.com >> To: dabenavidesd at yahoo.es >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Short status of CM3 Hudson regression >> testing on opencsw.org machines >> >> Quoting "Daniel Alejandro Benavides D." : >> >> > Hi all: >> > I was rethinking but it seems you caught a bug either inside >> > opencsw.org or elego system (incompatible versions). >> >> There are no incompatible CVS versions. Birch is running 1.12.13, >> and current9s.opencsw.org is running both that and 1.11.23. Should >> all work fine theoretically. >> >> It may be a problem with the proxy we need to use to get out from >> opencsw.org, too. >> >> Olaf >> >> PS: I don't think cool user space file systems from Linux will help >> us on Solaris systems, nor will opencsw.org change their general >> setup and policies for us. >> >> > Probably will be a lot easier with some special techniques like this ones >> > I assume you're not able to do that but just in case you do sshfs: >> > http://www.linux-mag.com/id/7820 >> > How critical is this process for it? see suggestions for it see >> > pages 34 and 42 about centralizing control over files in contrast of >> > distributed and the efficiency in I/O transmission and suggestions >> > for improving it in a white "paper" book of "The Shortcut guide to >> > Eliminating Insecure >> > and Unreliable File Transfer Methods" if that might help (again just >> > accept the security domain error and add the security exception) >> > https://168.176.86.16/~danielb/SGEIU-complete.pdf >> > downloaded from >> > http://nexus.realtimepublishers.com/sgeiu.php >> > you will need an account and take a survey on the topic if you might >> > In such a case where you are allowed sshfs might be an interesting >> > option it requires user space file system but if the performance is >> > not critical perhaps we can think about it, can we, might be >> > interesting for a windows setting, etc? >> > >> > Thanks in advance, hope it helps >> > >> > --- El mar, 10/8/10, Olaf Wagner escribi?: >> > >> >> De: Olaf Wagner >> >> Asunto: Re: [M3devel] Short status of CM3 Hudson regression testing >> >> on opencsw.org machines >> >> Para: m3devel at elegosoft.com >> >> Fecha: martes, 10 de agosto, 2010 08:33 >> >> Quoting Olaf Wagner : >> >> >> >> > Quoting Dagobert Michelsen : >> >> > >> >> >> Hi Olaf, >> >> >> >> >> >> Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> >> >>> Quoting Dagobert Michelsen : >> >> >>>> Am 09.08.2010 um 10:21 schrieb Olaf >> >> Wagner: >> >> >>>>> Currently I know of two other problems >> >> running our builds and tests >> >> >>>>> on the opencsw machines. >> >> >>>>> >> >> >>>>> 1. cvs update does not work on >> >> current10x (Solaris on x86) when run from >> >> >>>>> Hudson. >> >> >>>>> It does work on current10s and >> >> current9s. >> >> >>>> >> >> >>>> Interesting. current*s are all running on >> >> the same physical >> >> >>>> machine as zones, >> >> >>>> whereas current*x are located on a vSphere >> >> farm. Do you have a specific >> >> >>>> command sequence which I can try to >> >> reproduce the problem? >> >> >>> >> >> >>> I'm not yet able to reproduce it manually; I >> >> only see it in the >> >> >>> Hudson jobs (failing right away when computing >> >> the changelog). >> >> >>> >> >> >>> If you want, I can setup a job for test >> >> purposes and you can get >> >> >>> Hudson access. >> >> >> >> >> >> I can't promise I can fix this but if you set >> >> something up I may look >> >> >> in the next few days. >> >> > >> >> > I finally managed to reproduce the problem in the >> >> build step of >> >> > a Hudson job, and got this after enabling tracing: >> >> > >> >> > -> rename(CVS/Entries.Backup,CVS/Entries) >> >> > -> unlink_file(CVS/Entries.Log) >> >> > cvs update: inflate: unknown compression method >> >> > cvs [update aborted]: reading from server: I/O error >> >> > -> Lock_Cleanup() >> >> > Finished: FAILURE >> >> > >> >> > Is there a different/an older gzip library on >> >> current10x? >> >> > >> >> > see http://hudson.modula3.com:8080/job/opencsw10x-test/21/console >> >> > and http://hudson.modula3.com:8080/job/opencsw10x-test/20/console >> >> > >> >> >>>> Are you using cvs stable (1.11.23) or >> >> feature (1.12.13)? >> >> >>> >> >> >>> Stable. I'll try with 1.12.13, too (haven't >> >> seen that around). >> >> >>> Is it installed anywhere?? >> >> >> >> >> >> That is here: >> >> >> /opt/csw/cvs-feature/bin/cvs >> >> >> >> 1.12.13 says >> >> >> >> cvs update: inflate: invalid distance too far back cvs >> >> [update >> >> aborted]: reading from server: I/O error >> >> Finished: FAILURE >> >> >> >> Any ideas? >> >> >> >> 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 >> >> >> >> >> > >> > >> > >> > >> >> >> >> -- >> 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 >> > -- 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 Thu Aug 12 10:18:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 10:18:15 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <4DBBF376-84FE-4A02-81C8-347275B2BD62@baltic-online.de> References: <542991.69565.qm@web29701.mail.ird.yahoo.com>, <20100811092635.rgfetn8dsso8840k@mail.elegosoft.com> <4DBBF376-84FE-4A02-81C8-347275B2BD62@baltic-online.de> Message-ID: <20100812101815.s0tusa6ji8wwokw0@mail.elegosoft.com> Quoting Dagobert Michelsen : > Hi Jay, > > Am 11.08.2010 um 18:10 schrieb Jay K: >> Olaf I think we should do a bit more research here, but I also >> think we have a few easy options. >> >> - build our own cvs, put it in $HOME/bin. > > I doubt that it would make a difference as the installed OpenCSW package is > build pretty much standard: > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/cvs/trunk/Makefile > >> - copy cvs from another machine (e.g. 9x, 8x), put it in $HOME/bin > > They should be bit-identical as it is the same package installed on > all machines of the same arch. > >> - drop in a stub cvs in $HOME/bin that remove the -z option and >> then execs the "real" cvs, like how >> we convince Hudson that our java -version is ok. > > Have you tried cvs-feature? In contrast to the /opt/csw/bin/cvs it is > linked against > libz explicitly: > > current10x% ldd /opt/csw/bin/cvs > libgss.so.1 => /usr/lib/libgss.so.1 > libkrb5.so.3 => /opt/csw/lib/i386/libkrb5.so.3 > libgen.so.1 => /lib/libgen.so.1 > libk5crypto.so.3 => /opt/csw/lib/i386/libk5crypto.so.3 > libcrypto.so.0.9.8 => /opt/csw/lib/pentium_pro/ libcrypto.so.0.9.8 > libcom_err.so.3 => /opt/csw/lib/i386/libcom_err.so.3 > libxnet.so.1 => /lib/libxnet.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libc.so.1 => /lib/libc.so.1 > libcmd.so.1 => /lib/libcmd.so.1 > libresolv.so.2 => /lib/libresolv.so.2 > libsocket.so.1 => /lib/libsocket.so.1 > libkrb5support.so.0 => /opt/csw/lib/libkrb5support.so.0 > libdl.so.1 => /lib/libdl.so.1 > libmp.so.2 => /lib/libmp.so.2 > libmd.so.1 => /lib/libmd.so.1 > libscf.so.1 => /lib/libscf.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libm.so.2 => /lib/libm.so.2 > > current10x% ldd /opt/csw/cvs-feature/bin/cvs > librt.so.1 => /lib/librt.so.1 > libintl.so.3 => /opt/csw/lib/i386/libintl.so.3 > libiconv.so.2 => /opt/csw/lib/i386/libiconv.so.2 > libc.so.1 => /lib/libc.so.1 > libgssapi_krb5.so.2 => /opt/csw/lib/i386/libgssapi_krb5.so.2 > libkrb5.so.3 => /opt/csw/lib/i386/libkrb5.so.3 > libgen.so.1 => /lib/libgen.so.1 > libk5crypto.so.3 => /opt/csw/lib/i386/libk5crypto.so.3 > libcrypto.so.0.9.8 => /opt/csw/lib/pentium_pro/ libcrypto.so.0.9.8 > libcom_err.so.3 => /opt/csw/lib/i386/libcom_err.so.3 > libnsl.so.1 => /lib/libnsl.so.1 > libsocket.so.1 => /lib/libsocket.so.1 > libz.so => /opt/csw/lib/pentium_pro+mmx/libz.so > libpam.so.1 => /lib/libpam.so.1 > libaio.so.1 => /lib/libaio.so.1 > libmd.so.1 => /lib/libmd.so.1 > libkrb5support.so.0 => /opt/csw/lib/libkrb5support.so.0 > libresolv.so.2 => /lib/libresolv.so.2 > libdl.so.1 => /lib/libdl.so.1 > libmp.so.2 => /lib/libmp.so.2 > libscf.so.1 => /lib/libscf.so.1 > libcmd.so.1 => /lib/libcmd.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libm.so.2 => /lib/libm.so.2 Neither 1.11.23 nor the feature version 1.12.13 work, see http://hudson.modula3.com:8080/view/zzz/job/opencsw10x-test/28/console If there are any more executables to try, we can easily do that via that Hudson job. I'd tend to support the idea of making Hudson use a CVS wrapper which eliminates the -z flag for update for the time being, until we have a better solution. After all, updates should only be small compared to initial checkouts, which work even with compression. All very strange. 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 Thu Aug 12 12:32:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 12:32:23 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Message-ID: <20100812123223.gu47te0g0488gk4c@mail.elegosoft.com> FYI With this change from Jay http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/22/changes we got the first snapshot archive built on Solaris 2.9: http://www.modula3.com/cm3/snaps/cm3-bin-core-SOLsun-d5.9.0-sparc-sun-solaris2.9-2010-08-12-09-40-37.tgz Olaf PS: Tinderbox regression is completely broken currently though, but that must be related to the change of the development line from release branch to trunk as default again. Quoting Dagobert Michelsen : > Hi Olaf, > > Am 09.08.2010 um 17:01 schrieb Olaf Wagner: >> Quoting Dagobert Michelsen : >>> Am 09.08.2010 um 10:21 schrieb Olaf Wagner: >>>> Currently I know of two other problems running our builds and tests >>>> on the opencsw machines. >>>> >>>> 1. cvs update does not work on current10x (Solaris on x86) when run from >>>> Hudson. >>>> It does work on current10s and current9s. >>> >>> Interesting. current*s are all running on the same physical >>> machine as zones, >>> whereas current*x are located on a vSphere farm. Do you have a specific >>> command sequence which I can try to reproduce the problem? >> >> I'm not yet able to reproduce it manually; I only see it in the >> Hudson jobs (failing right away when computing the changelog). >> >> If you want, I can setup a job for test purposes and you can get >> Hudson access. > > I can't promise I can fix this but if you set something up I may look > in the next few days. > >>> Are you using cvs stable (1.11.23) or feature (1.12.13)? >> >> Stable. I'll try with 1.12.13, too (haven't seen that around). >> Is it installed anywhere?? > > That is here: > /opt/csw/cvs-feature/bin/cvs > > > Best regards > > -- Dago -- 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 Thu Aug 12 15:36:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 15:36:42 +0200 Subject: [M3devel] Thread hangs on Solaris 2.9 Message-ID: <20100812153642.vpiofd7vvyssgks4@mail.elegosoft.com> There seems to be a rather extended LongPause in m3tests on Solaris 2.9: [...] --- p037 --- tests Time.LongPause cd ../src/p0/p037 && cm3 -silent -DM3TESTS >SOLsun/stdout.build.raw 2>SOLsun/stderr.build.raw [endless rotation icon here :-)] see http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-SOLsun-opencsw-current9s/8/console 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 Thu Aug 12 20:42:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 12 Aug 2010 20:42:42 +0200 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com> <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com> <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org> Message-ID: <20100812204242.tk9wlc7f480skw8c@mail.elegosoft.com> I have done that now which seems to work: -bash-4.1$ cat ~/bin/cvs #!/bin/sh CVSEXE=/opt/csw/cvs-feature/bin/cvs if [ ! -x $CVSEXE ]; then CVSEXE=/opt/csw/bin/cvs fi if [ ! -x $CVSEXE ]; then echo "$CVSEXE not executable" 1>&2 exit 1 fi if [ `uname -n` = "current10x" ]; then args=`echo "$@" | sed -e 's/-z3 update/update/'` echo "$CVSEXE $args" exec $CVSEXE $args else echo "$CVSEXE $@" exec $CVSEXE $@ fi 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 Aug 12 23:32:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 12 Aug 2010 21:32:37 +0000 Subject: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines In-Reply-To: <20100812204242.tk9wlc7f480skw8c@mail.elegosoft.com> References: <20100809102136.yir8ec9eosg440sw@mail.elegosoft.com>, , <20100809170124.9r6q9circwgwwk80@mail.elegosoft.com>, <12CE30DC-0472-4928-87E9-81FA494DC6F5@opencsw.org>, <20100812204242.tk9wlc7f480skw8c@mail.elegosoft.com> Message-ID: Please check it in where I put the python/java wrapper, thanks. - Jay > Date: Thu, 12 Aug 2010 20:42:42 +0200 > From: wagner at elegosoft.com > To: dam at opencsw.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Short status of CM3 Hudson regression testing on opencsw.org machines > > I have done that now which seems to work: > > -bash-4.1$ cat ~/bin/cvs > #!/bin/sh > > CVSEXE=/opt/csw/cvs-feature/bin/cvs > > if [ ! -x $CVSEXE ]; then > CVSEXE=/opt/csw/bin/cvs > fi > if [ ! -x $CVSEXE ]; then > echo "$CVSEXE not executable" 1>&2 > exit 1 > fi > if [ `uname -n` = "current10x" ]; then > args=`echo "$@" | sed -e 's/-z3 update/update/'` > echo "$CVSEXE $args" > exec $CVSEXE $args > else > echo "$CVSEXE $@" > exec $CVSEXE $@ > fi > > 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 Sat Aug 14 00:59:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 13 Aug 2010 22:59:02 +0000 Subject: [M3devel] fs_rmrec In-Reply-To: <20100813220727.EAD51CC88D@birch.elegosoft.com> References: <20100813220727.EAD51CC88D@birch.elegosoft.com> Message-ID: Olaf, to be sure/clear -- fs_rmrec works now, right? The original and long-term problem was that deleting, or even, enumerating, stale symlinks would fail. There *may* have been a problem around keeping multiple DIRs open at a time and/or deleting while enumerating. My addressing the later concerns, and using fs_rmrec in m3-sys/m3cc, both exacerbated the problem due to the ordering of enumeration and deletion and the layout of m3-sys/m3cc. In either case, I believe it works now, right? Understood that old cm3 remains broken, and intermediate cm3 remains sort of worse. What I mean by all these "sort ofs" is that we used to enumerate and delete "at the same time". Which made it somewhat indeterminate if the symlink or its target was deleted first. I changed the code to delete files, and then directories. Given a symlink like "bar/foo => ../foo", ./foo would be guaranteeably deleted ahead of the symlink pointing to it. - Jay > Date: Sat, 14 Aug 2010 00:07:27 +0000 > To: m3commit at elegosoft.com > From: wagner at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: wagner at birch. 10/08/14 00:07:27 > > Modified files: > cm3/m3-sys/m3tests/src/: m3makefile > > Log message: > wrong again, another attempt: fix rmrec for NT386 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 14 13:10:07 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 14 Aug 2010 13:10:07 +0200 Subject: [M3devel] fs_rmrec In-Reply-To: References: <20100813220727.EAD51CC88D@birch.elegosoft.com> Message-ID: <20100814131007.520xyqx42ok0oo48@mail.elegosoft.com> Quoting Jay K : > Olaf, to be sure/clear -- fs_rmrec works now, right? I thought so, too, but... > The original and long-term problem was that deleting, or even, > enumerating, stale symlinks > would fail. There *may* have been a problem around keeping multiple > DIRs open at a time > and/or deleting while enumerating. My addressing the later concerns, > and using fs_rmrec > in m3-sys/m3cc, both exacerbated the problem due to the ordering of > enumeration and deletion > and the layout of m3-sys/m3cc. > > In either case, I believe it works now, right? I observed several failures in tests. Let's see if I can find some: Here is one: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-I386_SOLARIS-opencsw-current10x/11/console Perhaps the cm3 used there was still too old? I'm sure there were more, but I cannot find them right now. If you're sure it's fixed, we can try it again, no problem. What about the hanging test p037 on Solaris 2.9 though? See http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-SOLsun-opencsw-current9s/8/console Any ideas? Olaf > Understood that old cm3 remains broken, and intermediate cm3 remains > sort of worse. > > > What I mean by all these "sort ofs" is that we used to enumerate and > delete "at the same time". > Which made it somewhat indeterminate if the symlink or its target > was deleted first. > I changed the code to delete files, and then directories. > Given a symlink like "bar/foo => ../foo", ./foo would be > guaranteeably deleted ahead > of the symlink pointing to it. > > - 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 jay.krell at cornell.edu Sat Aug 14 20:51:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 14 Aug 2010 18:51:20 +0000 Subject: [M3devel] fs_rmrec In-Reply-To: <20100814131007.520xyqx42ok0oo48@mail.elegosoft.com> References: <20100813220727.EAD51CC88D@birch.elegosoft.com>, , <20100814131007.520xyqx42ok0oo48@mail.elegosoft.com> Message-ID: > What about the hanging test p037 on Solaris 2.9 though? Oops, right. Perhaps we don't use -lpthread and perhaps we need to. Or perhaps 2.9 uses M:N user:kernel threads and perhaps our code doesn't work with that. Needs some investigation. Tony do you know by chance if the semaphore "parking in signal handler" pthreads code has been used on pre-2.10 Solaris? - Jay > Date: Sat, 14 Aug 2010 13:10:07 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] fs_rmrec > > Quoting Jay K : > > > Olaf, to be sure/clear -- fs_rmrec works now, right? > > I thought so, too, but... > > > The original and long-term problem was that deleting, or even, > > enumerating, stale symlinks > > would fail. There *may* have been a problem around keeping multiple > > DIRs open at a time > > and/or deleting while enumerating. My addressing the later concerns, > > and using fs_rmrec > > in m3-sys/m3cc, both exacerbated the problem due to the ordering of > > enumeration and deletion > > and the layout of m3-sys/m3cc. > > > > In either case, I believe it works now, right? > > I observed several failures in tests. > Let's see if I can find some: > > Here is one: > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-I386_SOLARIS-opencsw-current10x/11/console > > Perhaps the cm3 used there was still too old? > I'm sure there were more, but I cannot find them right now. > > If you're sure it's fixed, we can try it again, no problem. > > What about the hanging test p037 on Solaris 2.9 though? > See > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-SOLsun-opencsw-current9s/8/console > > Any ideas? > > Olaf > > > Understood that old cm3 remains broken, and intermediate cm3 remains > > sort of worse. > > > > > > What I mean by all these "sort ofs" is that we used to enumerate and > > delete "at the same time". > > Which made it somewhat indeterminate if the symlink or its target > > was deleted first. > > I changed the code to delete files, and then directories. > > Given a symlink like "bar/foo => ../foo", ./foo would be > > guaranteeably deleted ahead > > of the symlink pointing to it. > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 15 08:53:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 15 Aug 2010 06:53:25 +0000 Subject: [M3devel] pruning m3cc/gcc? In-Reply-To: <7D2B9349-BCBA-46DE-8465-F50EEBB70F22@cs.purdue.edu> References: , <3423C8E1-7530-4DF3-9B86-2C598C10F7D9@cs.purdue.edu>, , <7D2B9349-BCBA-46DE-8465-F50EEBB70F22@cs.purdue.edu> Message-ID: [old, was going through mail for another reason] btw, treelang is gone in later gcc releases, e.g. 4.5. I think I read they didn't want to maintain it any longer. - Jay > From: hosking at cs.purdue.edu > To: jay.krell at cornell.edu > Date: Mon, 29 Jun 2009 12:01:16 -0400 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pruning m3cc/gcc? > > Please leave treelang. It is a good model for building gcc IR trees > as done by cm3cg. > > On 29 Jun 2009, at 10:42, Jay wrote: > > > > > Ok, presumably then ok to prune it just partly, like intl, libssp, > > libmudflap, libgomp, treelang, beyond that (fixincludes, libgcc) > > would require some checking/testing. Might even be worthwhile to > > "simplify" the m3makefile and reach a compromise that works only by > > some deletion. > > Really I wish somehow gmp/mpfr built more quickly. I often delete > > their source locally but can't commit that. > > > > - Jay > > > > ________________________________ > >> From: hosking at cs.purdue.edu > >> To: jay.krell at cornell.edu > >> Date: Mon, 29 Jun 2009 09:41:09 -0400 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] pruning m3cc/gcc? > >> > >> I personally like having the ability to build C from the same > >> source tree. It's useful for debugging the backend sometimes > >> (looking at the equivalent code generated from C). > >> > >> On 28 Jun 2009, at 23:38, Jay wrote: > >> > >> > >> I keep thinking of deleting > >> > >> m3-sys/m3cc/gcc/intl > >> m3-sys/m3cc/gcc/libgomp > >> m3-sys/m3cc/gcc/libmudflap > >> m3-sys/m3cc/gcc/libssp > >> m3-sys/m3cc/gcc/fixincludes > >> m3-sys/m3cc/gcc/libgcc > >> > >> > >> We don't use any of it. > >> Some of these deletions would shorten our build command lines. > >> Though some (esp. fixincludes and maybe libgcc) might break the > >> shortest configure + make that the "real" cm3 doesn't use but can > >> be useful. > >> > >> > >> I didn't include them in gcc-interix and gcc-apple. > >> > >> > >> But there are two possible contradictory goals: > >> > >> > >> - just have what we use/change > >> - have a complete merged gcc tree from which you > >> could build gcc/cc1 and not just cm3cg > >> Except we don't have C++, Java, Ada, Fortran, > >> so we don't really have this, but C probably counts for something. > >> > >> > >> If the second is the goal, don't delete. > >> If the first is the goal, delete. > >> > >> > >> There is also "having it all there in case it is needed > >> or somesuch", but that's easy enough to get elsewhere. > >> > >> > >> - Jay > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 15 05:31:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 15 Aug 2010 03:31:19 +0000 Subject: [M3devel] quake and/or "short circuit" Message-ID: It would have been nice for and/or to short circuit in quake like they do in C. Code like: if not defined("TARGET") readonly TARGET = "I386_FREEBSD" else if not equal(TARGET, "FreeBSD4") readonly TARGET = "I386_FREEBSD" end end is better written as: if not defined("TARGET") or not equal(TARGET, "FreeBSD4") readonly TARGET = "I386_FREEBSD" end but that isn't allowed because equal() will complain that TARGET isn't defined. It probably can't fixed though, due to e.g.: if TRUE or DoSomething() ... end would be broken. perhaps OR and AND or short_circuit_and or and_shorted or and_short_circuit or and_early_out or and_early or "&&" or something... Or I should just rewrite so much quake in Modula-3... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 16 09:55:04 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 16 Aug 2010 09:55:04 +0200 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: References: Message-ID: <20100816095504.29pg9d3dsgkwc00o@mail.elegosoft.com> You talk about `conditional and' and `conditional or'... I thought we had that in quake like in M3, but I might be mistaken. It should not be difficult to implement that though. Using it will be difficult until we've had a release which contains it... Olaf Quoting Jay K : > It would have been nice for and/or to short circuit in quake like > they do in C. > > > Code like: > > if not defined("TARGET") > readonly TARGET = "I386_FREEBSD" > else > if not equal(TARGET, "FreeBSD4") > readonly TARGET = "I386_FREEBSD" > end > end > > > is better written as: > if not defined("TARGET") or not equal(TARGET, "FreeBSD4") > readonly TARGET = "I386_FREEBSD" > end > > but that isn't allowed because equal() will complain that TARGET > isn't defined. > > It probably can't fixed though, due to e.g.: > > if TRUE or DoSomething() > ... > end > > > would be broken. > > > perhaps > OR and AND > or short_circuit_and > or and_shorted > or and_short_circuit > or and_early_out > or and_early > or "&&" > or something... > > > Or I should just rewrite so much quake in Modula-3... > > > - 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 jay.krell at cornell.edu Tue Aug 17 21:02:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 19:02:06 +0000 Subject: [M3devel] coverage of -O1, -O2, -O3, etc.? Message-ID: Anyone have ideas on getting coverage of various switches? Lately I use -O3 -Wuninitialized always. But that isn't exhaustive and doesn't get coverage in Hudson. And it isn't cheap for me. The "old" way was that I never used any optimization. I'm very likely paying more time to run the optimizer than that the optimizer saves. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 17 22:44:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 20:44:19 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: ,,, , , ,,, , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu>, , , , , Message-ID: I forgot about this. I never resolved it. Things seem to work though. ? - Jay > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 06:38:05 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > > I don't know. There is so much unknown here. It is frustrating and difficult. > We could use an extensive set of test cases. > Or know more about the test cases we do have. > And it'd be nice to see if anything varies in the 4.3 path if we put the labels on that list or not. > > tangent: > > I'd like automation that compiles the whole system, multiple architectures, and puts all the *s files in one flat > directory per architecture. I guess it's just a matter of a little code. > It should just skip the few errors that are cross problems, which I should fix anyway. > That particular problem makes me a little nervous, but I suppose I can code it to use both INTEGER and Target.Int > if doing a native build, and assert that the results match. > I hit a snag yesterday, can't build any tests (just to assembly) without first shipping m3core/libm3. > Can't ship m3core/libm3 for cross building. > I guess, and I forgot this, I should have used -x for override. Duh. > That's why I tried I386_DARWIN for some current 4.5 problems vs. SOLgnu, to escape cross building. Oops. > > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Mon, 12 Jul 2010 09:43:01 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] barrier labels? > > > > Perhaps we just need FORCED_LABEL for these: > > > > /* In a LABEL_DECL, nonzero means this label had its address taken > > and therefore can never be deleted and is a jump target for > > computed gotos. */ > > > > > > On 11 Jul 2010, at 23:03, Jay K wrote: > > > > > > > > I still don't see it, in the C++ frontend. > > > > > > There is: > > > > > > void > > > expand_label (tree label) > > > { > > > ... > > > if (DECL_NONLOCAL (label)) > > > { > > > ... nonlocal_goto_handler_labels > > > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > > > nonlocal_goto_handler_labels); > > > } > > > > > > but I don't think this works until later. > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sun, 11 Jul 2010 20:52:25 -0400 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] barrier labels? > > >> > > >> No, that code came from 4.x... > > >> > > >> > > >> > > >> > > >> On 11 Jul 2010, at 19:41, Jay K wrote: > > >> > > >>> > > >>> Tony, thanks for the pointer..though I haven't been able to find it yet. > > >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > > >>> > > >>> - Jay > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 > > >>>> To: jay.krell at cornell.edu > > >>>> CC: m3devel at elegosoft.com > > >>>> Subject: Re: [M3devel] barrier labels? > > >>>> > > >>>> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > > >>>> > > >>>> On 11 Jul 2010, at 07:46, Jay K wrote: > > >>>> > > >>>>> > > >>>>> Tony, six years ago you introduce what is now: > > >>>>> > > >>>>> > > >>>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > >>>>> > > >>>>> > > >>>>> static void > > >>>>> m3cg_set_label (void) > > >>>>> { > > >>>>> ... > > >>>>> if (barrier) > > >>>>> { > > >>>>> ... > > >>>>> { > > >>>>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > > >>>>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > > >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > > >>>>> } > > >>>>> ... > > >>>>> > > >>>>> > > >>>>> I'm not sure what to do here for gcc 4.5. > > >>>>> The data has moved around and isn't available this early. I suppose we could hang some information on and > > >>>>> deal with it later in compilation. > > >>>>> > > >>>>> > > >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > > >>>>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > > >>>>> > > >>>>> > > >>>>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > > >>>>> And Juno/mentor/tetris work without optimization, I'll test optimized later. > > >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. > > >>>>> > > >>>>> > > >>>>> Do we have good exception handling tests? > > >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > > >>>>> > > >>>>> > > >>>>> I'll poke around more.. > > >>>>> > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>> > > >>> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 17 22:47:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 20:47:36 +0000 Subject: [M3devel] gcc 4.5 In-Reply-To: References: Message-ID: This is moving along now. I've moved a few targets to 4.5.1 already. Some targets I haven't tested yet. Some have problems and I've held them back pending investigation. In some cases I compromise, e.g. turning off optimization on ALPHA_OSF. Eventually I might move some forward without testing. Generally I cross build, then self build, and startup some GUI apps. Though my X server is presently broken. - Jay > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: gcc 4.5 > Date: Sun, 11 Jul 2010 23:51:43 +0000 > > > I'm inclined to make gcc 4.5 the default backend very soon. > AMD64_DARWIN, I386_LINUX, SOLgnu are looking ok. > I could also test PPC, like PPC_LINUX. > > SOLgnu leaves everything volatile (same as 4.3) so maybe isn't much validation. > > I doubt there is much value in testing other operating systems, mainly just other processors. > Though there is sometimes, e.g. I think I386_DARWIN uses sse for floating point and other I386 systems don't. > I should also test SPARC_LINUX to get sparc w/o volatile. > > > There are many other targets. OpenBSD, NetBSD, FreeBSD, OSF/1, I386/AMD64_SOLARIS, ARMEL_LINUX, Cygwin, MinGW, etc. > Others can test them? > > > There is some downside, in particular I disable more optimization at -O3 than with gcc 4.3. > One of the additional optimizations perhaps doesn't exist in 4.3 though. > > > The label/barrier thing still isn't resolved. > I haven't run through m3-sys/m3tests. > > > But that the system can build itself is a good sign, though sometimes I overvalue it. > And I tested some gui apps at least unoptimized. > The "man vs. boy" test works. > > > The 4.3 backend will remain available via cm3 -DGCC43 in the m3cc directory. > You have to be careful about cm3cfg.common probing around and finding the intended one, > such as by deleting all others. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 17 23:20:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 17 Aug 2010 21:20:01 +0000 Subject: [M3devel] TimePosix__ComputeGrain Message-ID: I have now often seen cm3 hang starting up. Here: (gdb) bt #0 0x000003ff8010aed8 in gettimeofday64 () from /usr/shlib/libc.so #1 0x00000001205168a4 in TimePosix__Now () at ../src/time/POSIX/TimePosixC.c:41 #2 0x0000000120516924 in ComputeGrainOnce () at ../src/time/POSIX/TimePosixC.c:61 #3 0x0000000120516990 in TimePosix__ComputeGrain () at ../src/time/POSIX/TimePosixC.c:77 #4 0x00000001204ef344 in TimePosix_M3 ( M3_AcxOUs_mode=) at ../src/time/POSIX/TimePosix.m3:18 #5 0x00000001204c94f0 in RTLinker__RunMainBody ( I have adjusted the code to I believe guarantee forward progress. Some versions of mine did not. Ideas? Better portable ways to write it? It hangs a large fraction of the time on Alpha/OSF for example. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Aug 17 23:56:52 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 17 Aug 2010 23:56:52 +0200 Subject: [M3devel] [M3commit] "change outside commit" In-Reply-To: References: Message-ID: <20100817235652.tbbwe9lcnc44oggc@mail.elegosoft.com> Quoting Jay K : > same thing here: > > http://hudson.modula3.com:8080/job/cm3-current-build-I386_DARWIN/19/console > > - Jay > > From: jay.krell at cornell.edu > To: m3commit at elegosoft.com > Date: Tue, 17 Aug 2010 20:40:37 +0000 > Subject: [M3commit] "change outside commit" > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-AMD64_DARWIN/6/console > > +"/Users/hudson/work/cm3-inst/jbook2/AMD64_DARWIN/last-ok/bin/config/Darwin.common", line 258: quake runtime error: undefined variable: > SYSTEM_CC > > To deal with that, I manually edited > /Users/hudson/work/cm3-inst/jbook2/AMD64_DARWIN/last-ok/bin/config/Darwin.common > to more closely resemble current source. > > I don't know if merely having commited fixes works here. It is OK for now to manually repair installations in ~/work/cm3-inst. Sometimes broken things get installed, though I've tried to improve the scripts; but some things are just too difficult to implement (wrt. atomicity and concurrency). The problem is that it takes too much time to investigate and understand each failure of a CM3 regression run. I can only do that now and then. I'll keep improving things 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 mika at async.async.caltech.edu Wed Aug 18 00:27:04 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 17 Aug 2010 15:27:04 -0700 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: References: Message-ID: <20100817222704.B3ABE1A209B@async.async.caltech.edu> If you really want it, you can always introduce "cand" and "cor" for the short-circuit versions. Dijkstra advises against it, though. Mika Jay K writes: >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >It would have been nice for and/or to short circuit in quake like they do i= >n C. > > >Code like: > >if not defined("TARGET") > readonly TARGET =3D "I386_FREEBSD" >else > if not equal(TARGET=2C "FreeBSD4") > readonly TARGET =3D "I386_FREEBSD" > end >end > > >is better written as: >if not defined("TARGET") or not equal(TARGET=2C "FreeBSD4") > readonly TARGET =3D "I386_FREEBSD" >end > >but that isn't allowed because equal() will complain that TARGET isn't defi= >ned. > >It probably can't fixed though=2C due to e.g.: > >if TRUE or DoSomething() > ... >end > > >would be broken. > > >perhaps >OR and AND >or short_circuit_and >or and_shorted >or and_short_circuit >or and_early_out >or and_early >or "&&" >or something... > > >Or I should just rewrite so much quake in Modula-3... > > > - Jay > = > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >It would have been nice for and/or to short circuit in quake like they do i= >n C.


Code like:

if not defined("TARGET")
 =3B read= >only TARGET =3D "I386_FREEBSD"
else
 =3B if not equal(TARGET=2C "= >FreeBSD4")
 =3B =3B =3B readonly TARGET =3D "I386_FREEBSD"r> =3B end
end


is better written as:
if not defined("T= >ARGET") or not equal(TARGET=2C "FreeBSD4")
 =3B readonly TARGET =3D = >"I386_FREEBSD"
end

but that isn't allowed because equal() will co= >mplain that TARGET isn't defined.

It probably can't fixed though=2C = >due to e.g.:

if TRUE or DoSomething()
 =3B ...
end

= >
would be broken.


perhaps
OR and AND
or short_circuit_a= >nd
or and_shorted
or and_short_circuit
or and_early_out
or and_= >early
or "&=3B&=3B"
or something...


Or I should just= > rewrite so much quake in Modula-3...


 =3B- Jay
> = > >= > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_-- From hendrik at topoi.pooq.com Wed Aug 18 01:59:01 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 17 Aug 2010 19:59:01 -0400 Subject: [M3devel] dbxout_static_chain_decl? In-Reply-To: <20100528220400.GB4904@topoi.pooq.com> References: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu> <4BFF15CE.7060908@lcwb.coop> <20100528220400.GB4904@topoi.pooq.com> Message-ID: <20100817235900.GB29080@topoi.pooq.com> On Fri, May 28, 2010 at 06:04:01PM -0400, hendrik at topoi.pooq.com wrote: > > In Algol 68, when it's implemented using static links, the static chain > doesn't thread *all* the chain of surrounding procedures -- it skips the > ones that don't define any names used in the inner ones. > > This bit of denesting might improve efficiency even in Modula 3, since > some static chains might end up being shorter. Whether it's worth the > effort is another question, of course. I should perhaps have mentioned that this behaviour is *required* by the Alcol 68 language definition. Not required by Modula 3, where what you can do with local procedures is more restricted. -- hendrik From jay.krell at cornell.edu Wed Aug 18 03:19:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 18 Aug 2010 01:19:48 +0000 Subject: [M3devel] FW: clock_getres / Time.Grain. In-Reply-To: <20100817213538.760482474033@birch.elegosoft.com> References: <20100817213538.760482474033@birch.elegosoft.com> Message-ID: This needs a review. Folks need to read Posix, the Modula-3 *.i3 files, possibly the OS man pages. Possibly run the two versions and compare. Possibly only #ifdef it in when the compare similar, e.g. on OSF and leave the rest alone. Possibly only use the timeofday timer and not the highres timer. Thanks, - Jay > Date: Tue, 17 Aug 2010 23:35:38 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/17 23:35:37 > > Modified files: > cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c > > Log message: > Let's try clock_getres if it is available. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Aug 18 03:17:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 18 Aug 2010 01:17:02 +0000 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: <20100817222704.B3ABE1A209B@async.async.caltech.edu> References: , <20100817222704.B3ABE1A209B@async.async.caltech.edu> Message-ID: I don't know what the names should be, I'm pretty comfortable with "&&" and "||". Short circuiting is very useful. > Dijkstra advises against it, though. That makes me question Dijkstra, not short circuiting. Also useful is assignment being an expression. I wish it was in Modula-3. Such things as: if ((f = fopen(..)) && fread(f,...) or if (p && *p) In the first case Modula-3 forces useless verbosity and indentation. In the second case Modula-3 gets it right but Quake fails. Lacking these features you end up contorting your code one way or another, such as duplicating things. I really can't stand code that looks like: result = do something if success(result) do more stuff if success do more stuff if succes do more stuff Modula-3 this wrong. Exceptions help. But basically I want to be able to introduce WITH or VAR anywhere, but not need to "END" them, and therefore no implied need for indentation.. - Jay > To: jay.krell at cornell.edu > Date: Tue, 17 Aug 2010 15:27:04 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] quake and/or "short circuit" > > If you really want it, you can always introduce "cand" and "cor" for > the short-circuit versions. > > Dijkstra advises against it, though. > > Mika > > Jay K writes: > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >It would have been nice for and/or to short circuit in quake like they do i= > >n C. > > > > > >Code like: > > > >if not defined("TARGET") > > readonly TARGET =3D "I386_FREEBSD" > >else > > if not equal(TARGET=2C "FreeBSD4") > > readonly TARGET =3D "I386_FREEBSD" > > end > >end > > > > > >is better written as: > >if not defined("TARGET") or not equal(TARGET=2C "FreeBSD4") > > readonly TARGET =3D "I386_FREEBSD" > >end > > > >but that isn't allowed because equal() will complain that TARGET isn't defi= > >ned. > > > >It probably can't fixed though=2C due to e.g.: > > > >if TRUE or DoSomething() > > ... > >end > > > > > >would be broken. > > > > > >perhaps > >OR and AND > >or short_circuit_and > >or and_shorted > >or and_short_circuit > >or and_early_out > >or and_early > >or "&&" > >or something... > > > > > >Or I should just rewrite so much quake in Modula-3... > > > > > > - Jay > > = > > > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >It would have been nice for and/or to short circuit in quake like they do i= > >n C.


Code like:

if not defined("TARGET")
 =3B read= > >only TARGET =3D "I386_FREEBSD"
else
 =3B if not equal(TARGET=2C "= > >FreeBSD4")
 =3B =3B =3B readonly TARGET =3D "I386_FREEBSD" >r> =3B end
end


is better written as:
if not defined("T= > >ARGET") or not equal(TARGET=2C "FreeBSD4")
 =3B readonly TARGET =3D = > >"I386_FREEBSD"
end

but that isn't allowed because equal() will co= > >mplain that TARGET isn't defined.

It probably can't fixed though=2C = > >due to e.g.:

if TRUE or DoSomething()
 =3B ...
end

= > >
would be broken.


perhaps
OR and AND
or short_circuit_a= > >nd
or and_shorted
or and_short_circuit
or and_early_out
or and_= > >early
or "&=3B&=3B"
or something...


Or I should just= > > rewrite so much quake in Modula-3...


 =3B- Jay
> > = > > > >= > > > >--_203e0ef7-c6fc-42ed-ad8c-3abbdc3b9c9e_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Aug 18 03:53:46 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 17 Aug 2010 21:53:46 -0400 Subject: [M3devel] quake and/or "short circuit" In-Reply-To: References: <20100817222704.B3ABE1A209B@async.async.caltech.edu> Message-ID: <20100818015346.GB29274@topoi.pooq.com> On Wed, Aug 18, 2010 at 01:17:02AM +0000, Jay K wrote: > > I don't know what the names should be, I'm pretty comfortable with "&&" and "||". > Short circuiting is very useful. > > > Dijkstra advises against it, though. > > That makes me question Dijkstra, not short circuiting. He has specific reasons, having to do with programs being part of a logical calculus. In logic, 'and' and 'or' are both commutative, so he thinks it sim0plifies the formal calculus of programming to have them behave the same in programs. > > > Also useful is assignment being an expression. > I wish it was in Modula-3. So do I. > > Such things as: > > > if ((f = fopen(..)) && fread(f,...) > > > or if (p && *p) > > > In the first case Modula-3 forces useless verbosity and indentation. > In the second case Modula-3 gets it right but Quake fails. > > Lacking these features you end up contorting your code one way or another, such as duplicating things. > > > I really can't stand code that looks like: > > > result = do something > if success(result) > do more stuff > if success > do more stuff > if succes > do more stuff > > > Modula-3 this wrong. > Exceptions help. > But basically I want to be able to introduce WITH or VAR anywhere, but not need to "END" them, and therefore no implied need for indentation.. It looks as if you want Modula 3 with Algol 68 syntax. So do I. -- hendrik From jay.krell at cornell.edu Wed Aug 18 09:53:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 18 Aug 2010 07:53:12 +0000 Subject: [M3devel] FW: clock_getres / Time.Grain. In-Reply-To: References: <20100817213538.760482474033@birch.elegosoft.com>, Message-ID: Well, it seems clock_getres is either not available (Darwin) or varies much from the historical code (Linux, Solaris). So this is only for OSF/1 now. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Wed, 18 Aug 2010 01:19:48 +0000 Subject: [M3devel] FW: clock_getres / Time.Grain. This needs a review. Folks need to read Posix, the Modula-3 *.i3 files, possibly the OS man pages. Possibly run the two versions and compare. Possibly only #ifdef it in when the compare similar, e.g. on OSF and leave the rest alone. Possibly only use the timeofday timer and not the highres timer. Thanks, - Jay > Date: Tue, 17 Aug 2010 23:35:38 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/17 23:35:37 > > Modified files: > cm3/m3-libs/m3core/src/time/POSIX/: TimePosixC.c > > Log message: > Let's try clock_getres if it is available. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Aug 18 19:24:39 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 18 Aug 2010 12:24:39 -0500 Subject: [M3devel] dbxout_static_chain_decl? In-Reply-To: <20100817235900.GB29080@topoi.pooq.com> References: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu> <4BFF15CE.7060908@lcwb.coop> <20100528220400.GB4904@topoi.pooq.com> <20100817235900.GB29080@topoi.pooq.com> Message-ID: <4C6C1757.9080005@lcwb.coop> hendrik at topoi.pooq.com wrote: > On Fri, May 28, 2010 at 06:04:01PM -0400, hendrik at topoi.pooq.com wrote: >> In Algol 68, when it's implemented using static links, the static chain >> doesn't thread *all* the chain of surrounding procedures -- it skips the >> ones that don't define any names used in the inner ones. >> >> This bit of denesting might improve efficiency even in Modula 3, since >> some static chains might end up being shorter. Whether it's worth the >> effort is another question, of course. Well, I'm going to keep beating this drum. Except for highly optimized compiles, I want the debugger to give a view that reflects what is declared. Even when a nonlocal variable is not referred do by any nested procedure, a debugger user (specifically, me) often wants to look at or even change such variables, when stopped inside a nested procedure. I do this a lot. Yes, you can always go up the dynamic call chain with debugger commands to get at them, but this sometimes costs a *lot* of extra time, especially if the nested procedure has called itself recursively umpteen times. Then you have to get back to the frame you were in. Then do it all again later. It's also often quite tricky to get right. All this diverts a lot of mental capacity from actually chasing the bug to how to work the debugger, just for a simple variable access that, by language rules, is visible from right were you are. Of course, it you choose a medium or high level of optimization, then using a debugger is already pretty much an exercise in futility anyway, for various other reasons, so in that case, I wouldn't fight it. > > I should perhaps have mentioned that this behaviour is *required* by the > Alcol 68 language definition. Not required by Modula 3, where what you > can do with local procedures is more restricted. > > -- hendrik > From jay.krell at cornell.edu Thu Aug 19 22:15:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 20:15:32 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson Message-ID: New Hudson node. A VM running on MacBook. ? We'll see if it stays on and if the network works. I386_NETBSD ssh -p 227 hudson at jayk.homedns.org To start, it has: ? /usr/pkg/java/openjdk7/bin/java ? /cm3/bin/cm3 ??? Actually a bunch in /cm3, you can get cm3cg, pkg/{m3core,libm3,etc.} there. ? /usr/pkg/bin/bash It is missing some libraries still so some "late" packages will fail. I haven't tested X apps, have to reboot the MacBook. ?And install more X libraries. AMD64_NETBSD later. I made a new node. Copied from openbsd-jkrell. jkrell-xnbsd. http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin ?- Jay ? From jay.krell at cornell.edu Thu Aug 19 22:32:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 20:32:40 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: ok, I put in a /usr/local/bin/java that Hudson likes. I cloned the m3cc/build/tests jobs from I386_OPENBSD. Not sure what is next, gotta run. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Thu, 19 Aug 2010 20:15:32 +0000 > Subject: [M3devel] VM for I386_NETBSD Hudson > > > New Hudson node. > A VM running on MacBook. > We'll see if it stays on and if the network works. > > I386_NETBSD > > ssh -p 227 hudson at jayk.homedns.org > > To start, it has: > /usr/pkg/java/openjdk7/bin/java > /cm3/bin/cm3 > Actually a bunch in /cm3, you can get cm3cg, pkg/{m3core,libm3,etc.} there. > /usr/pkg/bin/bash > > It is missing some libraries still so some "late" packages > will fail. > > I haven't tested X apps, have to reboot the MacBook. > And install more X libraries. > > AMD64_NETBSD later. > > I made a new node. Copied from openbsd-jkrell. > jkrell-xnbsd. > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > - Jay > From jay.krell at cornell.edu Thu Aug 19 22:54:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 20:54:48 +0000 Subject: [M3devel] more failure to propagate error Message-ID: http://hudson.modula3.com:8080/job/boot-i386-netbsd/4/console I understand the actual error, the config files are missing. ?- Jay From jay.krell at cornell.edu Thu Aug 19 23:05:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:05:17 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: , Message-ID: ok, I cloned boot-ppc-linux and this worked: http://hudson.modula3.com:8080/job/boot-i386-netbsd/5/console I had to: ?- remove the branch ?- change my /cm3 to not delegate to CVS (run scripts/python/make-dist-cfg.py) ?- not sure, but the config files still weren't there, maybe I had to rerun it, maybe I had mkdir config and that stopped ? the copying on subsequent run, I deleted the empty dir and reran We'll see how this goes: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/1/console Somewhat tedious point and click and type here but not terrible. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Thu, 19 Aug 2010 20:32:40 +0000 > Subject: Re: [M3devel] VM for I386_NETBSD Hudson > > > ok, I put in a /usr/local/bin/java that Hudson likes. > I cloned the m3cc/build/tests jobs from I386_OPENBSD. > Not sure what is next, gotta run. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com; m3devel at elegosoft.com > > Date: Thu, 19 Aug 2010 20:15:32 +0000 > > Subject: [M3devel] VM for I386_NETBSD Hudson > > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - Jay > > > From jay.krell at cornell.edu Thu Aug 19 23:10:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:10:20 +0000 Subject: [M3devel] SOLgnu/SOlsun broken Message-ID: I'm aware that SPARC32_SOLARIS/SOLsun/SOLgnu are having problems. e.g.: http://hudson.modula3.com:8080/job/cm3-current-build-SOLgnu/55/console cp: /home/hudson/workspace/cm3-current-build-SOLgnu/cm3/m3-sys/cminstall/src/config-no-install/CVS: is a directory Segmentation Fault - core dumped /home/hudson/work/cm3-inst/ssol/current/bin/cm3- is broken compiler upgrade failed I'll try to get to it soon. Usually, for some reason, these are caused by something related to position independence. - Jay From jay.krell at cornell.edu Thu Aug 19 23:12:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:12:00 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: ,,, , , , , , , , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu>, , , , , , Message-ID: As well, SOLgnu/SOLsun/SPARC32_SOLARIS when using the gcc 4.5.1 backend crash just after raising an exception. Ugh. Needs investigation.. ?- Jay ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] barrier labels? > Date: Tue, 17 Aug 2010 20:44:19 +0000 > > I forgot about this. > I never resolved it. > Things seem to work though. > ? > > - Jay > > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > Date: Tue, 13 Jul 2010 06:38:05 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] barrier labels? > > > > > > I don't know. There is so much unknown here. It is frustrating and > difficult. > > We could use an extensive set of test cases. > > Or know more about the test cases we do have. > > And it'd be nice to see if anything varies in the 4.3 path if we put > the labels on that list or not. > > > > tangent: > > > > I'd like automation that compiles the whole system, multiple > architectures, and puts all the *s files in one flat > > directory per architecture. I guess it's just a matter of a little code. > > It should just skip the few errors that are cross problems, which > I should fix anyway. > > That particular problem makes me a little nervous, but I suppose > I can code it to use both INTEGER and Target.Int > > if doing a native build, and assert that the results match. > > I hit a snag yesterday, can't build any tests (just to assembly) > without first shipping m3core/libm3. > > Can't ship m3core/libm3 for cross building. > > I guess, and I forgot this, I should have used -x for override. Duh. > > That's why I tried I386_DARWIN for some current 4.5 problems vs. > SOLgnu, to escape cross building. Oops. > > > > > > - Jay > > > > ---------------------------------------- > > > From: hosking at cs.purdue.edu > > > Date: Mon, 12 Jul 2010 09:43:01 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] barrier labels? > > > > > > Perhaps we just need FORCED_LABEL for these: > > > > > > /* In a LABEL_DECL, nonzero means this label had its address taken > > > and therefore can never be deleted and is a jump target for > > > computed gotos. */ > > > > > > > > > On 11 Jul 2010, at 23:03, Jay K wrote: > > > > > > > > > > > I still don't see it, in the C++ frontend. > > > > > > > > There is: > > > > > > > > void > > > > expand_label (tree label) > > > > { > > > > ... > > > > if (DECL_NONLOCAL (label)) > > > > { > > > > ... nonlocal_goto_handler_labels > > > > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > > > > nonlocal_goto_handler_labels); > > > > } > > > > > > > > but I don't think this works until later. > > > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > >> From: hosking at cs.purdue.edu > > > >> Date: Sun, 11 Jul 2010 20:52:25 -0400 > > > >> To: jay.krell at cornell.edu > > > >> CC: m3devel at elegosoft.com > > > >> Subject: Re: [M3devel] barrier labels? > > > >> > > > >> No, that code came from 4.x... > > > >> > > > >> > > > >> > > > >> > > > >> On 11 Jul 2010, at 19:41, Jay K wrote: > > > >> > > > >>> > > > >>> Tony, thanks for the pointer..though I haven't been able to > find it yet. > > > >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 > was current at the time. > > > >>> > > > >>> - Jay > > > >>> > > > >>> ---------------------------------------- > > > >>>> From: hosking at cs.purdue.edu > > > >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 > > > >>>> To: jay.krell at cornell.edu > > > >>>> CC: m3devel at elegosoft.com > > > >>>> Subject: Re: [M3devel] barrier labels? > > > >>>> > > > >>>> I extracted that usage from what C++ was doing for exception > labels. The point is to make sure that flow analysis knows that the > exception handler label targets are important "non-local" label > targets. I do remember that DECL_NONLOCAL was *not* the right thing to > do (that is used for proper non-local outer-scope goto targets for > nested functions) and I remember the SP hacks being used with that > (they need to recover from targeting from an inner-scope function and > clean up the stack accordingly). I suggest poking around in what the > C++ exception handling now does with table-driven exception targets. > > > >>>> > > > >>>> On 11 Jul 2010, at 07:46, Jay K wrote: > > > >>>> > > > >>>>> > > > >>>>> Tony, six years ago you introduce what is now: > > > >>>>> > > > >>>>> > > > >>>>> > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > > >>>>> > > > >>>>> > > > >>>>> static void > > > >>>>> m3cg_set_label (void) > > > >>>>> { > > > >>>>> ... > > > >>>>> if (barrier) > > > >>>>> { > > > >>>>> ... > > > >>>>> { > > > >>>>> rtx list = DECL_STRUCT_FUNCTION > (current_function_decl)->x_nonlocal_goto_handler_labels; > > > >>>>> DECL_STRUCT_FUNCTION > (current_function_decl)->x_nonlocal_goto_handler_labels > > > >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > > > >>>>> } > > > >>>>> ... > > > >>>>> > > > >>>>> > > > >>>>> I'm not sure what to do here for gcc 4.5. > > > >>>>> The data has moved around and isn't available this early. I > suppose we could hang some information on and > > > >>>>> deal with it later in compilation. > > > >>>>> > > > >>>>> > > > >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very > bad code to be produced (incorrect, not inefficient). > > > >>>>> I didn't look into why. The bad code was changing the stack > pointer where it should leave it alone. > > > >>>>> > > > >>>>> > > > >>>>> gcc-4.5 is working for me now (cm3 built with it can built > itself), at least with -O1, AMD64_DARWIN. > > > >>>>> And Juno/mentor/tetris work without optimization, I'll test > optimized later. > > > >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. > > > >>>>> > > > >>>>> > > > >>>>> Do we have good exception handling tests? > > > >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > > > >>>>> > > > >>>>> > > > >>>>> I'll poke around more.. > > > >>>>> > > > >>>>> > > > >>>>> - Jay > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > From jay.krell at cornell.edu Thu Aug 19 23:27:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Aug 2010 21:27:27 +0000 Subject: [M3devel] cvs commands in Hudson keep complaining about long-ago deleted directories Message-ID: Olaf there's something somehow slightly off. http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console Started by user jkrell Building remotely on jkrell-xnbsd [m3cc] $ cvs -q -z3 update -PdC -D "Thursday, August 19, 2010 9:16:34 PM UTC" ?cvs update: use `cvs add' to create an entry for `gcc/INSTALL'???? <==? ?cvs update: use `cvs add' to create an entry for `gcc/fixincludes' ?? <== This has been happening on all jobs. I manually removed the directories in most/all. But this is a new node/task. It must be related to the branches varying. But cvs upd shouldn't be so difficult. ?- Jay From wagner at elegosoft.com Fri Aug 20 08:03:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 08:03:38 +0200 Subject: [M3devel] cvs commands in Hudson keep complaining about long-ago deleted directories In-Reply-To: References: Message-ID: <20100820080338.42ud2degysww4gsk@mail.elegosoft.com> Quoting Jay K : > Olaf there's something somehow slightly off. > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > Started by user jkrell > Building remotely on jkrell-xnbsd > [m3cc] $ cvs -q -z3 update -PdC -D "Thursday, August 19, 2010 9:16:34 PM UTC" > > ?cvs update: use `cvs add' to create an entry for `gcc/INSTALL'???? > <==? > ?cvs update: use `cvs add' to create an entry for `gcc/fixincludes' ?? <== > > This has been happening on all jobs. > I manually removed the directories in most/all. > But this is a new node/task. > > It must be related to the branches varying. > But cvs upd shouldn't be so difficult. In my working copy from the trunk these directories are there. They get removed by your m3makefile again, but update -d resurrects them. What exactly have you done to `remove' them from CVS? As CVS doesn't handle directories as first class objects, the only ways to remove a directory are (1) delete all files in it recursively and let CVS know. The -p(rune) option will then delete empty directories. (2) remove the complete history on the server. Not allowed for a simple human user in daily operations ;-) Olaf PS: I'm in a hurry now, do I won't have time to read and answer all mails now. There are still several dozens... More later. -- 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 Fri Aug 20 08:33:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 20 Aug 2010 06:33:53 +0000 Subject: [M3devel] cvs commands in Hudson keep complaining about long-ago deleted directories In-Reply-To: <20100820080338.42ud2degysww4gsk@mail.elegosoft.com> References: , <20100820080338.42ud2degysww4gsk@mail.elegosoft.com> Message-ID: > They get removed by your m3makefile again Oops, I didn't realize, don't see, will keep looking. (See next.) > What exactly have you done to `remove' them from CVS? As CVS doesn't > handle directories as first class objects, the only ways to remove > (1) delete all files in it recursively and let CVS know. > The -p(rune) option will then delete empty directories. Oops, I thought I had done that. Apparently not. > (2) remove the complete history on the server. Not allowed for > a simple human user in daily operations ;-) Of course. Sorry for the misdirection! ?- Jay From wagner at elegosoft.com Fri Aug 20 10:31:57 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 10:31:57 +0200 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: <20100820103157.387frltd2cwooccc@mail.elegosoft.com> Quoting Jay K : > ok, I put in a /usr/local/bin/java that Hudson likes. > I cloned the m3cc/build/tests jobs from I386_OPENBSD. > Not sure what is next, gotta run. To simplify matters, new Hudson nodes should contain the last CM3 rlease in $INSTROOT_REL, which usually is something like $HOME/work/$HOST/cm3-inst/rel-5.8.6 BTW, several nodes still lack the latest release there, and/or reference something like LASTREL=d5.7.0 or similar. These may fail as soon as we rely on features in that release (like quake functions etc.). I haven't had time to check everything yet, Olaf > ?- Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com; m3devel at elegosoft.com >> Date: Thu, 19 Aug 2010 20:15:32 +0000 >> Subject: [M3devel] VM for I386_NETBSD Hudson >> >> >> New Hudson node. >> A VM running on MacBook. >> We'll see if it stays on and if the network works. >> >> I386_NETBSD >> >> ssh -p 227 hudson at jayk.homedns.org >> >> To start, it has: >> /usr/pkg/java/openjdk7/bin/java >> /cm3/bin/cm3 >> Actually a bunch in /cm3, you can get cm3cg, >> pkg/{m3core,libm3,etc.} there. >> /usr/pkg/bin/bash >> >> It is missing some libraries still so some "late" packages >> will fail. >> >> I haven't tested X apps, have to reboot the MacBook. >> And install more X libraries. >> >> AMD64_NETBSD later. >> >> I made a new node. Copied from openbsd-jkrell. >> jkrell-xnbsd. >> http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ >> >> PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin >> >> - 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 wagner at elegosoft.com Fri Aug 20 14:58:09 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 14:58:09 +0200 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com> The installed cm3 still uses the wrong target platform name: http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. Fix config? Olaf Quoting Jay K : > > New Hudson node. > A VM running on MacBook. > ? We'll see if it stays on and if the network works. > > I386_NETBSD > > ssh -p 227 hudson at jayk.homedns.org > > To start, it has: > ? /usr/pkg/java/openjdk7/bin/java > ? /cm3/bin/cm3 > ??? Actually a bunch in /cm3, you can get cm3cg, > pkg/{m3core,libm3,etc.} there. > ? /usr/pkg/bin/bash > > It is missing some libraries still so some "late" packages > will fail. > > I haven't tested X apps, have to reboot the MacBook. > ?And install more X libraries. > > AMD64_NETBSD later. > > I made a new node. Copied from openbsd-jkrell. > jkrell-xnbsd. > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > ?- 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 wagner at elegosoft.com Fri Aug 20 16:15:36 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Aug 2010 16:15:36 +0200 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: References: Message-ID: <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Quoting Jay K : > New Hudson node. > A VM running on MacBook. > ? We'll see if it stays on and if the network works. For your information It seems we have crossed the acceptable load boundary for our hosted server birch.elegosoft.com recently. The main problem seems to be I/O caused by lots of concurrent CVS checkouts and updates in combination with internal backup, which make other services like HTTP unresponsive and unusable. As far as I can see there is no easy short-time solution. We are going to find a new and more efficient home for our web services anyway in the fall, but it may be that we will have to limit the number of concurrent CVS accesses or Hudson job executions (including clients) for some time. I'm currently also investigating if we can easily move to another (virtual) host or setup a proxy to improve matters. Both will need some migration on client sides. I'll keep you informed what way we choose to resolve this problem. It will help if you don't check in lots of small changes, but complete reasonable change sets. It would also help if we could reduce the size of the repository again, especially in the gcc and gdb structures. If there is dead content that we don't really need, we might move it to another access path for some time. Thanks in advance for your understanding and cooperation. Please stay calm and continue to enjoy the flight ;-) 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 Sat Aug 21 09:38:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 07:38:29 +0000 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> References: , <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Message-ID: All the more reason to use anything besides CVS? What about checkout vs. update? Is update a problem or just checkout? We don't do many checkouts, right? Can/should the pollling interval be changed, like to every hour? And can machines poll at different times, say at a minute within the hour that is a hash of their hostname? Or more aggressive, have some machines only poll a few times a day, once or twice? Only more mainstream machines poll more frequently? I can always run "build now" if I'm eager for a particular build. Repository size is a tough one. Even if I remove files, the repository size is unchanged, right? We have 3 copies of gcc in semi-active use right now. There are others in the repository. But gcc-apple really isn't active -- it is for ARM_DARWIN. Can the Hudson jobs easily exclude that? Between gcc and gcc-4.5 we are stuck for now. gcc-4.5 works a lot and also definitely fails some. In particular SPARC32_SOLARIS/SOLgnu/SOLsun fail right after throwing an exception. SPARC64_SOLARIS has at least a small problem. I'm not sure if there are problems beyond those. Certainly if you want to "cherry pick" off a few files here and there, there is definitely opportunity. I'm not sure if a few files here and there matter though. m3-pkgtools presently isn't built for example. dll2lib or whatever isn't worth anything these days. The old m3gc-simple and m3gc-enhanced are dead. I like a source control to preserve record of deleted stuff though. - Jay > Date: Fri, 20 Aug 2010 16:15:36 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: m3-support at elego.de > Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson > > Quoting Jay K : > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > For your information > > It seems we have crossed the acceptable load boundary for our hosted > server birch.elegosoft.com recently. The main problem seems to be > I/O caused by lots of concurrent CVS checkouts and updates in combination > with internal backup, which make other services like HTTP unresponsive and > unusable. > > As far as I can see there is no easy short-time solution. We are going > to find a new and more efficient home for our web services anyway in the > fall, but it may be that we will have to limit the number of concurrent > CVS accesses or Hudson job executions (including clients) for some time. > > I'm currently also investigating if we can easily move to another > (virtual) host or setup a proxy to improve matters. Both will need > some migration on client sides. > > I'll keep you informed what way we choose to resolve this problem. > > It will help if you don't check in lots of small changes, but complete > reasonable change sets. > > It would also help if we could reduce the size of the repository again, > especially in the gcc and gdb structures. If there is dead content > that we don't really need, we might move it to another access path for > some time. > > Thanks in advance for your understanding and cooperation. > > Please stay calm and continue to enjoy the flight ;-) > > 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 wagner at elegosoft.com Sat Aug 21 11:24:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 21 Aug 2010 11:24:43 +0200 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: References: , <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Message-ID: <20100821112443.eb5ljfzklc0kk8wc@mail.elegosoft.com> Quoting Jay K : > All the more reason to use anything besides CVS? I'd doubt that other system will improve this situation much. But I don't know. Peter Eiserloh is currently trying out git. > What about checkout vs. update? > Is update a problem or just checkout? > We don't do many checkouts, right? We're doing mostly updates. But they should generate the same i/o load. > Can/should the pollling interval be changed, like to every hour? > And can machines poll at different times, say at a minute within the > hour that is a hash of their hostname? I've already increased the polling interval on several jobs, but may increase still more. > Or more aggressive, have some machines only poll a few times a day, > once or twice? Well yes, we could just poll locally on birch and start the other jobs on completion. I think I'll do that; I'll probably disable all the polling first by script and then add some dependencies. > Only more mainstream machines poll more frequently? > I can always run "build now" if I'm eager for a particular build. Yes. > Repository size is a tough one. > Even if I remove files, the repository size is unchanged, right? I meant we could move a complete sub-tree to another location for some time if it's not needed. There are several versions of gcc IIRC. If we need all of them for at least one target, we cannot do that. > We have 3 copies of gcc in semi-active use right now. > There are others in the repository. > But gcc-apple really isn't active -- it is for ARM_DARWIN. > Can the Hudson jobs easily exclude that? We can add that where possible, too. > Between gcc and gcc-4.5 we are stuck for now. > gcc-4.5 works a lot and also definitely fails some. > In particular SPARC32_SOLARIS/SOLgnu/SOLsun fail right after > throwing an exception. > SPARC64_SOLARIS has at least a small problem. > I'm not sure if there are problems beyond those. > > Certainly if you want to "cherry pick" off a few files here and > there, there is definitely opportunity. > I'm not sure if a few files here and there matter though. Not worth the trouble. > m3-pkgtools presently isn't built for example. > dll2lib or whatever isn't worth anything these days. It's just the gcc and gdb code that's so large. > The old m3gc-simple and m3gc-enhanced are dead. Also not worth to remove. > I like a source control to preserve record of deleted stuff though. I'm not going to delete anything then. Let's try the polling strategy change first. 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 Sat Aug 21 12:13:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 10:13:03 +0000 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: <20100821112443.eb5ljfzklc0kk8wc@mail.elegosoft.com> References: , <20100820161536.xmld5roocgwgggow@mail.elegosoft.com>, , <20100821112443.eb5ljfzklc0kk8wc@mail.elegosoft.com> Message-ID: > I meant we could move a complete sub-tree to another location for some > time if it's not needed. There are several versions of gcc IIRC. > If we need all of them for at least one target, we cannot do that. Aha, I understand better now. You mean to a new CVS root/repository? You can move this: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.1.1/ e.g. /usr/cvs/cm3_m3cc_gcc-4.1.1. My desire for history, worst case, drop a readme.txt in cm3/m3-sys/m3cc/gcc-4.1.1. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-interix. I merged it into m3cc/gcc long ago (and gcc-4.5 more recently) and it has all been deleted. Again, a marker file could be dropped in. Less clear: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-apple. It is for iphone but surely currently unused. stuck with for now: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.5 http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc I actually have some interest in making this situation worse. It appears OpenBSD doesn't like GPL3, so they have moved some targets up to gcc 4.x, but stopped at 4.2.1. Some are on 3.x I think some are on 2.x. It'd be helpful to branch the OpenBSD versions. Or, on the other hand, I'm starting to put time into a C backend! :) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Aug 21 14:05:34 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sat, 21 Aug 2010 08:05:34 -0400 Subject: [M3devel] Hudson setup and M3 repository, was: Re: VM for I386_NETBSD Hudson In-Reply-To: References: <20100820161536.xmld5roocgwgggow@mail.elegosoft.com> Message-ID: <20100821120534.GA8755@topoi.pooq.com> On Sat, Aug 21, 2010 at 07:38:29AM +0000, Jay K wrote: > > All the more reason to use anything besides CVS? Sorry. I meant to work on conversion to monotone, but I haven't had the time to work on it yet. -- hendrik From wagner at elegosoft.com Sat Aug 21 18:21:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 21 Aug 2010 18:21:44 +0200 Subject: [M3devel] changes in CM3 continuous integration setup Message-ID: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com> Due to I/O overload problems on the Hudson/CVS/WWW server birch.elegosoft.com I have now reduced the jobs that perform actual repository polling on the CM3 CVS repository to two, running locally on birch: cm3-current-m3cc-AMD64_LINUX cm3-current-build-AMD64_LINUX The first checks all the m3cc sources, the second the rest; the first runs all 10, the second all 11 minutes. All other jobs are triggered in several cascades by these two. For each target platform, the dependencies are m3cc --> build --> test-m3tests --> test-all-pkgs The m3cc and build jobs for AMD64_LINUX also trigger other target platform builds in this fashion: AMD64_LINUX --> AMD64_DARWIN --> AMD64_FREEBSD --> PPC_DARWIN --> I386_DARWIN --> I386_NETBSD --> I386_OPENBSD --> SOLsun-opencsw-curent9s --> SOLsun-opencsw-curent10s --> I386_SOLARIS-opencsw-curent10x --> FreeBSD4 --> LINUXLIBC6 --> NT386 --> PPC_LINUX --> SPARC32_LINUX --> SOLgnu This scheme reflects the expected availability and maintainability of the machines by me, in case you wonder ;-) I hope that this will help to reduce the load and not lead to further problems due to parallel updates on one cascade level. Of course, jobs can still be started manually via the HTTP GUI. If you do this, please bear in mind that other jobs will be triggered, too, according to the diagrams above. 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 Sun Aug 22 00:42:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 22:42:21 +0000 Subject: [M3devel] record types in backend In-Reply-To: References: <20100821083935.3593B247400C@birch.elegosoft.com>, Message-ID: In debugging this..the gcc code wants to enumerate the fields of a struct. We spend the effort building up most of this information, but we never hook it up to the parameter. The fields are null. From debugging it. Then from reading our code: declare_param: m3_build_type case T_struct: { tree ts = make_node (RECORD_TYPE); TYPE_FIELDS (ts) = NULL_TREE; Seems to me we should have a hash of typeid to tree, and here we should look up the typeid and set the fields appropriately. I'll try that. Besides fixing SPARC64_SOLARIS here, it should dramatically improve debugging with stock gdb. We'll see. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Sat, 21 Aug 2010 21:49:04 +0000 Subject: Re: [M3commit] CVS Update: cm3 It turns out 4.3.5 fails the same way. - Jay > Date: Sat, 21 Aug 2010 10:39:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/21 10:39:34 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > > Log message: > back to gcc 4.3 for SPARC64_SOLARIS, see m3-sys/m3tests/src/p2/p247 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 22 00:43:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 21 Aug 2010 22:43:53 +0000 Subject: [M3devel] record types in backend In-Reply-To: References: <20100821083935.3593B247400C@birch.elegosoft.com>, , Message-ID: I should point out that the type we do build up contains fields of I think integers. static void debug_field (const char *name) { tree f = build_decl (FIELD_DECL, get_identifier (name), t_int); That also needs work and shouldn't be difficult. I'm not sure where the builtin typeids come from though. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: record types in backend Date: Sat, 21 Aug 2010 22:42:21 +0000 In debugging this..the gcc code wants to enumerate the fields of a struct. We spend the effort building up most of this information, but we never hook it up to the parameter. The fields are null. From debugging it. Then from reading our code: declare_param: m3_build_type case T_struct: { tree ts = make_node (RECORD_TYPE); TYPE_FIELDS (ts) = NULL_TREE; Seems to me we should have a hash of typeid to tree, and here we should look up the typeid and set the fields appropriately. I'll try that. Besides fixing SPARC64_SOLARIS here, it should dramatically improve debugging with stock gdb. We'll see. - Jay From: jay.krell at cornell.edu To: jkrell at elego.de; m3commit at elegosoft.com Date: Sat, 21 Aug 2010 21:49:04 +0000 Subject: Re: [M3commit] CVS Update: cm3 It turns out 4.3.5 fails the same way. - Jay > Date: Sat, 21 Aug 2010 10:39:34 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/08/21 10:39:34 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > > Log message: > back to gcc 4.3 for SPARC64_SOLARIS, see m3-sys/m3tests/src/p2/p247 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 22 12:11:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 22 Aug 2010 10:11:08 +0000 Subject: [M3devel] better type information in gcc backend Message-ID: This is getting interesting. I have a small local change so that local structs have type information -- as to what fields they contain. As a result, you can see like: 0x001d65b7 in RTType__Expand (M3_DaARCY_m=0x0) at ../src/runtime/common/RTType.m3:719 (gdb) info locals M3_BQo8Jp_new = { Bd56fi_0_32_name = 0, D0ztjH_32_32_is_equal = 0, DXHNAh_64_32_rehash = 0, Cwb5VA_96_32_initial_size = 0, Cwb5VA_128_32_full = 0, Cwb5VA_160_32_cnt = 0, Cwb5VA_192_32_max = 0, AcxOUs_224_32_mask = 0, AJWxb1_256_32_map = 0 } which is a great improvement. It used to only show you the address of the locals. *However*, first when I put the change in, gcc would hit infinite recursions, something related to bitfields. So I *again* disabled our wierdo bitfield stuff. That hack is a continuing thorn in my side. Yes it does generate better code, at least when not optimizing. We'd surely be better to get all the type information correct though and use member references. I realize that the frontend "lowers" things generally further than that, it expects a lower level backend than the gcc tree representation is really designed for. Anyway.. Then it compiles. But the result crashes. Using -O3. And info locals actually prints the locals three times each. More to do here.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Sun Aug 22 16:26:33 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Sun, 22 Aug 2010 22:26:33 +0800 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 Message-ID: The CM3 binaries for FreeBSD6 don't work in FreeBSD 8.1 because cminstall is looking for very specific versions of libraries. For example it wants libm.so.4 but I only have libm.so -> libm.so.5. It also looks for libc.so.6 where I can only supply libc.so.7. Even worse is the requirement for libpthread.so.2. There *IS* no libpthread.so.anything. There's a libpthread.so which is a soft link to libthr.so which is itself a soft link to libthr.so.3. If I try to fake any of this out with softlinks I get problems with libpthread.so.2 since it's looking for a symbol (LIBTHREAD_1_0) which is apparently not provided by libthr.so.3. There is nothing in /usr/ports that seems to give me a proper libpthread that cminstall would like, so I'm basically stuck at this point unable to install (not build -- install!) CM3 on this FreeBSD machine. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Aug 22 16:43:49 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 22 Aug 2010 16:43:49 +0200 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: References: Message-ID: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Quoting Michael Richter : > The CM3 binaries for FreeBSD6 don't work in FreeBSD 8.1 because cminstall is > looking for very specific versions of libraries. For example it wants > libm.so.4 but I only have libm.so -> libm.so.5. It also looks for libc.so.6 > where I can only supply libc.so.7. Even worse is the requirement for > libpthread.so.2. There *IS* no libpthread.so.anything. There's a > libpthread.so which is a soft link to libthr.so which is itself a soft link > to libthr.so.3. > > If I try to fake any of this out with softlinks I get problems with > libpthread.so.2 since it's looking for a symbol (LIBTHREAD_1_0) which is > apparently not provided by libthr.so.3. There is nothing in /usr/ports that > seems to give me a proper libpthread that cminstall would like, so I'm > basically stuck at this point unable to install (not build -- install!) CM3 > on this FreeBSD machine. AFAIK FreeBSD always offered so-called compatibility distributions, which contain all old libraries of previous systems. You should be able to install these with the FreeBSD installer and then run cm3 and build your own binary which uses the up-to-date libs. Hope this helps, 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 ttmrichter at gmail.com Sun Aug 22 17:49:33 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Sun, 22 Aug 2010 23:49:33 +0800 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> References: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Message-ID: On 22 August 2010 22:43, Olaf Wagner wrote: > AFAIK FreeBSD always offered so-called compatibility distributions, > which contain all old libraries of previous systems. You should be > able to install these with the FreeBSD installer and then run cm3 > and build your own binary which uses the up-to-date libs. > I'm looking at FreeBSD.org and I'm not seeing anything like that at all. Sysintall doesn't offer anything like that under "distributions" either. Sorry for being such a newb here, but I really have no idea where to even LOOK for the next step. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Sun Aug 22 17:54:57 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Sun, 22 Aug 2010 23:54:57 +0800 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: References: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Message-ID: Of course about ten seconds after I post this I find the "compatx" packages in ports. Teaches me to look for full words in names! Please disregard the earlier message. ;) On 22 August 2010 23:49, Michael Richter wrote: > On 22 August 2010 22:43, Olaf Wagner wrote: > >> AFAIK FreeBSD always offered so-called compatibility distributions, >> which contain all old libraries of previous systems. You should be >> able to install these with the FreeBSD installer and then run cm3 >> and build your own binary which uses the up-to-date libs. >> > > I'm looking at FreeBSD.org and I'm not seeing anything like that at all. > Sysintall doesn't offer anything like that under "distributions" either. > Sorry for being such a newb here, but I really have no idea where to even > LOOK for the next step. > > > -- > "Perhaps people don't believe this, but throughout all of the discussions > of entering China our focus has really been what's best for the Chinese > people. It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Aug 22 18:49:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 22 Aug 2010 18:49:39 +0200 Subject: [M3devel] Installation difficulties in FreeBSD 8.1 x86 In-Reply-To: References: <20100822164349.caa2hp9ggggo0w4g@mail.elegosoft.com> Message-ID: <20100822184939.4zv8hdovuowgckok@mail.elegosoft.com> Quoting Michael Richter : > On 22 August 2010 22:43, Olaf Wagner wrote: > >> AFAIK FreeBSD always offered so-called compatibility distributions, >> which contain all old libraries of previous systems. You should be >> able to install these with the FreeBSD installer and then run cm3 >> and build your own binary which uses the up-to-date libs. >> > > I'm looking at FreeBSD.org and I'm not seeing anything like that at all. > Sysintall doesn't offer anything like that under "distributions" either. > Sorry for being such a newb here, but I really have no idea where to even > LOOK for the next step. I think this may be of help: luthien [] root # ls -ld /usr/ports/misc/compat?x drwxrwxr-x 3 root wheel 512 May 25 05:23 /usr/ports/misc/compat3x/ drwxrwxr-x 3 root wheel 512 Aug 22 05:23 /usr/ports/misc/compat4x/ drwxrwxr-x 3 root wheel 512 Aug 22 05:23 /usr/ports/misc/compat5x/ drwxrwxr-x 3 root wheel 512 Dec 6 2009 /usr/ports/misc/compat6x/ drwxr-xr-x 3 wagner wheel 512 Dec 8 2009 /usr/ports/misc/compat7x/ luthien [] root # cat /usr/ports/misc/compat6x/pkg-descr This package allows you to install the compat6x libraries on your system, so you can use legacy binaries that depend on them. Ports usage example: -- .include .if ${OSVERSION} >= 700043 LIB_DEPENDS+= c.6:${PORTSDIR}/misc/compat6x .endif -- 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 Mon Aug 23 09:57:04 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Aug 2010 09:57:04 +0200 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com> References: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com> Message-ID: <20100823095704.6pgf9a9xssc4804o@mail.elegosoft.com> Quoting Olaf Wagner : > AMD64_LINUX --> AMD64_DARWIN > --> AMD64_FREEBSD -//-> PPC_DARWIN --> I386_DARWIN > --> I386_NETBSD > --> I386_OPENBSD > --> SOLsun-opencsw-curent9s > --> SOLsun-opencsw-curent10s > --> I386_SOLARIS-opencsw-curent10x > -//-> FreeBSD4 --> LINUXLIBC6 > --> NT386 > --> PPC_LINUX > --> SPARC32_LINUX > --> SOLgnu I've now cut off the subtrees at PPC_DARWIN and FreeBSD4, as the load was still not much better. Those two poll now for themselves again, but only once or twice a day, so that the number of CVS updates and build runs should be further reduced. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 23 12:44:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 10:44:48 +0000 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100823095704.6pgf9a9xssc4804o@mail.elegosoft.com> References: <20100821182144.l470i16rs4kggckg@mail.elegosoft.com>, <20100823095704.6pgf9a9xssc4804o@mail.elegosoft.com> Message-ID: I don't really understand all of this. Surely CVS can tolerate more than 10 "active" users? Or is it really awful? (or, most likely, both) What if they all poll much less than once an hour? Let's say we have 12 machines. Have them each poll 4 times per day: 48 polls. So that's just one operation every 30 minutes. One poll, possibly followed by one update. Or, didn't you set it up so only one machine polled and all the other builds would follow it, serially? If not, that makes sense. Have one machine poll every 30 minutes. If it finds something, it builds, and the next one builds. If it finds nothing, then nothing occurs. Surely this would work ok? It merely serializes all of our Hudson jobs? Which is, granted, rather unfortunate. Adding machines should allow great parallelism. And CVS is read-mostly, so should handle plenty of load. "Read-mostly" being a property that makes systems easier to scale. I assume if I bothered to learn to use cvsup, it would help much? We'd have a few mirrors and it'd "fan out well"? e.g. 5 cvsup mirrors could each serve 5 cvs clients, 25 for the price of 5? - Jay > Date: Mon, 23 Aug 2010 09:57:04 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com; m3-support at elego.de > Subject: Re: [M3devel] changes in CM3 continuous integration setup > > Quoting Olaf Wagner : > > > AMD64_LINUX --> AMD64_DARWIN > > --> AMD64_FREEBSD -//-> PPC_DARWIN --> I386_DARWIN > > --> I386_NETBSD > > --> I386_OPENBSD > > --> SOLsun-opencsw-curent9s > > --> SOLsun-opencsw-curent10s > > --> I386_SOLARIS-opencsw-curent10x > > -//-> FreeBSD4 --> LINUXLIBC6 > > --> NT386 > > --> PPC_LINUX > > --> SPARC32_LINUX > > --> SOLgnu > > I've now cut off the subtrees at PPC_DARWIN and FreeBSD4, as the load > was still not much better. Those two poll now for themselves again, > but only once or twice a day, so that the number of CVS updates > and build runs should be further reduced. > > 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 Mon Aug 23 12:57:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 10:57:00 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com> References: , <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com> Message-ID: I noticed this too. Not sure yet where it comes from. Would folks mind if I removed "NetBSD2_i386" from the system completely? I don't think anybody uses it.. I386_NETBSD serves about the same purpose. - Jay > Date: Fri, 20 Aug 2010 14:58:09 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: VM for I386_NETBSD Hudson > > The installed cm3 still uses the wrong target platform name: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. > Fix config? > > Olaf > > Quoting Jay K : > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, > > pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 23 13:17:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 11:17:17 +0000 Subject: [M3devel] RTLinker.envp, instance removal? Message-ID: RTLinker exposes: envp instance envp is not entirely useless, but is redundant with Cstdlib.getenv, which is exposed through libm3/Env. RTLinker.envp appears somewhat broken on Windows, despite appearances that I tried to fix it. In particular, broken for gui apps. (btw, gui apps and console apps are far more the same than people realize; this whole business where Modula-3's main varies for each of them is unnecessary; the actual entry point for any Win32 console or gui app takes no parameters; the parameters the C runtime passes to main or WinMain are created by it based on stuff such as GetCommandLine, GetStartupInfo, etc.) instance is pretty much useless. Anyone that needs it can get it via GetModuleHandle(NULL); I suppose RTLinker.instance is more portable, as it'll reliably be null on posix -- ie: the #ifdef is built into startup/m3core, instead of the user's app. (on the other hand, there's probably nothing portable you can do with instance, given that it is useless on Posix) Anyway, on the general premise that less is more and things deemed buggy, of little value, and unused, are best just removed instead of fixed or improved, I propose removing both of these. Once I verify they are unused. ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 23 13:23:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 11:23:25 +0000 Subject: [M3devel] main in C or not? Message-ID: There has long been a configuration variable: MAIN_IN_C. I propose that main always be in C. I made that so already, a small change. I further propose that the support for main to not be in C be removed. "Not in C" is "generating it via the backend", directly an .obj for NT386, or going through the gcc backend for Posix. Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. I have this change about ready. I don't think avoiding C is valuable and I'd rather have fewer configuration variables. Pick one approach that works reasonably always. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Aug 23 13:41:40 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Aug 2010 13:41:40 +0200 Subject: [M3devel] changes in CM3 continuous integration setup Message-ID: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> Quoting Jay K : > I don't really understand all of this. > Surely CVS can tolerate more than 10 "active" users? > Or is it really awful? > (or, most likely, both) > What if they all poll much less than once an hour? It's not just CVS. The machine is running our WWW services, FTP, CVSup, backup for several hosts and secondary mail services. > Let's say we have 12 machines. > Have them each poll 4 times per day: 48 polls. > So that's just one operation every 30 minutes. > One poll, possibly followed by one update. That would be an individual setup for all jobs regarding polling. It's of course possible, but more tedious work again. > Or, didn't you set it up so only one machine polled and all the > other builds would follow it, serially? > If not, that makes sense. > Have one machine poll every 30 minutes. > If it finds something, it builds, and the next one builds. > If it finds nothing, then nothing occurs. > Surely this would work ok? > It merely serializes all of our Hudson jobs? > Which is, granted, rather unfortunate. > Adding machines should allow great parallelism. > And CVS is read-mostly, so should handle plenty of load. > "Read-mostly" being > a property that makes systems easier to scale. The current setup is suboptimal. I've changed things in a way that could be done quickly. But it's not easy to foretell how any change will affect the load and responsiveness, as it isn't even clear where the limits are; and other services are continually competing for resources, too. I've set up continuous logging of system load, top and iotop. You can get a quick summary with this job: http://hudson.modula3.com:8080/view/zzz/job/sysload We'll monitor this for some days and see how our changes affect the situation. Complete logs are written to Hudson's ~/log/ directory. > I assume if I bothered to learn to use cvsup, it would help much? > We'd have a few mirrors and it'd "fan out well"? > e.g. 5 cvsup mirrors could each serve 5 cvs clients, 25 for the price of 5? I think we'd only need one CVS mirror that the continous integration could use. Unfortunately, our system administrator is on vacance (his wife's expecting their second baby) right now, and I haven't got any machine for that readily available. We'll sort that out, though; don't worry too much. It may need some weeks, but we'll find an acceptable solution without much limitations. 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 Mon Aug 23 13:57:01 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 23 Aug 2010 13:57:01 +0200 Subject: [M3devel] main in C or not? In-Reply-To: References: Message-ID: <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Quoting Jay K : > There has long been a configuration variable: MAIN_IN_C. > > I propose that main always be in C. I made that so already, a small change. > > I further propose that the support for main to not be in C be removed. > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > going through the gcc backend for Posix. > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > I have this change about ready. > > I don't think avoiding C is valuable and I'd rather have fewer > configuration variables. > Pick one approach that works reasonably always. This requires that every user must have a C compiler in addition to cm3. I thought the default was not to generate C, and just require a C compiler for special runtime support. I'm not sure if this really a valid argument for the systems we support though, as we also need a system linker, and that is probably bundled with the C compiler in a development package. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Aug 23 23:51:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 21:51:44 +0000 Subject: [M3devel] main in C or not? In-Reply-To: <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Mon Aug 23 23:54:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 21:54:17 +0000 Subject: [M3devel] RTLinker.envp, instance removal? In-Reply-To: References: Message-ID: envp is used at least by posix/RTArgs so will stay. I'll investigate further: ie. if it is used on Windows, test it and make it work, else maybe make it null. Still probably remove instance if it isn't used, I don't think it has a portable use. One could compare it to null to deduce Win32 vs. Posix but there is already Compiler.ThisOS or somesuch. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: RTLinker.envp, instance removal? Date: Mon, 23 Aug 2010 11:17:17 +0000 RTLinker exposes: envp instance envp is not entirely useless, but is redundant with Cstdlib.getenv, which is exposed through libm3/Env. RTLinker.envp appears somewhat broken on Windows, despite appearances that I tried to fix it. In particular, broken for gui apps. (btw, gui apps and console apps are far more the same than people realize; this whole business where Modula-3's main varies for each of them is unnecessary; the actual entry point for any Win32 console or gui app takes no parameters; the parameters the C runtime passes to main or WinMain are created by it based on stuff such as GetCommandLine, GetStartupInfo, etc.) instance is pretty much useless. Anyone that needs it can get it via GetModuleHandle(NULL); I suppose RTLinker.instance is more portable, as it'll reliably be null on posix -- ie: the #ifdef is built into startup/m3core, instead of the user's app. (on the other hand, there's probably nothing portable you can do with instance, given that it is useless on Posix) Anyway, on the general premise that less is more and things deemed buggy, of little value, and unused, are best just removed instead of fixed or improved, I propose removing both of these. Once I verify they are unused. ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 23 23:55:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 23 Aug 2010 21:55:55 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, Message-ID: > I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration > is ignored. Alternatively I can change cm3cfg.common. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] main in C or not? Date: Mon, 23 Aug 2010 21:51:44 +0000 Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 rcolebur at SCIRES.COM Tue Aug 24 00:10:15 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:06:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:06:04 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , Message-ID: Randy, yes, that is my same understanding, from fairly recent experience. They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: extern const int max_this = 100; extern const int max_that = 200; etc. Certain updates involve changes to that file, recompile it, relink. As such, not much of a C compiler is needed. On Itanium they do give you an ANSI compiler. The K&R compiler is enough of a compile to compile some gcc 3.x, from which you can compile current gcc (or just stick with 3.x I guess). I was able to do that. The K&R compiler I think is also enough to do 64bit work, but I think offers no shared libraries and no optimization. I haven't booted my HP-UX/hppa in months now, I doubt anyone cares much, and if anyone did, we could probably require either the ANSI compiler or gcc. Perhaps perhaps perhaps I'll bring the system back up and make sure our stuff all compiles ok K&R. Perhaps. It kind of muddies the code and even e.g. gcc 4.x can't be compiled with a K&R compiler, not even with the ansi2kr build-time conversion thingy -- which, btw, I'd be willing to try to use as a compromise. Anyway, while supporting HP-UX/hppa/itanium is on some "list", it might never make it to the top. Nobody seems interested in it. The great thing about a C generating backend if you can fairly honestly claim to support "all" systems while doing "zero" work. You know, consider: #include int main() { printf("hello\n"); return 0; } What does it work on? Pretty much "everything" -- everything with a C compiler and stdio. How much porting work? Pretty much "zero". I say "fairly honestly" because there is still a small amount of #ifdef in the C code. Though the amount of #ifdef we have at present is fairly small and the number of systems it supports is fairly large. And even the generated C code might have some system-dependencies to be smushed out perhaps. autoconf might help. The C-generating backend would theoretically and really probably for real work with HP-UX, AIX, Irix, Android, iPhone, VMS, etc. besides the usual assortment of NT (including AMD64, IA64), Linux, Solaris, FreeBSD, NetBSD, OpenBSD (modulo the threading/context problems), Darwin. (iPhone has a problem with the signal headers perhaps). - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: Re: [M3devel] main in C or not? Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:06:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:06:14 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , Message-ID: Randy, yes, that is my same understanding, from fairly recent experience. They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: extern const int max_this = 100; extern const int max_that = 200; etc. Certain updates involve changes to that file, recompile it, relink. As such, not much of a C compiler is needed. On Itanium they do give you an ANSI compiler. The K&R compiler is enough of a compile to compile some gcc 3.x, from which you can compile current gcc (or just stick with 3.x I guess). I was able to do that. The K&R compiler I think is also enough to do 64bit work, but I think offers no shared libraries and no optimization. I haven't booted my HP-UX/hppa in months now, I doubt anyone cares much, and if anyone did, we could probably require either the ANSI compiler or gcc. Perhaps perhaps perhaps I'll bring the system back up and make sure our stuff all compiles ok K&R. Perhaps. It kind of muddies the code and even e.g. gcc 4.x can't be compiled with a K&R compiler, not even with the ansi2kr build-time conversion thingy -- which, btw, I'd be willing to try to use as a compromise. Anyway, while supporting HP-UX/hppa/itanium is on some "list", it might never make it to the top. Nobody seems interested in it. The great thing about a C generating backend if you can fairly honestly claim to support "all" systems while doing "zero" work. You know, consider: #include int main() { printf("hello\n"); return 0; } What does it work on? Pretty much "everything" -- everything with a C compiler and stdio. How much porting work? Pretty much "zero". I say "fairly honestly" because there is still a small amount of #ifdef in the C code. Though the amount of #ifdef we have at present is fairly small and the number of systems it supports is fairly large. And even the generated C code might have some system-dependencies to be smushed out perhaps. autoconf might help. The C-generating backend would theoretically and really probably for real work with HP-UX, AIX, Irix, Android, iPhone, VMS, etc. besides the usual assortment of NT (including AMD64, IA64), Linux, Solaris, FreeBSD, NetBSD, OpenBSD (modulo the threading/context problems), Darwin. (iPhone has a problem with the signal headers perhaps). - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: Re: [M3devel] main in C or not? Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:12:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:12:14 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , Message-ID: Randy, yes, that is my same understanding, from fairly recent experience. They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: extern const int max_this = 100; extern const int max_that = 200; etc. Certain updates involve changes to that file, recompile it, relink. As such, not much of a C compiler is needed. On Itanium they do give you an ANSI compiler. The K&R compiler is enough of a compile to compile some gcc 3.x, from which you can compile current gcc (or just stick with 3.x I guess). I was able to do that. The K&R compiler I think is also enough to do 64bit work, but I think offers no shared libraries and no optimization. I haven't booted my HP-UX/hppa in months now, I doubt anyone cares much, and if anyone did, we could probably require either the ANSI compiler or gcc. Perhaps perhaps perhaps I'll bring the system back up and make sure our stuff all compiles ok K&R. Perhaps. It kind of muddies the code and even e.g. gcc 4.x can't be compiled with a K&R compiler, not even with the ansi2kr build-time conversion thingy -- which, btw, I'd be willing to try to use as a compromise. Anyway, while supporting HP-UX/hppa/itanium is on some "list", it might never make it to the top. Nobody seems interested in it. The great thing about a C generating backend if you can fairly honestly claim to support "all" systems while doing "zero" work. You know, consider: #include int main() { printf("hello\n"); return 0; } What does it work on? Pretty much "everything" -- everything with a C compiler and stdio. How much porting work? Pretty much "zero". I say "fairly honestly" because there is still a small amount of #ifdef in the C code. Though the amount of #ifdef we have at present is fairly small and the number of systems it supports is fairly large. And even the generated C code might have some system-dependencies to be smushed out perhaps. autoconf might help. The C-generating backend would theoretically and really probably for real work with HP-UX, AIX, Irix, Android, iPhone, VMS, etc. besides the usual assortment of NT (including AMD64, IA64), Linux, Solaris, FreeBSD, NetBSD, OpenBSD (modulo the threading/context problems), Darwin. (iPhone has a problem with the signal headers perhaps). - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 23 Aug 2010 18:10:15 -0400 Subject: Re: [M3devel] main in C or not? Jay, My recollection on HPUX is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler. We purchased the ANSI C, but still had to use the K&R for kernel adjustments. But, this was many years ago (circa HPUX v9). Regards, Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, August 23, 2010 5:52 PM To: Olaf; m3devel Subject: Re: [M3devel] main in C or not? Hm. Interesting subtle angle you point out. I have seen very few systems with ld but not cc. e.g. OLPC default install. My HP-UX/hppa machine came with only a K&R cc. Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. AIX maybe also. We could potentially call ld directly. But in general I don't write the configuration files that way, they run cc for linking. *.c is used a bunch in m3core but not much else. On the other hand: cc is fairly ubiquitous. We have a "plan" for a "new distribution format" that will require cc -- users will build more of the system. Though we'll still provide binaries for some systems. I'm *really* interested in a C-generating backend, which will subsume this. Except perhaps systems like NT386, and maybe we'll expand that set. I'm becoming increasingly frustrated with the gcc backend. I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration is ignored. I'll still go ahead and make the C code typesafe via ANSI prototypes. (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef all the breakage, or require an ANSI compiler such as gcc; I assume nobody really cares about K&R). Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, but I admit I didn't fully debug these. And then, removing variations among configurations, I like. But that can be achieved via the small change for now and leaving the support in. - Jay > Date: Mon, 23 Aug 2010 13:57:01 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? > > Quoting Jay K : > > > There has long been a configuration variable: MAIN_IN_C. > > > > I propose that main always be in C. I made that so already, a small change. > > > > I further propose that the support for main to not be in C be removed. > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > going through the gcc backend for Posix. > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > I have this change about ready. > > > > I don't think avoiding C is valuable and I'd rather have fewer > > configuration variables. > > Pick one approach that works reasonably always. > > This requires that every user must have a C compiler in addition to > cm3. I thought the default was not to generate C, and just require > a C compiler for special runtime support. > > I'm not sure if this really a valid argument for the systems we support > though, as we also need a system linker, and that is probably bundled with > the C compiler in a development package. > > 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 Tue Aug 24 02:21:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 00:21:13 +0000 Subject: [M3devel] main in C or not? In-Reply-To: References: , , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , , , , Message-ID: (sorry, some hotmail error caused 3 sends) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Tue Aug 24 03:06:41 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 23 Aug 2010 21:06:41 -0400 Subject: [M3devel] main in C or not? In-Reply-To: References: Message-ID: <20100824010641.GA22229@topoi.pooq.com> On Tue, Aug 24, 2010 at 12:12:14AM +0000, Jay K wrote: > > Randy, yes, that is my same understanding, from fairly recent experience. > > > They ship the kernel as a bunch of static libraries, and one C source file with just tunable data: > extern const int max_this = 100; > extern const int max_that = 200; > etc. > > > Certain updates involve changes to that file, recompile it, relink. > As such, not much of a C compiler is needed. Watch out for binary libraries fetched in by the C compiler. Depending on license, they may prohibit making a binary distribution. -- hendrik From hosking at cs.purdue.edu Tue Aug 24 03:14:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 23 Aug 2010 21:14:52 -0400 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> 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 23 Aug 2010, at 17:51, Jay K wrote: > Hm. Interesting subtle angle you point out. > I have seen very few systems with ld but not cc. e.g. OLPC default install. > My HP-UX/hppa machine came with only a K&R cc. > Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc. > AIX maybe also. > We could potentially call ld directly. > But in general I don't write the configuration files that way, they run cc for linking. > *.c is used a bunch in m3core but not much else. > > > On the other hand: > cc is fairly ubiquitous. > We have a "plan" for a "new distribution format" that will require cc -- users will build more of the > system. Though we'll still provide binaries for some systems. > > > I'm *really* interested in a C-generating backend, which will subsume this. How will source-level debugging work in this instance? > Except perhaps systems like NT386, and maybe we'll expand that set. > I'm becoming increasingly frustrated with the gcc backend. > > > I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration > is ignored. > > > I'll still go ahead and make the C code typesafe via ANSI prototypes. > (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef > all the breakage, or require an ANSI compiler such as gcc; I assume nobody really > cares about K&R). > > > Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX, > but I admit I didn't fully debug these. And then, removing variations among configurations, I like. > But that can be achieved via the small change for now and leaving the support in. > > > - Jay > > > Date: Mon, 23 Aug 2010 13:57:01 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] main in C or not? > > > > Quoting Jay K : > > > > > There has long been a configuration variable: MAIN_IN_C. > > > > > > I propose that main always be in C. I made that so already, a small change. > > > > > > I further propose that the support for main to not be in C be removed. > > > > > > "Not in C" is "generating it via the backend", directly an .obj for NT386, or > > > going through the gcc backend for Posix. > > > > > > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C. > > > > > > I have this change about ready. > > > > > > I don't think avoiding C is valuable and I'd rather have fewer > > > configuration variables. > > > Pick one approach that works reasonably always. > > > > This requires that every user must have a C compiler in addition to > > cm3. I thought the default was not to generate C, and just require > > a C compiler for special runtime support. > > > > I'm not sure if this really a valid argument for the systems we support > > though, as we also need a system linker, and that is probably bundled with > > the C compiler in a development package. > > > > 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 Tue Aug 24 06:50:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 04:50:38 +0000 Subject: [M3devel] main in C or not? In-Reply-To: <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>, , <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> Message-ID: >> [Jay] I'm *really* interested in a C-generating backend, which will subsume this. > [Tony How will source-level debugging work in this instance? #line directiives should be used. stock gdb will have very good type information where today it has virtually none. Besides the other debuggers like windbg/VisualStudio. Expressions would be in C perhaps. You could still hack on m3gdb if you really want, but it seems of reduced utility. Compilation would likely be slower. It might be a few steps backwards besides a few steps forward. I find the lure of portability and possibly much improved exception handling (where applicable in C, else in C++), and source distribution, a very high benefit and worth some tradeoff. We'd also lose the GPL, which would please some people. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 24 07:26:14 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 24 Aug 2010 07:26:14 +0200 Subject: [M3devel] main in C or not? also, backend.... In-Reply-To: References: , , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> , , <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> Message-ID: <1282627574.2694.37.camel@localhost> Looks like a lobotomy for me. GNU Pascal folks are on similar crossroads now, only they are forced because they follow GCC changes "in realtime", as opposed to fixed version approach used by cm3. C *is* assembly and approach, except this debugger/debugging lobotomy thing, is sound. Except - there are better assemblies, and if we are divorcing cm3 from GCC then let's do it properly - going LLVM way. On Tue, 2010-08-24 at 04:50 +0000, Jay K wrote: > stock gdb will have very good type information where today it has > virtually none. > Besides the other debuggers like windbg/VisualStudio. > Expressions would be in C perhaps. > You could still hack on m3gdb if you really want, but it seems of > reduced utility. -- Dragi?a Duri? From jay.krell at cornell.edu Tue Aug 24 07:46:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 05:46:48 +0000 Subject: [M3devel] main in C or not? also, backend.... In-Reply-To: <1282627574.2694.37.camel@localhost> References: ,, , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com>,, ,, <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu>, , <1282627574.2694.37.camel@localhost> Message-ID: You could say the same thing about the gcc internal representation, but no. C is a much more portable more documented more implemented more known assembly. - Jay > From: dragisha at m3w.org > To: jay.krell at cornell.edu > Date: Tue, 24 Aug 2010 07:26:14 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] main in C or not? also, backend.... > > Looks like a lobotomy for me. > > GNU Pascal folks are on similar crossroads now, only they are forced > because they follow GCC changes "in realtime", as opposed to fixed > version approach used by cm3. > > C *is* assembly and approach, except this debugger/debugging lobotomy > thing, is sound. Except - there are better assemblies, and if we are > divorcing cm3 from GCC then let's do it properly - going LLVM way. > > On Tue, 2010-08-24 at 04:50 +0000, Jay K wrote: > > stock gdb will have very good type information where today it has > > virtually none. > > Besides the other debuggers like windbg/VisualStudio. > > Expressions would be in C perhaps. > > You could still hack on m3gdb if you really want, but it seems of > > reduced utility. > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 08:02:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 06:02:05 +0000 Subject: [M3devel] remove/rename NT386GNU/NT386MINGNU Message-ID: I'm assuming nobody here uses NT386GNU or NT386MINGNU. I'll remove them. They are replaced by I386_CYGWIN, I386_MINGW, which I think also nobody uses. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 08:18:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 06:18:50 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: , <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com>, Message-ID: aha, regression/defs.sh copied all the uname stuff out of sysinfo.sh.. I hand fixed the config already but will fix defs.sh.. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: VM for I386_NETBSD Hudson Date: Mon, 23 Aug 2010 10:57:00 +0000 I noticed this too. Not sure yet where it comes from. Would folks mind if I removed "NetBSD2_i386" from the system completely? I don't think anybody uses it.. I386_NETBSD serves about the same purpose. - Jay > Date: Fri, 20 Aug 2010 14:58:09 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: VM for I386_NETBSD Hudson > > The installed cm3 still uses the wrong target platform name: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. > Fix config? > > Olaf > > Quoting Jay K : > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, > > pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 08:51:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 06:51:04 +0000 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> References: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> Message-ID: Olaf, ssh and cvs are usually failing now. It is quite bad now. I have to retry cvs -z3 diff and cvs -z3 commit multiple times to get them to work. - Jay > Date: Mon, 23 Aug 2010 13:41:40 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; m3-support at elego.de > Subject: RE: [M3devel] changes in CM3 continuous integration setup > > Quoting Jay K : > > > I don't really understand all of this. > > Surely CVS can tolerate more than 10 "active" users? > > Or is it really awful? > > (or, most likely, both) > > What if they all poll much less than once an hour? > > It's not just CVS. The machine is running our WWW services, FTP, > CVSup, backup for several hosts and secondary mail services. > > > Let's say we have 12 machines. > > Have them each poll 4 times per day: 48 polls. > > So that's just one operation every 30 minutes. > > One poll, possibly followed by one update. > > That would be an individual setup for all jobs regarding polling. > It's of course possible, but more tedious work again. > > > Or, didn't you set it up so only one machine polled and all the > > other builds would follow it, serially? > > If not, that makes sense. > > Have one machine poll every 30 minutes. > > If it finds something, it builds, and the next one builds. > > If it finds nothing, then nothing occurs. > > Surely this would work ok? > > It merely serializes all of our Hudson jobs? > > Which is, granted, rather unfortunate. > > Adding machines should allow great parallelism. > > And CVS is read-mostly, so should handle plenty of load. > > "Read-mostly" being > > a property that makes systems easier to scale. > > The current setup is suboptimal. > I've changed things in a way that could be done quickly. > But it's not easy to foretell how any change will affect the load > and responsiveness, as it isn't even clear where the limits are; and > other services are continually competing for resources, too. > > I've set up continuous logging of system load, top and iotop. > You can get a quick summary with this job: > > http://hudson.modula3.com:8080/view/zzz/job/sysload > > We'll monitor this for some days and see how our changes affect > the situation. > > Complete logs are written to Hudson's ~/log/ directory. > > > I assume if I bothered to learn to use cvsup, it would help much? > > We'd have a few mirrors and it'd "fan out well"? > > e.g. 5 cvsup mirrors could each serve 5 cvs clients, 25 for the price of 5? > > I think we'd only need one CVS mirror that the continous integration > could use. Unfortunately, our system administrator is on vacance (his wife's > expecting their second baby) right now, and I haven't got any machine > for that readily available. > > We'll sort that out, though; don't worry too much. It may need some > weeks, but we'll find an acceptable solution without much limitations. > > 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 wagner at elegosoft.com Tue Aug 24 09:55:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 09:55:42 +0200 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: References: <20100823134140.ifb8qxlm80og0g0o@mail.elegosoft.com> Message-ID: <20100824095542.gsanecbbgko0c8w0@mail.elegosoft.com> Quoting Jay K : > Olaf, ssh and cvs are usually failing now. It is quite bad now. > I have to retry cvs -z3 diff and cvs -z3 commit multiple times to > get them to work. No use to retry in such situations, better wait a quarter of an hour. Yes, that's one of those outages we have observed for some time now. I happened to notice and observe this one. I think it was caused by two backup processes using most of the i/o bandwidth and then several CVS server instances pile up while waiting for disk blocks and prevent each other from making much progress. I think we really need a CVS mirror (as we cannot easily improve the i/o system). Sigh. I tried to stop most of the CVS processes, but response and recovery was very slow nonetheless. Things should have calmed down in the meantime 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 Tue Aug 24 10:53:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 10:53:44 +0200 Subject: [M3devel] changes in CM3 continuous integration setup Message-ID: <20100824105344.eeeppqbtus4skgoc@mail.elegosoft.com> >> AMD64_LINUX --> AMD64_DARWIN >> --> AMD64_FREEBSD -//-> PPC_DARWIN --> I386_DARWIN >> --> I386_NETBSD >> --> I386_OPENBSD >> --> SOLsun-opencsw-curent9s >> --> SOLsun-opencsw-curent10s >> --> I386_SOLARIS-opencsw-curent10x >> -//-> FreeBSD4 --> LINUXLIBC6 >> --> NT386 >> --> PPC_LINUX >> --> SPARC32_LINUX >> --> SOLgnu changed again -- further reduce build load two continuous integration servers on AMD64 and SPARC architecture AMD64_FREEBSD polls for changes every 15 minutes \------> SOLsun-opencsw-curent10s AMD64_LINUX polls once per day 23:20/55 PPC_DARWIN polls once per day 22:22/52 \----> I386_DARWIN \---> I386_NETBSD \--> I386_OPENBSD FreeBSD4 polls once per day 21:14/40 \--------> LINUXLIBC6 \-------> NT386 \------> PPC_LINUX SOLsun-opencsw-curent9s polls once per day 1:14/44 \------> I386_SOLARIS-opencsw-curent10x AMD64_DARWIN polls once per day 0:18/48 SPARC32_LINUX polls once per day 3:18/48 SOLgnu on demand only (--> opencsw job) SOLsun on demand only (--> opencsw job) Further changes to reduce build and CVS load may be made until we've set up a CVS mirror or moved away other services from birch. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Tue Aug 24 10:59:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 08:59:08 +0000 Subject: [M3devel] VM for I386_NETBSD Hudson In-Reply-To: References: , <20100820145809.byuuscwwqo4sc0cs@mail.elegosoft.com>, , Message-ID: This worked now. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: VM for I386_NETBSD Hudson Date: Tue, 24 Aug 2010 06:18:50 +0000 aha, regression/defs.sh copied all the uname stuff out of sysinfo.sh.. I hand fixed the config already but will fix defs.sh.. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: VM for I386_NETBSD Hudson Date: Mon, 23 Aug 2010 10:57:00 +0000 I noticed this too. Not sure yet where it comes from. Would folks mind if I removed "NetBSD2_i386" from the system completely? I don't think anybody uses it.. I386_NETBSD serves about the same purpose. - Jay > Date: Fri, 20 Aug 2010 14:58:09 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: VM for I386_NETBSD Hudson > > The installed cm3 still uses the wrong target platform name: > > http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_NETBSD/2/console > > NetBSD2_i386 instead of I386_NETBSD if I'm not much mistaken. > Fix config? > > Olaf > > Quoting Jay K : > > > > > New Hudson node. > > A VM running on MacBook. > > We'll see if it stays on and if the network works. > > > > I386_NETBSD > > > > ssh -p 227 hudson at jayk.homedns.org > > > > To start, it has: > > /usr/pkg/java/openjdk7/bin/java > > /cm3/bin/cm3 > > Actually a bunch in /cm3, you can get cm3cg, > > pkg/{m3core,libm3,etc.} there. > > /usr/pkg/bin/bash > > > > It is missing some libraries still so some "late" packages > > will fail. > > > > I haven't tested X apps, have to reboot the MacBook. > > And install more X libraries. > > > > AMD64_NETBSD later. > > > > I made a new node. Copied from openbsd-jkrell. > > jkrell-xnbsd. > > http://hudson.modula3.com:8080/computer/jkrell-xnbsd/ > > > > PATH=/home/hudson/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/pkg/java/openjdk7/bin:/usr/local/sbin:/usr/pkg/bin > > > > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 24 11:40:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 24 Aug 2010 09:40:20 +0000 Subject: [M3devel] changes in CM3 continuous integration setup In-Reply-To: <20100824105344.eeeppqbtus4skgoc@mail.elegosoft.com> References: <20100824105344.eeeppqbtus4skgoc@mail.elegosoft.com> Message-ID: It's still seeming really bad for me..can't work this way.. - Jay > Date: Tue, 24 Aug 2010 10:53:44 +0200 > From: wagner > To: m3devel > Subject: Re: [M3devel] changes in CM3 continuous integration setup > > changed again -- further reduce build load -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Tue Aug 24 12:37:30 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 24 Aug 2010 12:37:30 +0200 Subject: [M3devel] ***SPAM*** RE: main in C or not? also, backend.... In-Reply-To: References: ,, , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> ,, ,, <51FE7E71-F712-487C-B40E-1319B7DAF95F@cs.purdue.edu> , ,<1282627574.2694.37.camel@localhost> Message-ID: <1282646250.3321.35.camel@localhost> And with C you divorce source level from debugging. Also, Modula-3 was there, early in it's lifetime. For some reason, SRC team went debate-RMS route. IMO, it's better to make effort for better dwarf info to object code, and even better to go LLVM. On Tue, 2010-08-24 at 05:46 +0000, Jay K wrote: > You could say the same thing about the gcc internal representation, > but no. > C is a much more portable more documented more implemented more known > assembly. > > - Jay > > > From: dragisha at m3w.org > > To: jay.krell at cornell.edu > > Date: Tue, 24 Aug 2010 07:26:14 +0200 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] main in C or not? also, backend.... > > > > Looks like a lobotomy for me. > > > > GNU Pascal folks are on similar crossroads now, only they are forced > > because they follow GCC changes "in realtime", as opposed to fixed > > version approach used by cm3. > > > > C *is* assembly and approach, except this debugger/debugging > lobotomy > > thing, is sound. Except - there are better assemblies, and if we are > > divorcing cm3 from GCC then let's do it properly - going LLVM way. > > > > On Tue, 2010-08-24 at 04:50 +0000, Jay K wrote: > > > stock gdb will have very good type information where today it has > > > virtually none. > > > Besides the other debuggers like windbg/VisualStudio. > > > Expressions would be in C perhaps. > > > You could still hack on m3gdb if you really want, but it seems of > > > reduced utility. > > -- > > Dragi?a Duri? > > -- Dragi?a Duri? From wagner at elegosoft.com Tue Aug 24 17:08:47 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 17:08:47 +0200 Subject: [M3devel] main in C or not? In-Reply-To: References: , <20100823135701.esupds480k4k8k4s@mail.elegosoft.com> Message-ID: <20100824170847.alrnx5h5q8wg484k@mail.elegosoft.com> Quoting Jay K : > I'm *really* interested in a C-generating backend, which will subsume this. > Except perhaps systems like NT386, and maybe we'll expand that set. > I'm becoming increasingly frustrated with the gcc backend. The tide comes and goes. The DEC SRC people were very frustrated with the C-generating M3 compiler long ago, and invested large efforts to build the gcc backend ;-) I think I remember that Bill Kalsow, who wrote much of the original compiler code, said that "C was a very mediocre choice as an intermediate language". (It may have been somebody else who said this though.) > I can compromise and leave the code in m3linker, but I still like > the change in cm3 where the configuration > is ignored. Yes, I think we should not unnecessarily remove this. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Aug 24 17:17:28 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 24 Aug 2010 17:17:28 +0200 Subject: [M3devel] remove/rename NT386GNU/NT386MINGNU In-Reply-To: References: Message-ID: <20100824171728.ti1edlk740owc84k@mail.elegosoft.com> Quoting Jay K : > > I'm assuming nobody here uses NT386GNU or NT386MINGNU. > I'll remove them. > They are replaced by I386_CYGWIN, I386_MINGW, which I think also nobody uses. I would like to add a Cygwin build to our Hudson setup, if only the elego-win-vm wasn't so slow and so much offline. 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 Aug 26 11:45:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 09:45:01 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? Message-ID: Olaf, I have some temporary so far hypothetical interest in trying gcc 4.3.0 again -- the SOLgnu/SOLsun problem with 4.3.5. ? Really, hopefully that's not something needed long term. I have some possibly lasting so far hypothetical interest in another gcc fork -- to fork OpenBSD's 4.2.1. ?Though I guess I can try to apply their patches to 4.5.1. It is trivial and reasonable? Or it would be a pain in Hudson? ? In paritcular the notion of gcc-openbsd in a separate repository? ? I actually think maybe we should use gcc-apple for *_DARWIN but Tony disagreed and mainline seems ok. ? It is for ARM_DARWIN, which isn't in great shape (Hudson?! :) ) I'm open to moving the existing gcc (gcc-4.3/gcc-4.3.5) to its own repository. And the existing gcc-apple to its own. (Besides, a C backends wipes this all away. : ) ) I don't much like CVS but I have slowly learned to use it a bit. ? My favorite by far by far is Perforce. We could possibly use it free for open source work. ? I have lots of experience with it. It is fast. It has good gui. It has atomic changes. It does branching right (unlike svn which does branching completely wrong) I have no experience with anything else -- svn, mtn, git, hg, etc. ?- Jay From jay.krell at cornell.edu Thu Aug 26 11:46:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 09:46:54 +0000 Subject: [M3devel] moving the old gcc-4.1.1? Message-ID: Olaf, would be reasonable, easy, profitable to move the old: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.1.1/ to its own repository? Just a simple mv and done? ? Or more involved, e.g. to update existing CVS checkouts? I believe its presence slows down everyone's update/checkout. And benefits only folks interested in "archaelogoy". Maybe a gcc-4.1.1/readme.txt could be dropped in pointing to the new location? ?- Jay From wagner at elegosoft.com Thu Aug 26 12:59:16 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 26 Aug 2010 12:59:16 +0200 Subject: [M3devel] additional CVS repositories for additional gcc forks? Message-ID: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> Quoting Jay K : > Olaf, I have some temporary so far hypothetical interest in trying > gcc 4.3.0 again -- the SOLgnu/SOLsun problem with 4.3.5. > ? Really, hopefully that's not something needed long term. > > I have some possibly lasting so far hypothetical interest in another > gcc fork -- to fork OpenBSD's 4.2.1. > ?Though I guess I can try to apply their patches to 4.5.1. > > It is trivial and reasonable? > Or it would be a pain in Hudson? The main problem wrt. performance and i/o load is importing different gcc versions in different directories and not as different versions. Thus they get stored as lots of new different files, which all need to be read and their directories locked. The gcc structure is huge compared to all the M3 code. Of course, if we use the gcc versions in parallel, i.e. they are variants in one of our configuration, this is actually needed. It might help if you postpone your gcc projects for some weeks until we've either moved our WWW services or setup a repository mirror or whatever. > ? In paritcular the notion of gcc-openbsd in a separate repository? > ? I actually think maybe we should use gcc-apple for *_DARWIN but > Tony disagreed and mainline seems ok. > ? It is for ARM_DARWIN, which isn't in great shape (Hudson?! :) ) > > I'm open to moving the existing gcc (gcc-4.3/gcc-4.3.5) to its own > repository. > And the existing gcc-apple to its own. I wouldn't like to change much now, just remove what we really don't need. > (Besides, a C backends wipes this all away. : ) ) No. I would see a C backend as a variant (option) too, but probably not use it on platforms were I can compile without it. > I don't much like CVS but I have slowly learned to use it a bit. > ? My favorite by far by far is Perforce. We could possibly use it > free for open source work. Perforce is nice, agreed. I haven't used it much in practice though. I'm not sure how much effort it would cost us to get a Perforce setup, and if all users would be comfortable with it. > I have lots of experience with it. It is fast. It has good gui. It > has atomic changes. It does branching right (unlike svn which does > branching completely wrong) I wouldn't say that, though subversion still has several severe problems with merging, especially tree merges. > I have no experience with anything else -- svn, mtn, git, hg, etc. We (Elego) have, but the experience of the M3 developers will vary very much I think. Git may be an interesting option, though I'm not sure if it is really mature enough and has got all the infrastructure support we may need. We've got commercial customers who are thinking about switching over to it completely though. As I've said before, switching to another version control system will involve much tedious work, and I cannot contribute much (time) for that. However, if the M3 community decides to use something different and plans and implements a reasonable migration to the new tool(s), I wouldn't object to that. 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 Thu Aug 26 13:03:33 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 26 Aug 2010 13:03:33 +0200 Subject: [M3devel] moving the old gcc-4.1.1? In-Reply-To: References: Message-ID: <20100826130333.i4d6awas088g0cw0@mail.elegosoft.com> Quoting Jay K : > Olaf, would be reasonable, easy, profitable to move the old: > > http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc-4.1.1/ > > to its own repository? > Just a simple mv and done? > ? Or more involved, e.g. to update existing CVS checkouts? > > I believe its presence slows down everyone's update/checkout. > And benefits only folks interested in "archaelogoy". > > Maybe a gcc-4.1.1/readme.txt could be dropped in pointing to the new > location? We can just move it to another path in /usr/cvs, i.e. /usr/cvs/unused/cm3/m3cc/gcc-4.11 or however you'd like to call it. I'm not sure if the updates will just complain that something has vanished from the repository (I think so) or if they will fail: we need to check this. 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 Aug 26 13:34:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 11:34:54 +0000 Subject: [M3devel] passing structs by value Message-ID: On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. I really can't follow the complicated rules here: ?? http://www.x86-64.org/documentation/abi-0.99.pdf? but suffice it to say, records can be passed in registers, but it depends on the types of their fields. As much as we don't pass/return records by value between Modula-3 and C, that is ok. As long as Modula-3 callers/recievers agree. And they do, but... The gcc backend is given good type information at first, but historically throws much of it away. As you start to repair that, it starts following the ABI. At least at the callee side. I think the caller is still devoid of type information. I'm assuming there is a fallback rule for the case of missing type information. So if you give just one side the type information, you get a mismatch, bad code. Passing records in registers is nice, but.. (reminder: I think historically we never did). I thin we should probably just change the frontend to handle passing records by value itself. Like it does for I386_NT/NT386. For any record parameter, introduce a temporary in the caller and pass its address. ? Or whatever the code is already prepared to do. We should probably handle records returned by value similarly. This decision can be revisited if/when there is a C backend. Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. I doubt anyone else is either. I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. Further long term deficiencies this uncovers, I'm very inclined to dig further into. The right fix is probably to maintain types in the expression stack. Or at least throw in more casts on the pops. I don't think pop_param presently recieves enough type information -- no type id. ?- Jay From jay.krell at cornell.edu Thu Aug 26 13:36:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 11:36:51 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: Message-ID: aka: I propose Target.i3 standard_structs always be true, and therefore remove it and propagate true through m3front. Or at least make it always true and leave the code in m3front for future generations to revisit.. I will go ahead and test this. ? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: passing structs by value > Date: Thu, 26 Aug 2010 11:34:54 +0000 > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > I really can't follow the complicated rules here: > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > As long as Modula-3 callers/recievers agree. And they do, but... > > > The gcc backend is given good type information at first, but historically throws much of it away. > As you start to repair that, it starts following the ABI. At least at the callee side. > I think the caller is still devoid of type information. > I'm assuming there is a fallback rule for the case of missing type information. > > So if you give just one side the type information, you get a mismatch, bad code. > > > Passing records in registers is nice, but.. > (reminder: I think historically we never did). > > > I thin we should probably just change the frontend to handle passing records by value itself. > Like it does for I386_NT/NT386. > > > For any record parameter, introduce a temporary in the caller and pass its address. > Or whatever the code is already prepared to do. > > > We should probably handle records returned by value similarly. > > > This decision can be revisited if/when there is a C backend. > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > I doubt anyone else is either. > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > The right fix is probably to maintain types in the expression stack. > Or at least throw in more casts on the pops. > > > I don't think pop_param presently recieves enough type information -- no type id. > > > - Jay > From jay.krell at cornell.edu Thu Aug 26 13:46:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 11:46:13 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> Message-ID: > No. I would see a C backend as a variant (option) too, but probably not > use it on platforms were I can compile without it. I would like to see a C backend at least replace the gcc backend. We could maybe then slowly iterate on the integrated backend. Or LLVM. It would provide more obvious correctness, better debugging, better code quality. Imagine -- basically all platforms would get stack walkers. By generating C++ for most platforms, or using C exception handling in NT/VMS/Tru64. Basically all platforms would just work. Stock debuggers would work, gdb and others. Basically no more porting. Basically all optimizations could be enabled. (Aside: I think the generated C would be sure to store gc roots in volatile locals, but not otherwise use said volatiles.) And in more recent developments, it would enregister some records passed by value. It would, in a sense, shrink the code base (cheating sort of). I'm not holding my breath on any of this. But I'm going to start trying to do more and talk less about it. - Jay ---------------------------------------- > Date: Thu, 26 Aug 2010 12:59:16 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: additional CVS repositories for additional gcc forks? > > Quoting Jay K : > > > Olaf, I have some temporary so far hypothetical interest in trying > > gcc 4.3.0 again -- the SOLgnu/SOLsun problem with 4.3.5. > > Really, hopefully that's not something needed long term. > > > > I have some possibly lasting so far hypothetical interest in another > > gcc fork -- to fork OpenBSD's 4.2.1. > > Though I guess I can try to apply their patches to 4.5.1. > > > > It is trivial and reasonable? > > Or it would be a pain in Hudson? > > The main problem wrt. performance and i/o load is importing different > gcc versions in different directories and not as different versions. > Thus they get stored as lots of new different files, which all need > to be read and their directories locked. The gcc structure is huge > compared to all the M3 code. Of course, if we use the gcc versions in > parallel, i.e. they are variants in one of our configuration, this > is actually needed. > > It might help if you postpone your gcc projects for some weeks until > we've either moved our WWW services or setup a repository mirror or > whatever. > > > In paritcular the notion of gcc-openbsd in a separate repository? > > I actually think maybe we should use gcc-apple for *_DARWIN but > > Tony disagreed and mainline seems ok. > > It is for ARM_DARWIN, which isn't in great shape (Hudson?! :) ) > > > > I'm open to moving the existing gcc (gcc-4.3/gcc-4.3.5) to its own > > repository. > > And the existing gcc-apple to its own. > > I wouldn't like to change much now, just remove what we really don't > need. > > > (Besides, a C backends wipes this all away. : ) ) > > No. I would see a C backend as a variant (option) too, but probably not > use it on platforms were I can compile without it. > > > I don't much like CVS but I have slowly learned to use it a bit. > > My favorite by far by far is Perforce. We could possibly use it > > free for open source work. > > Perforce is nice, agreed. I haven't used it much in practice though. > I'm not sure how much effort it would cost us to get a Perforce setup, > and if all users would be comfortable with it. > > > I have lots of experience with it. It is fast. It has good gui. It > > has atomic changes. It does branching right (unlike svn which does > > branching completely wrong) > > I wouldn't say that, though subversion still has several severe problems > with merging, especially tree merges. > > > I have no experience with anything else -- svn, mtn, git, hg, etc. > We (Elego) have, but the experience of the M3 developers will vary > very much I think. > > Git may be an interesting option, though I'm not sure if it is really > mature enough and has got all the infrastructure support we may need. > We've got commercial customers who are thinking about switching over to > it completely though. > > As I've said before, switching to another version control system will > involve much tedious work, and I cannot contribute much (time) > for that. However, if the M3 community decides to use something > different and plans and implements a reasonable migration to the > new tool(s), I wouldn't object to that. > > 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 Thu Aug 26 14:10:22 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 26 Aug 2010 14:10:22 +0200 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com> Message-ID: <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> Quoting Jay K : > > No. I would see a C backend as a variant (option) too, but probably not > > use it on platforms were I can compile without it. > > I would like to see a C backend at least replace the gcc backend. > We could maybe then slowly iterate on the integrated backend. Or LLVM. > It would provide more obvious correctness, better debugging, better > code quality. I don't really see that yet. > Imagine -- basically all platforms would get stack walkers. > By generating C++ for most platforms, or using C exception > handling in NT/VMS/Tru64. > Basically all platforms would just work. I doubt that very much. > Stock debuggers would work, gdb and others. > Basically no more porting. > Basically all optimizations could be enabled. > (Aside: I think the generated C would be sure to store > gc roots in volatile locals, but not otherwise use said volatiles.) As I said: it has been tried before. > And in more recent developments, it would enregister some records > passed by value. > It would, in a sense, shrink the code base (cheating sort of). And it would be an order of magnitude slower. > I'm not holding my breath on any of this. > But I'm going to start trying to do more and talk less about it. I will let you convince me ;-) I've got no problem with trying that. If it's really better, we will use it. If not, we may want to use it for special situations (e.g. porting). 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 Aug 26 14:23:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Aug 2010 12:23:36 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> Message-ID: ?>? better code quality Use the native C++ exception handling. Not more calling setjmp all over the place. Inlining. Currnetly disabled in 4.5.1 because it breaks things. LTO/LTCG -- which we could get today, on gcc platforms, if we are willing to import even more code. ?(link time optimization, link time code gen). e.g. cross module inlining. see also PGO -- profile guided optimization. i.e. whatever the full C/C++ toolset is, you can use it. ?> better debugging ? Existing debuggers would work and work well. Notice today that NT386 has only line numbers. That there are systems that don't support stabs -- e.g. HP-UX. That other -g switches to cm3cg crash. > > Basically all platforms would just work. > > I doubt that very much. It's only a slight exaggeration. We'd still need our #ifdef'ing of the C code. Possibly guided by autoconf. And there are still the threading/gc issues. But for example, we should work on any processor for any operating system for which we already work -- NT, Linux, NetBSD, FreeBSD, Solaris, OSF -- on any processors. And AIX, Irix, VMS would work or be closer to working. (IA64 might need an #ifdef) Anyway, I'll try to work on it. > And it would be an order of magnitude slower. It would be slower. I'm not sure by how much. ?- Jay ---------------------------------------- > Date: Thu, 26 Aug 2010 14:10:22 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? > > Quoting Jay K : > > > > No. I would see a C backend as a variant (option) too, but probably not > > > use it on platforms were I can compile without it. > > > > I would like to see a C backend at least replace the gcc backend. > > We could maybe then slowly iterate on the integrated backend. Or LLVM. > > It would provide more obvious correctness, better debugging, better > > code quality. > > I don't really see that yet. > > > Imagine -- basically all platforms would get stack walkers. > > By generating C++ for most platforms, or using C exception > > handling in NT/VMS/Tru64. > > Basically all platforms would just work. > > I doubt that very much. > > > Stock debuggers would work, gdb and others. > > Basically no more porting. > > Basically all optimizations could be enabled. > > (Aside: I think the generated C would be sure to store > > gc roots in volatile locals, but not otherwise use said volatiles.) > > As I said: it has been tried before. > > > And in more recent developments, it would enregister some records > > passed by value. > > It would, in a sense, shrink the code base (cheating sort of). > > And it would be an order of magnitude slower. > > > I'm not holding my breath on any of this. > > But I'm going to start trying to do more and talk less about it. > > I will let you convince me ;-) > I've got no problem with trying that. If it's really better, we will > use it. If not, we may want to use it for special situations (e.g. porting). > > 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 Aug 27 08:14:05 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 08:14:05 +0200 Subject: [M3devel] Fwd: [CM3] #1148: CVSup stalls on several platforms Message-ID: <20100827081405.vw7d059ulcg8wgcc@mail.elegosoft.com> FYI -- I thought this was working, but it's still broken... ----- Forwarded message from bugs at elego.de ----- Date: Fri, 27 Aug 2010 06:05:05 -0000 From: CM3 Reply-To: CM3 Subject: [CM3] #1148: CVSup stalls on several platforms To: wagner at elego.de #1148: CVSup stalls on several platforms --------------------------+------------------------------------------------- Reporter: wagner | Owner: wagner Type: sw-bug | Status: new Priority: high | Milestone: CM3 Release 5.9 Component: misc | Version: 5.8-RC3 Severity: serious | Keywords: cvsup, stalling, hanging, pthreads Relnote: | Org: Estimatedhours: 0 | Hours: 0 Billable: 0 | Totalhours: 0 Internal: 0 | --------------------------+------------------------------------------------- Htr: try to mirror the cm3 repository, possible any other, too Fix: Env: --------------------------+------------------------------------------------- We either still have a problem with fork, or in the pthreads implementation. Here's some evidence from a mail thread: I do, but I'm having trouble with cvsup from release_branch_cm3_5_8 LINUXLIB6. It stalls and hangs after a few minutes. strace says this forever: clone(child_stack=0xb140f4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb140fbd8, {entry_number:6, base_addr:0xb140fb90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb140fbd8) = 20265 write(1, "Running\n"..., 8Running ) = 8 futex(0x80ac0cc, FUTEX_WAIT, 5, NULL) = -1 EINTR (Interrupted system call) --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- rt_sigsuspend(~[INT QUIT ABRT TERM RTMIN RT_1] --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- <... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call) rt_sigreturn(0xb7aedf00) = -1 EINTR (Interrupted system call) rt_sigreturn(0x80ac0cc) = -1 EINTR (Interrupted system call) futex(0x80ac0cc, FUTEX_WAIT, 5, NULL) = -1 EINTR (Interrupted system call) --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- rt_sigsuspend(~[INT QUIT ABRT TERM RTMIN RT_1] --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- <... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call) rt_sigreturn(0xb7aedf00) = -1 EINTR (Interrupted system call) rt_sigreturn(0x80ac0cc) = -1 EINTR (Interrupted system call) futex(0x80ac0cc, FUTEX_WAIT, 5, NULL) = -1 EINTR (Interrupted system call) --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- rt_sigsuspend(~[INT QUIT ABRT TERM RTMIN RT_1] --- SIGRT_32 (Real-time signal 30) @ 0 (0) --- Any ideas there? Maybe I'll just reinstall with FreeBSD ;-) Is this with the actual release (5.8.6) or any RC? Yes, I used cm3-bin-core-LINUXLIBC6-5.8.6-REL.tgz and cm3-src-all-5.8.6-REL.tgz with. wiley:/home/mand# cvsup -v CVSup client, GUI version Copyright 1996-2003 John D. Polstra Software version: release_branch_cm3_5_8 Protocol version: 17.0 Operating system: LINUXLIBC6 @Jay, you did correct the process startup so that CVSup should work, didn't you? Any ideas about this one? @Mike, can you attach with gdb and get a stack backtrace? Here it is... wiley:/home/mand# gdb -p 32607 GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". Attaching to process 32607 Reading symbols from /usr/local/cm3/bin/cvsup...done. Reading symbols from /usr/local/cm3/lib/libm3formsvbt.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3formsvbt.so.5 Reading symbols from /usr/local/cm3/lib/libm3formsvbtpixmaps.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3formsvbtpixmaps.so.5 Reading symbols from /usr/local/cm3/lib/libvideovbt.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libvideovbt.so.5 Reading symbols from /usr/local/cm3/lib/libweb.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libweb.so.5 Reading symbols from /usr/local/cm3/lib/libjvideo.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libjvideo.so.5 Reading symbols from /usr/local/cm3/lib/libm3vbtkit.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3vbtkit.so.5 Reading symbols from /usr/local/cm3/lib/libm3ui.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3ui.so.5 Reading symbols from /usr/local/cm3/lib/libm3X11R4.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3X11R4.so.5 Reading symbols from /usr/local/cm3/lib/libsuplib.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libsuplib.so.5 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/local/cm3/lib/libm3tcp.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3tcp.so.5 Reading symbols from /usr/local/cm3/lib/libset.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libset.so.5 Reading symbols from /usr/local/cm3/lib/libTempFiles.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libTempFiles.so.5 Reading symbols from /usr/local/cm3/lib/libm3.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3.so.5 Reading symbols from /usr/local/cm3/lib/libm3core.so.5...done. Loaded symbols for /usr/local/cm3/bin/../lib/libm3core.so.5 Reading symbols from /usr/lib/libXaw.so.7...done. Loaded symbols for /usr/lib/libXaw.so.7 Reading symbols from /usr/lib/libXmu.so.6...done. Loaded symbols for /usr/lib/libXmu.so.6 Reading symbols from /usr/lib/libXext.so.6...done. Loaded symbols for /usr/lib/libXext.so.6 Reading symbols from /usr/lib/libXt.so.6...done. Loaded symbols for /usr/lib/libXt.so.6 Reading symbols from /usr/lib/libSM.so.6...done. Loaded symbols for /usr/lib/libSM.so.6 Reading symbols from /usr/lib/libICE.so.6...done. Loaded symbols for /usr/lib/libICE.so.6 Reading symbols from /usr/lib/libX11.so.6...done. Loaded symbols for /usr/lib/libX11.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 0xb6ec26b0 (LWP 32607)] [New Thread 0xb140fb90 (LWP 32617)] [New Thread 0xb1e0fb90 (LWP 32616)] [New Thread 0xb320fb90 (LWP 32614)] [New Thread 0xb3c0fb90 (LWP 32613)] [New Thread 0xb460fb90 (LWP 32612)] [New Thread 0xb5051b90 (LWP 32611)] [New Thread 0xb5a7fb90 (LWP 32610)] [New Thread 0xb647fb90 (LWP 32609)] [New Thread 0xb6e7fb90 (LWP 32608)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libXpm.so.4...done. Loaded symbols for /usr/lib/libXpm.so.4 Reading symbols from /usr/lib/libXau.so.6...done. Loaded symbols for /usr/lib/libXau.so.6 Reading symbols from /usr/lib/libxcb-xlib.so.0...done. Loaded symbols for /usr/lib/libxcb-xlib.so.0 Reading symbols from /usr/lib/libxcb.so.1...done. Loaded symbols for /usr/lib/libxcb.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libXdmcp.so.6...done. Loaded symbols for /usr/lib/libXdmcp.so.6 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_mdns4_minimal.so.2...done. Loaded symbols for /lib/libnss_mdns4_minimal.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libnss_compat.so.2...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libnss_nis.so.2...done. Loaded symbols for /lib/libnss_nis.so.2 0xb6f2599d in sigsuspend () from /lib/libc.so.6 (gdb) bt #0 0xb6f2599d in sigsuspend () from /lib/libc.so.6 #1 0xb72a7ece in ThreadPThread__sigsuspend () at ../src/thread/PTHREAD/ThreadPThreadC.c:141 #2 0xb72a6d56 in ThreadPThread__SignalHandler (M3_DLS2Hj_sig=64, M3_AJWxb1_info=0xbfffc6f0, M3_AJWxb1_context=0xbfffc770) at ../src/thread/PTHREAD/ThreadPThread.m3:1205 #3 #4 0xb70438f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #5 0xb72a84d6 in ThreadPThread__pthread_cond_wait (cond=0x80ac0c8, mutex=0x80ac0a8) at ../src/thread/PTHREAD/ThreadPThreadC.c:507 #6 0xb72a29a9 in ThreadPThread__XWait (M3_DMxDjQ_self=0x80ac018, M3_AYIbX3_m=0xb6e84bc4, M3_Bl0jv4_c=0xb6e84bdc, M3_AicXUJ_alertable=1 '\001') at ../src/thread/PTHREAD/ThreadPThread.m3:183 #7 0xb72a2a71 in Thread__AlertWait (M3_AYIbX3_m=0xb6e84bc4, M3_Bl0jv4_c=0xb6e84bdc) at ../src/thread/PTHREAD/ThreadPThread.m3:196 #8 0xb7cdd671 in Reaper__AlertJoinNext (M3_Cjq8Fl_reaper=0xb6e84bc4, M3_DTZVTc_thr=0xbfffcf50, M3_EKuYlT_ret=0xbfffcf54) at ../src/Reaper.m3:111 #9 0x08079323 in FSClient__Apply (M3_EVLLAD_self=0xb6eb5ab8) at ../src/FSClient.m3:201 #10 0x08091e26 in Main_M3 (M3_AcxOUs_mode=1) at ../src/Main.m3:398 #11 0xb7292ccb in RTLinker__RunMainBody (M3_DjPxE3_m=0x80a6d40) at ../src/runtime/common/RTLinker.m3:406 #12 0xb7291ffe in RTLinker__AddUnitI (M3_DjPxE3_m=0x80a6d40) at ../src/runtime/common/RTLinker.m3:113 #13 0xb729208c in RTLinker__AddUnit (M3_DjPxE5_b=0x808d275) at ../src/runtime/common/RTLinker.m3:122 #14 0x0804e9ce in main (argc=6, argv=0xbfffd914, envp=0xbfffd930) at _m3main.mc:4 (gdb) 2 or 3 thoughts: o Did you turn off the GUI (I think -g)? Yes. o Did you increase the debugging level (-L 2?)? Yes. o Have you tried an old binary e.g. from our DCVS packages? Not yet. I'll try that next. [update: yes, it works, needs libc6-i386 of course] I upgraded my vServer and installed a 64-bit Ubuntu with cm3 from AMD_64 sources, but encountered the same stall. I thought perhaps this might have to do with the modified kernel or ulimits on the vServer, but as it turns out, cvsup on birch also hangs, as well as on willow (Ubuntu i386). -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 Aug 27 08:14:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 08:14:59 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms Message-ID: <20100827081459.s88b14400448owk8@mail.elegosoft.com> FYI -- fixed version info (5.8.6) ----- Forwarded message from bugs at elego.de ----- Date: Fri, 27 Aug 2010 06:09:55 -0000 From: CM3 Reply-To: CM3 Subject: Re: [CM3] #1148: CVSup stalls on several platforms To: wagner at elego.de #1148: CVSup stalls on several platforms --------------------------+------------------------------------------------- Reporter: wagner | Owner: wagner Type: sw-bug | Status: new Priority: high | Milestone: CM3 Release 5.9 Component: misc | Version: 5.8.6 Severity: serious | Keywords: cvsup, stalling, hanging, pthreads Relnote: | Org: Estimatedhours: 0.0 | Hours: 0 Billable: 0 | Totalhours: 0 Internal: 0 | --------------------------+------------------------------------------------- Htr: try to mirror the cm3 repository, possible any other, too Fix: Env: --------------------------+------------------------------------------------- Changes (by wagner): * version: 5.8-RC3 => 5.8.6 -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 Fri Aug 27 09:01:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 07:01:57 +0000 Subject: [M3devel] m3cc often succeeds when it should fail Message-ID: I finally looked into this. The reason is that the exit code of a pipeline is the last command. Seems kind of dumb and I don't like any of the options. I like having tee in there to save a log. There is a way to deal it with bash, zsh, and it takes a big function to do it in standard sh. Maybe q_exec or m3_exec? It looks like no. I suppose we could wrap up everything in a .sh file, detect bash 3 or newer, and use set -o pipefail? ?- Jay From jay.krell at cornell.edu Fri Aug 27 09:19:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 07:19:59 +0000 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: References: Message-ID: We could introduce a new quake feature.. if defined("set_pipefail") ? set_pipefail() end q_exec() ? ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 27 Aug 2010 07:01:57 +0000 > Subject: [M3devel] m3cc often succeeds when it should fail > > > I finally looked into this. > > The reason is that the exit code of a pipeline is the last command. > Seems kind of dumb and I don't like any of the options. > I like having tee in there to save a log. > > There is a way to deal it with bash, zsh, and it takes a big function to do it in standard sh. > > Maybe q_exec or m3_exec? > It looks like no. > > I suppose we could wrap up everything in a .sh file, detect bash 3 or newer, and use set -o pipefail? > > - Jay > From jay.krell at cornell.edu Fri Aug 27 11:12:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 09:12:00 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: , Message-ID: Easier said than done. Setting standard_structs = TRUE I thought would free the backend from worrying about passing or returning structs at all, but that's far from true. I thought the frontend would introduce temporaries and pass their addresses. But no. See for example what M3x86 does in pop_struct. Frustrating. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: passing structs by value > Date: Thu, 26 Aug 2010 11:36:51 +0000 > > > aka: I propose Target.i3 standard_structs always be true, and therefore remove it and propagate true through m3front. > Or at least make it always true and leave the code in m3front for future generations to revisit.. > > I will go ahead and test this. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: passing structs by value > > Date: Thu, 26 Aug 2010 11:34:54 +0000 > > > > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > I really can't follow the complicated rules here: > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > As you start to repair that, it starts following the ABI. At least at the callee side. > > I think the caller is still devoid of type information. > > I'm assuming there is a fallback rule for the case of missing type information. > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > Passing records in registers is nice, but.. > > (reminder: I think historically we never did). > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > Like it does for I386_NT/NT386. > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > Or whatever the code is already prepared to do. > > > > > > We should probably handle records returned by value similarly. > > > > > > This decision can be revisited if/when there is a C backend. > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > I doubt anyone else is either. > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > The right fix is probably to maintain types in the expression stack. > > Or at least throw in more casts on the pops. > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > - Jay > > > From jay.krell at cornell.edu Fri Aug 27 11:21:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 09:21:42 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: , , Message-ID: Hm. I think the right fix here is to pass a typeid to pop_struct. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: passing structs by value > Date: Fri, 27 Aug 2010 09:12:00 +0000 > > > Easier said than done. > Setting standard_structs = TRUE I thought would free the backend from worrying > about passing or returning structs at all, but that's far from true. > I thought the frontend would introduce temporaries and pass their addresses. But no. > > See for example what M3x86 does in pop_struct. > Frustrating. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: RE: passing structs by value > > Date: Thu, 26 Aug 2010 11:36:51 +0000 > > > > > > aka: I propose Target.i3 standard_structs always be true, and therefore remove it and propagate true through m3front. > > Or at least make it always true and leave the code in m3front for future generations to revisit.. > > > > I will go ahead and test this. > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Subject: passing structs by value > > > Date: Thu, 26 Aug 2010 11:34:54 +0000 > > > > > > > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > > > I really can't follow the complicated rules here: > > > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > > As you start to repair that, it starts following the ABI. At least at the callee side. > > > I think the caller is still devoid of type information. > > > I'm assuming there is a fallback rule for the case of missing type information. > > > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > > > > Passing records in registers is nice, but.. > > > (reminder: I think historically we never did). > > > > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > > Like it does for I386_NT/NT386. > > > > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > > Or whatever the code is already prepared to do. > > > > > > > > > We should probably handle records returned by value similarly. > > > > > > > > > This decision can be revisited if/when there is a C backend. > > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > > I doubt anyone else is either. > > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > > > > The right fix is probably to maintain types in the expression stack. > > > Or at least throw in more casts on the pops. > > > > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > > > > - Jay > > > > > > From michael.anderson at elego.de Fri Aug 27 12:03:06 2010 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 27 Aug 2010 12:03:06 +0200 Subject: [M3devel] [elego Server Maintenance] Friday 27.08.2010 20:00 Message-ID: <20100827120306.2yrr0fzucgcksk0g@mail.elego.de> Hello, On Friday, August 27 at 8 PM CEST, we will perform scheduled maintenance on our servers, including the modula3 CVS server and Hudson CI server. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 27 12:29:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 10:29:41 +0000 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: <20100827081459.s88b14400448owk8@mail.elegosoft.com> References: <20100827081459.s88b14400448owk8@mail.elegosoft.com> Message-ID: Can you add more information to the bug as to how to reproduce the problem? Exact files? cvsup.conf or whatnot? Exact command lines? I don't use cvsup, don't know how to set it up. Before when I debugging this it wasn't too difficult though. Perhaps we can put something in m3-sys/m3tests even? ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 08:14:59 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms > > FYI -- fixed version info (5.8.6) > > ----- Forwarded message from bugs at elego.de ----- > Date: Fri, 27 Aug 2010 06:09:55 -0000 > From: CM3 > Reply-To: CM3 > Subject: Re: [CM3] #1148: CVSup stalls on several platforms > To: wagner at elego.de > > #1148: CVSup stalls on several platforms > --------------------------+------------------------------------------------- > Reporter: wagner | Owner: wagner > Type: sw-bug | Status: new > Priority: high | Milestone: CM3 Release 5.9 > Component: misc | Version: 5.8.6 > Severity: serious | Keywords: cvsup, stalling, hanging, pthreads > Relnote: | Org: > Estimatedhours: 0.0 | Hours: 0 > Billable: 0 | Totalhours: 0 > Internal: 0 | > --------------------------+------------------------------------------------- > Htr: > try to mirror the cm3 repository, possible any other, too > > > Fix: > > > > Env: > > > --------------------------+------------------------------------------------- > Changes (by wagner): > > * version: 5.8-RC3 => 5.8.6 > > > -- > Ticket URL: > CM3 > Critical Mass Modula3 Compiler > > > ----- End forwarded message ----- > > > -- > 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 Aug 27 13:01:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 13:01:23 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: References: <20100827081459.s88b14400448owk8@mail.elegosoft.com> Message-ID: <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com> Quoting Jay K : > Can you add more information to the bug as to how to reproduce the problem? > Exact files? cvsup.conf or whatnot? > Exact command lines? > > I don't use cvsup, don't know how to set it up. > Before when I debugging this it wasn't too difficult though. > > Perhaps we can put something in m3-sys/m3tests even? I will try to set up an automated cvsup test at the weekend. In our DCVS distribution we had quite a few replication tests; perhaps I can burrow something from that. It won't go into m3tests though, but rather be a subdir to cvsup. m3-sys/m3tests is for language/compiler tests. 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 michael.anderson at elego.de Fri Aug 27 13:25:57 2010 From: michael.anderson at elego.de (Michael Anderson) Date: Fri, 27 Aug 2010 13:25:57 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com> References: <20100827081459.s88b14400448owk8@mail.elegosoft.com> <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com> Message-ID: <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> Quoting Olaf Wagner : > Quoting Jay K : > >> Can you add more information to the bug as to how to reproduce the problem? >> Exact files? cvsup.conf or whatnot? >> Exact command lines? >> I'm able to reliably reproduce the problem with this command: /usr/local/cm3/bin/cvsup -g -L 2 cvsupfile.cm3 where the cvsupfile contains: *default host=birch.elego.de *default base=/home/mand/tmp/cvsup *default prefix=/home/mand/tmp/cvs *default release=cvs *default delete use-rel-suffix *default preserve cm3 Sometimes the first sync will finish, but a subsequent sync will hang. >> I don't use cvsup, don't know how to set it up. >> Before when I debugging this it wasn't too difficult though. >> >> Perhaps we can put something in m3-sys/m3tests even? > > I will try to set up an automated cvsup test at the weekend. > In our DCVS distribution we had quite a few replication tests; > perhaps I can burrow something from that. > > It won't go into m3tests though, but rather be a subdir to cvsup. > m3-sys/m3tests is for language/compiler tests. > > 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 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Aug 27 13:44:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 11:44:02 +0000 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> References: <20100827081459.s88b14400448owk8@mail.elegosoft.com>, , <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com>, <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> Message-ID: Michael, thank you. Please add it to the bug. ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 13:25:57 +0200 > From: michael.anderson at elego.de > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms > > Quoting Olaf Wagner : > > > Quoting Jay K : > > > >> Can you add more information to the bug as to how to reproduce the problem? > >> Exact files? cvsup.conf or whatnot? > >> Exact command lines? > >> > > > I'm able to reliably reproduce the problem with this command: > > /usr/local/cm3/bin/cvsup -g -L 2 cvsupfile.cm3 > > where the cvsupfile contains: > > *default host=birch.elego.de > *default base=/home/mand/tmp/cvsup > *default prefix=/home/mand/tmp/cvs > *default release=cvs > *default delete use-rel-suffix > *default preserve > cm3 > > Sometimes the first sync will finish, but a subsequent sync will hang. > > >> I don't use cvsup, don't know how to set it up. > >> Before when I debugging this it wasn't too difficult though. > >> > >> Perhaps we can put something in m3-sys/m3tests even? > > > > I will try to set up an automated cvsup test at the weekend. > > In our DCVS distribution we had quite a few replication tests; > > perhaps I can burrow something from that. > > > > It won't go into m3tests though, but rather be a subdir to cvsup. > > m3-sys/m3tests is for language/compiler tests. > > > > 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 > > > > -- > Michael Anderson > IT Services & Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Building 12.3 (BIG) room 227 > 13355 Berlin, Germany > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > fax +49 30 23 45 86 95 http://www.elegosoft.com > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > From jay.krell at cornell.edu Fri Aug 27 13:45:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 11:45:07 +0000 Subject: [M3devel] type id for globals? Message-ID: Is it reasonable to desire a typeid for the globals records? ie. to assist in generating type information? I guess I don't need it after all, really.. (3553) comment ? quoted_string:global data type descriptor ? comment: `global data type descriptor' (3554) declare_record ? record id:0xffffffff fields:0xc size:0x3c80 (3555) declare_field ? quoted_string:types ? field types, id 0x454792e7, size 0x240, offset 0x640 (3556) declare_field ? quoted_string:uids ? field uids, id 0x454792e7, size 0x240, offset 0x880 (3557) declare_field ? quoted_string:brands ? field brands, id 0x454792e7, size 0x240, offset 0xac0 (3558) declare_field ? quoted_string:Dummy1_typecell ? field Dummy1_typecell, id 0xf8c78b31, size 0x300, offset 0x1600 (3559) declare_field ? quoted_string:Dummy3_typecell ? field Dummy3_typecell, id 0xf8c78b31, size 0x300, offset 0x1900 (3560) declare_field ? quoted_string:NULL_typecell ? field NULL_typecell, id 0xf8c78b31, size 0x300, offset 0x1c00 (3561) declare_field ? quoted_string:UNROOT_typecell ? field UNROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x1f00 (3562) declare_field ? quoted_string:ROOT_typecell ? field ROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x23c0 (3563) declare_field From hosking at cs.purdue.edu Fri Aug 27 16:00:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Aug 2010 10:00:32 -0400 Subject: [M3devel] type id for globals? In-Reply-To: References: Message-ID: <48EBBDD6-52BE-47DB-A8C8-49413477C615@cs.purdue.edu> Not sure... haven't really been following much lately... On 27 Aug 2010, at 07:45, Jay K wrote: > > Is it reasonable to desire a typeid for the globals records? > ie. to assist in generating type information? > I guess I don't need it after all, really.. > > (3553) comment > quoted_string:global data type descriptor > comment: `global data type descriptor' > (3554) declare_record > record id:0xffffffff fields:0xc size:0x3c80 > (3555) declare_field > quoted_string:types > field types, id 0x454792e7, size 0x240, offset 0x640 > (3556) declare_field > quoted_string:uids > field uids, id 0x454792e7, size 0x240, offset 0x880 > (3557) declare_field > quoted_string:brands > field brands, id 0x454792e7, size 0x240, offset 0xac0 > (3558) declare_field > quoted_string:Dummy1_typecell > field Dummy1_typecell, id 0xf8c78b31, size 0x300, offset 0x1600 > (3559) declare_field > quoted_string:Dummy3_typecell > field Dummy3_typecell, id 0xf8c78b31, size 0x300, offset 0x1900 > (3560) declare_field > quoted_string:NULL_typecell > field NULL_typecell, id 0xf8c78b31, size 0x300, offset 0x1c00 > (3561) declare_field > quoted_string:UNROOT_typecell > field UNROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x1f00 > (3562) declare_field > quoted_string:ROOT_typecell > field ROOT_typecell, id 0x909bfd1e, size 0x4c0, offset 0x23c0 > (3563) declare_field > > > > > From wagner at elegosoft.com Fri Aug 27 17:17:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 17:17:23 +0200 Subject: [M3devel] Potential bug in RTAllocator.Clone, was: Fwd: Auto-discard notification Message-ID: <20100827171723.2a60uadm0wos04gw@mail.elegosoft.com> Forwarded; sent before subscription was confirmed: The attached message has been automatically discarded. Info The following are the headers for this message/rfc822 message. Date: Fri, 27 Aug 2010 15:39:23 +0100 Subject: Potential bug in RTAllocator.Clone From: Raja Mukherji To: m3devel at elegosoft.com 2.1 unnamed [text/plain] 0.58 KB Download Hi, this is my first post to the Modula-3 mailing list... While using RTAllocator.Clone in a project, I kept getting errors related to the type of the returned object. The debugger m3gdb returned a TYPECODE of 0. I think the cause is line 84 in RTAllocator.m3 which currently reads res := AllocTraced(dataSize, def.dataAlignment, thread^); which doesn't seem to set the header of the clone. Changing it to res := LOOPHOLE(GetTraced(def), ADDRESS); seems to fix the problems, but since I'm not that familiar with the object representation I thought I should ask here first. Thanks, Raja ----- Forwarded message from m3devel-bounces at elegosoft.com ----- Date: Fri, 27 Aug 2010 16:48:17 +0200 From: m3devel-bounces at elegosoft.com Reply-To: m3devel-bounces at elegosoft.com Subject: Auto-discard notification To: m3devel-owner at elegosoft.com The attached message has been automatically discarded. ----- End forwarded message ----- -- 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 rajamukherji at gmail.com Fri Aug 27 17:19:18 2010 From: rajamukherji at gmail.com (Raja Mukherji) Date: Fri, 27 Aug 2010 16:19:18 +0100 Subject: [M3devel] Potential bug in RTAllocator.Clone Message-ID: Hi, this is my first post to the Modula-3 mailing list... While using RTAllocator.Clone in a project, I kept getting errors related to the type of the returned object. The debugger m3gdb returned a TYPECODE of 0. I think the cause is line 84 in RTAllocator.m3 which currently reads res := AllocTraced(dataSize, def.dataAlignment, thread^); which doesn't seem to set the header of the clone. Changing it to res := LOOPHOLE(GetTraced(def), ADDRESS); seems to fix the problems, but since I'm not that familiar with the object representation I thought I should ask here first. Thanks, Raja From rodney_bates at lcwb.coop Fri Aug 27 17:20:51 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 Aug 2010 10:20:51 -0500 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com> Message-ID: <4C77D7D3.6070602@lcwb.coop> Jay K wrote: > > better code quality > > Use the native C++ exception handling. Not more calling setjmp all over the place. > Inlining. Currnetly disabled in 4.5.1 because it breaks things. > LTO/LTCG -- which we could get today, on gcc platforms, if we are willing to import even more code. > (link time optimization, link time code gen). e.g. cross module inlining. > see also PGO -- profile guided optimization. > i.e. whatever the full C/C++ toolset is, you can use it. > > > > better debugging > > > Existing debuggers would work and work well. There is no way a debugger that has no Modula-3 awareness is going to provide a Modula-3-like view. The operators will have C spellings and C semantics, and these do differ. The syntax will be strictly C. The display of values will be C. TEXT won't work in any reasonable way at all. Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 type info would be lost, and output formats would lose. Things that use pointers at the machine level can never know whether the pointers point to a single value or an array, and if the latter, with what bounds. Display of whole arrays is pretty much out of the question. Probably the worst thing will be calls. They just don't work without the debugger having knowledge of a lot of stuff. There are extra hidden parameters, method calls, passing procedure-typed parameters with environments, calling the same, the three modes of Modula-3, etc. I consider calls in debugger commands very valuable. This could probably be improved a lot by switching to a better debug info format, probably the latest Dwarf variant. But that is a big job. > Notice today that NT386 has only line numbers. > That there are systems that don't support stabs -- e.g. HP-UX. > That other -g switches to cm3cg crash. > > >>> Basically all platforms would just work. >> I doubt that very much. > > It's only a slight exaggeration. > We'd still need our #ifdef'ing of the C code. Possibly guided by autoconf. > And there are still the threading/gc issues. > But for example, we should work on any processor for any operating system > for which we already work -- NT, Linux, NetBSD, FreeBSD, Solaris, OSF -- on any processors. > And AIX, Irix, VMS would work or be closer to working. > (IA64 might need an #ifdef) > > Anyway, I'll try to work on it. > >> And it would be an order of magnitude slower. > > It would be slower. I'm not sure by how much. > > - Jay > > > ---------------------------------------- >> Date: Thu, 26 Aug 2010 14:10:22 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? >> >> Quoting Jay K : >> >>>> No. I would see a C backend as a variant (option) too, but probably not >>>> use it on platforms were I can compile without it. >>> I would like to see a C backend at least replace the gcc backend. >>> We could maybe then slowly iterate on the integrated backend. Or LLVM. >>> It would provide more obvious correctness, better debugging, better >>> code quality. >> I don't really see that yet. >> >>> Imagine -- basically all platforms would get stack walkers. >>> By generating C++ for most platforms, or using C exception >>> handling in NT/VMS/Tru64. >>> Basically all platforms would just work. >> I doubt that very much. >> >>> Stock debuggers would work, gdb and others. >>> Basically no more porting. >>> Basically all optimizations could be enabled. >>> (Aside: I think the generated C would be sure to store >>> gc roots in volatile locals, but not otherwise use said volatiles.) >> As I said: it has been tried before. >> >>> And in more recent developments, it would enregister some records >>> passed by value. >>> It would, in a sense, shrink the code base (cheating sort of). >> And it would be an order of magnitude slower. >> >>> I'm not holding my breath on any of this. >>> But I'm going to start trying to do more and talk less about it. >> I will let you convince me ;-) >> I've got no problem with trying that. If it's really better, we will >> use it. If not, we may want to use it for special situations (e.g. porting). >> >> 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 Aug 27 17:31:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 17:31:06 +0200 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: References: Message-ID: <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> Quoting Jay K : > We could introduce a new quake feature.. > if defined("set_pipefail") > ? set_pipefail() > end > q_exec() > ? Could you elaborate what exactly fails? I don't think we should rely on bash3 or zsh or something else fancy. I'm also not sure that we can easily implement it in quake. The problem with pipelining logs through tee and losing result values is a standard one, but has no canonical solution AFAIK. More details would help, Olaf > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Fri, 27 Aug 2010 07:01:57 +0000 >> Subject: [M3devel] m3cc often succeeds when it should fail >> >> >> I finally looked into this. >> >> The reason is that the exit code of a pipeline is the last command. >> Seems kind of dumb and I don't like any of the options. >> I like having tee in there to save a log. >> >> There is a way to deal it with bash, zsh, and it takes a big >> function to do it in standard sh. >> >> Maybe q_exec or m3_exec? >> It looks like no. >> >> I suppose we could wrap up everything in a .sh file, detect bash 3 >> or newer, and use set -o pipefail? >> >> - 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 rodney_bates at lcwb.coop Fri Aug 27 17:30:15 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 Aug 2010 10:30:15 -0500 Subject: [M3devel] passing structs by value In-Reply-To: References: Message-ID: <4C77DA07.8030608@lcwb.coop> Jay, I am not sure what you are saying here, but it sounds like you might be considering the passing mode of records to be an implementor choice. Have I read this right? It isn't a choice for Modula-3. The language specifies the mode. Value for VALUE in the signature, reference for VAR, and for READONLY, it depends on the form of the actual. For function returns, the semantics are always by value. Of course, at the machine level, you can always pass a pointer between caller and callee, as long as the necessary copying is done somewhere This is the only reasonable way to implement READONLY, since whether a copy is to be made will differ at different call sites. Jay K wrote: > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > I really can't follow the complicated rules here: > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > As long as Modula-3 callers/recievers agree. And they do, but... > > > The gcc backend is given good type information at first, but historically throws much of it away. > As you start to repair that, it starts following the ABI. At least at the callee side. > I think the caller is still devoid of type information. > I'm assuming there is a fallback rule for the case of missing type information. > > So if you give just one side the type information, you get a mismatch, bad code. > > > Passing records in registers is nice, but.. > (reminder: I think historically we never did). > > > I thin we should probably just change the frontend to handle passing records by value itself. > Like it does for I386_NT/NT386. > > > For any record parameter, introduce a temporary in the caller and pass its address. > Or whatever the code is already prepared to do. > > > We should probably handle records returned by value similarly. > > > This decision can be revisited if/when there is a C backend. > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > I doubt anyone else is either. > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > The right fix is probably to maintain types in the expression stack. > Or at least throw in more casts on the pops. > > > I don't think pop_param presently recieves enough type information -- no type id. > > > - Jay > From hosking at cs.purdue.edu Fri Aug 27 18:11:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Aug 2010 12:11:50 -0400 Subject: [M3devel] Potential bug in RTAllocator.Clone, was: Fwd: Auto-discard notification In-Reply-To: <20100827171723.2a60uadm0wos04gw@mail.elegosoft.com> References: <20100827171723.2a60uadm0wos04gw@mail.elegosoft.com> Message-ID: I just committed a fix for this. On 27 Aug 2010, at 11:17, Olaf Wagner wrote: > Forwarded; sent before subscription was confirmed: > > The attached message has been automatically discarded. > Info The following are the headers for this message/rfc822 message. > Date: Fri, 27 Aug 2010 15:39:23 +0100 > Subject: Potential bug in RTAllocator.Clone > From: Raja Mukherji > To: m3devel at elegosoft.com > 2.1 unnamed [text/plain] 0.58 KB Download > Hi, this is my first post to the Modula-3 mailing list... > > While using RTAllocator.Clone in a project, I kept getting errors > related to the type of the returned object. The debugger m3gdb > returned a TYPECODE of 0. > I think the cause is line 84 in RTAllocator.m3 which currently reads > > res := AllocTraced(dataSize, def.dataAlignment, thread^); > > which doesn't seem to set the header of the clone. Changing it to > > res := LOOPHOLE(GetTraced(def), ADDRESS); > > seems to fix the problems, but since I'm not that familiar with the > object representation I thought I should ask here first. > > Thanks, > Raja > > ----- Forwarded message from m3devel-bounces at elegosoft.com ----- > Date: Fri, 27 Aug 2010 16:48:17 +0200 > From: m3devel-bounces at elegosoft.com > Reply-To: m3devel-bounces at elegosoft.com > Subject: Auto-discard notification > To: m3devel-owner at elegosoft.com > > The attached message has been automatically discarded. > > ----- End forwarded message ----- > > > -- > 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 Fri Aug 27 18:36:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 16:36:19 +0000 Subject: [M3devel] passing structs by value In-Reply-To: <4C77DA07.8030608@lcwb.coop> References: , <4C77DA07.8030608@lcwb.coop> Message-ID: Rodney, don't worry too much, I believe I understand the language semantics and won't deliberately change them. > Of course, at the machine levelI'm talking about the machine level. Passing a record by value can be in registers or a pointer to a copy. The gcc backend wasn't passing enough type information around, such that where the C ABI specified in registers, it'd a be a pointer to a copy. ?? Imho, it's kind of bad of the gcc code to even have accepted the trees we give it. I don't much mind the inefficiency, but I do mind missing type information in the debugger. And what really got me started here is an assertion failure in the SPARC64_SOLARIS backend. It goes to decide how to pass a record by value, which includes looking at what fields the record has, and it had none. Which it is sometimes ok with, but not in this case. If you just change parse.c to pass around the type information it has, well, the easy code only has information at the reciever, not the caller, leading to inconsistency, bad code, crash. The badness only occurs in a little bit of code in the system, and then, only on some platforms. I was lucky to be using such a platform! I have fixed it now so that the passer and recieve both have the information. The result should be, on some platforms, depending on the ABI, depending on the exact RECORD, some records will be passed in registers. Minor side benefit is correct interop with C, though I'd suggest just staying away from passing records by value with C. Unfortunately SPARC64_SOLARIS still hits the same assertion failure in gcc. :( I'm double checking to make sure I used current source. Accidentally doing a clean build of m3cc, so it'll be a while. ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 10:30:15 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] passing structs by value > > Jay, I am not sure what you are saying here, but it sounds like you might be considering the > passing mode of records to be an implementor choice. Have I read this right? > > It isn't a choice for Modula-3. The language specifies the mode. Value for VALUE in the > signature, reference for VAR, and for READONLY, it depends on the form of the actual. > > For function returns, the semantics are always by value. > > Of course, at the machine level, you can always pass a pointer between caller and callee, > as long as the necessary copying is done somewhere This is the only reasonable way to > implement READONLY, since whether a copy is to be made will differ at different call > sites. > > Jay K wrote: > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > I really can't follow the complicated rules here: > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > As you start to repair that, it starts following the ABI. At least at the callee side. > > I think the caller is still devoid of type information. > > I'm assuming there is a fallback rule for the case of missing type information. > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > Passing records in registers is nice, but.. > > (reminder: I think historically we never did). > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > Like it does for I386_NT/NT386. > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > Or whatever the code is already prepared to do. > > > > > > We should probably handle records returned by value similarly. > > > > > > This decision can be revisited if/when there is a C backend. > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > I doubt anyone else is either. > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > The right fix is probably to maintain types in the expression stack. > > Or at least throw in more casts on the pops. > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > - Jay > > From jay.krell at cornell.edu Fri Aug 27 18:51:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 16:51:57 +0000 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> References: , , <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> Message-ID: > Could you elaborate what exactly fails? I use make | tee -a. Any compilation failure..and still success. > I don't think we should rely on bash3 or zsh or something else fancy. Agreed. > I'm also not sure that we can easily implement it in quake. Here is where I disagree...though I'm not certain. You put in a substantial sh emulation already, in sysutils, already exposed in quake. m3-libs/sysutils/src/System.m3 ? PROCEDURE WaitForAll() : INTEGER = ??? VAR p: Process.T; ret: INTEGER := 0; ??? BEGIN ????? WHILE processes.size() > 0 DO ??????? p := NARROW(processes.remlo(), Process.T); ??????? ret := Process.Wait(p); ??????? CloseFiles(cjobid); ??????? INC(cjobid); ????? END; ????? RETURN ret; ??? END WaitForAll; A small change there would do what I want I think. ? PROCEDURE WaitForAll() : INTEGER = ??? VAR p: Process.T; ret := 0; overall := 0; ??? BEGIN ????? WHILE processes.size() > 0 DO ??????? p := NARROW(processes.remlo(), Process.T); ??????? ret := Process.Wait(p); ??????? IF ret <> 0 AND overall = 0 THEN ?????????? overall := ret; ??????? END; ??????? CloseFiles(cjobid); ??????? INC(cjobid); ????? END; ????? RETURN overall; ??? END WaitForAll; It could be made optional, though the way I showed would be global for that cm3 invocation, once set. It'd probably be safe to make it not optional. ? > The problem with pipelining logs through tee and losing result > values is a standard one, but has no canonical solution AFAIK. Agreed, based on my web searching last night. ?- Jay From jay.krell at cornell.edu Fri Aug 27 18:54:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 16:54:50 +0000 Subject: [M3devel] passing structs by value In-Reply-To: References: , , <4C77DA07.8030608@lcwb.coop>, Message-ID: > bad code, crash. Clarification, not a crash but an "orderly" error. This is somewhat by chance though. You could imagine perhaps a record that just contains a pointer, and a crash. - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: rodney_bates at lcwb.coop; m3devel at elegosoft.com > Date: Fri, 27 Aug 2010 16:36:19 +0000 > Subject: Re: [M3devel] passing structs by value > > > Rodney, don't worry too much, I believe I understand the language semantics and won't deliberately change them. > > > Of course, at the machine levelI'm talking about the machine level. > > Passing a record by value can be in registers or a pointer to a copy. > The gcc backend wasn't passing enough type information around, such that > where the C ABI specified in registers, it'd a be a pointer to a copy. > Imho, it's kind of bad of the gcc code to even have accepted the trees we give it. > I don't much mind the inefficiency, but I do mind missing type information in the debugger. > > And what really got me started here is an assertion failure in the SPARC64_SOLARIS backend. > It goes to decide how to pass a record by value, which includes looking at what fields the record > has, and it had none. Which it is sometimes ok with, but not in this case. > > If you just change parse.c to pass around the type information it has, well, the easy > code only has information at the reciever, not the caller, leading to inconsistency, bad code, crash. > The badness only occurs in a little bit of code in the system, and then, only on some platforms. > I was lucky to be using such a platform! > > I have fixed it now so that the passer and recieve both have the information. > > The result should be, on some platforms, depending on the ABI, depending on the exact RECORD, > some records will be passed in registers. > Minor side benefit is correct interop with C, though I'd suggest just staying away from > passing records by value with C. > > Unfortunately SPARC64_SOLARIS still hits the same assertion failure in gcc. :( > I'm double checking to make sure I used current source. Accidentally doing > a clean build of m3cc, so it'll be a while. > > > - Jay > > > ---------------------------------------- > > Date: Fri, 27 Aug 2010 10:30:15 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] passing structs by value > > > > Jay, I am not sure what you are saying here, but it sounds like you might be considering the > > passing mode of records to be an implementor choice. Have I read this right? > > > > It isn't a choice for Modula-3. The language specifies the mode. Value for VALUE in the > > signature, reference for VAR, and for READONLY, it depends on the form of the actual. > > > > For function returns, the semantics are always by value. > > > > Of course, at the machine level, you can always pass a pointer between caller and callee, > > as long as the necessary copying is done somewhere This is the only reasonable way to > > implement READONLY, since whether a copy is to be made will differ at different call > > sites. > > > > Jay K wrote: > > > On some platforms, such as AMD64_DARWIN, probably all AMD64 platforms, the gcc backend does not necessarily pass records by value in accordance with the C ABI. > > > > > > I really can't follow the complicated rules here: > > > > > > http://www.x86-64.org/documentation/abi-0.99.pdf > > > > > > > > > > > > but suffice it to say, records can be passed in registers, but it depends on the types of their fields. > > > > > > > > > > > > As much as we don't pass/return records by value between Modula-3 and C, that is ok. > > > As long as Modula-3 callers/recievers agree. And they do, but... > > > > > > > > > The gcc backend is given good type information at first, but historically throws much of it away. > > > As you start to repair that, it starts following the ABI. At least at the callee side. > > > I think the caller is still devoid of type information. > > > I'm assuming there is a fallback rule for the case of missing type information. > > > > > > So if you give just one side the type information, you get a mismatch, bad code. > > > > > > > > > Passing records in registers is nice, but.. > > > (reminder: I think historically we never did). > > > > > > > > > I thin we should probably just change the frontend to handle passing records by value itself. > > > Like it does for I386_NT/NT386. > > > > > > > > > For any record parameter, introduce a temporary in the caller and pass its address. > > > Or whatever the code is already prepared to do. > > > > > > > > > We should probably handle records returned by value similarly. > > > > > > > > > This decision can be revisited if/when there is a C backend. > > > Basically, our current system is somewhat broken, I'm a bit lazy and not very inclined to fix it. > > > I doubt anyone else is either. > > > I'd like to both improve the debugging situation with stock gdb, as well as fix SPARC64_SOLARIS to work. > > > Further long term deficiencies this uncovers, I'm very inclined to dig further into. > > > > > > > > > The right fix is probably to maintain types in the expression stack. > > > Or at least throw in more casts on the pops. > > > > > > > > > I don't think pop_param presently recieves enough type information -- no type id. > > > > > > > > > - Jay > > > > From wagner at elegosoft.com Fri Aug 27 19:23:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 19:23:31 +0200 Subject: [M3devel] m3cc often succeeds when it should fail In-Reply-To: References: , , <20100827173106.ceafno1okgo488g4@mail.elegosoft.com> Message-ID: <20100827192331.fwoon2w4sgwgks8w@mail.elegosoft.com> Quoting Jay K : >> Could you elaborate what exactly fails? > > I use make | tee -a. > Any compilation failure..and still success. You loose stderr there. One standard solution would be to write stderr to a file and check that for content afterwards: make 2>make.err | tee -a log if[ -s make.err ]; then # error >> I'm also not sure that we can easily implement it in quake. > > Here is where I disagree...though I'm not certain. > You put in a substantial sh emulation already, in sysutils, already > exposed in quake. > > m3-libs/sysutils/src/System.m3 > > ? PROCEDURE WaitForAll() : INTEGER = > ??? VAR p: Process.T; ret: INTEGER := 0; > ??? BEGIN > ????? WHILE processes.size() > 0 DO > ??????? p := NARROW(processes.remlo(), Process.T); > ??????? ret := Process.Wait(p); > ??????? CloseFiles(cjobid); > ??????? INC(cjobid); > ????? END; > ????? RETURN ret; > ??? END WaitForAll; > > A small change there would do what I want I think. > > ? PROCEDURE WaitForAll() : INTEGER = > > ??? VAR p: Process.T; ret := 0; overall := 0; > ??? BEGIN > ????? WHILE processes.size() > 0 DO > ??????? p := NARROW(processes.remlo(), Process.T); > ??????? ret := Process.Wait(p); > ??????? IF ret <> 0 AND overall = 0 THEN > ?????????? overall := ret; > ??????? END; > ??????? CloseFiles(cjobid); > ??????? INC(cjobid); > ????? END; > ????? RETURN overall; > ??? END WaitForAll; > > It could be made optional, though the way I showed would be global for > that cm3 invocation, once set. > > It'd probably be safe to make it not optional. ? If this is what is used in your situation I'm in favour of making it the default to heed all return codes. I only said that I'm not sure it can be done easily, as there are different ways how processes are created in quake, often via system shells (might even be a cmd.exe) or anything specified in QUAKE_SHELL. As long as we're using one of the new functions I wrote some years ago it should be no problem. If it's working for you, just change it and document it in the quake manual (cm3/doc/help/cm3/quake.html). 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 hendrik at topoi.pooq.com Fri Aug 27 19:35:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 13:35:02 -0400 Subject: [M3devel] conversion to another version control system Message-ID: <20100827173502.GA8777@topoi.pooq.com> I was tinkering with a copy of the Modula 3 cvs repository I had made a few months ago using cvsup, seeing of cvs2git would make me a proper git-fast-import file. It complained that what I provided wasn't a valid CVS repository: ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS repository, nor a path within a CVS repository. A CVS repository contains a CVSROOT directory within its root directory. Now I looked around, and couldn't find a CVSROOT directory anywhere except in /usr/lib/cvs, which is probably irrelevant. Is this a problem with cvs2git, a problem with the repository, or a problem with cvsup, or a problem with the way I used cvsup to copy the repository? Or would any regular cvs user know just exactly what to do? By the way, the recent problems mentioned on this list about cvsup have made me afraid to use it again. Are those problems restricted to a few platforms, or widespread? -- hendrik From hendrik at topoi.pooq.com Fri Aug 27 20:09:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 14:09:02 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827173502.GA8777@topoi.pooq.com> References: <20100827173502.GA8777@topoi.pooq.com> Message-ID: <20100827180902.GA8903@topoi.pooq.com> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: > I was tinkering with a copy of the Modula 3 cvs repository I had made > a few months ago using cvsup, seeing of cvs2git would make me a proper > git-fast-import file. It complained that what I provided wasn't a valid > CVS repository: > > ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS > repository, nor a path within a CVS repository. A CVS repository > contains a CVSROOT directory within its root directory. > > Now I looked around, and couldn't find a CVSROOT directory anywhere > except in /usr/lib/cvs, which is probably irrelevant. > > Is this a problem with cvs2git, a problem with the repository, or a > problem with cvsup, or a problem with the way I used cvsup to copy the > repository? Or would any regular cvs user know just exactly what to do? Should I perhaps just create an empty CVSROOT directory somewhere? In case it indicates what I did wrong, an ancient log indicates that when I created the copy of the repository in the first place, I used the commands cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 -- hendrik From hosking at cs.purdue.edu Fri Aug 27 20:02:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 27 Aug 2010 14:02:50 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827180902.GA8903@topoi.pooq.com> References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> Message-ID: cvs checkout gives you a checked out working directory not a repository. You'd need to *copy* the repository hierarchy verbatim. On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >> I was tinkering with a copy of the Modula 3 cvs repository I had made >> a few months ago using cvsup, seeing of cvs2git would make me a proper >> git-fast-import file. It complained that what I provided wasn't a valid >> CVS repository: >> >> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >> repository, nor a path within a CVS repository. A CVS repository >> contains a CVSROOT directory within its root directory. >> >> Now I looked around, and couldn't find a CVSROOT directory anywhere >> except in /usr/lib/cvs, which is probably irrelevant. >> >> Is this a problem with cvs2git, a problem with the repository, or a >> problem with cvsup, or a problem with the way I used cvsup to copy the >> repository? Or would any regular cvs user know just exactly what to do? > > Should I perhaps just create an empty CVSROOT directory somewhere? > > In case it indicates what I did wrong, an ancient log indicates that > when I created the copy of the repository in the first place, I used the > commands > > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 > > -- hendrik From jay.krell at cornell.edu Fri Aug 27 20:28:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 18:28:47 +0000 Subject: [M3devel] importing types not described to backend Message-ID: This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 INTERFACE Color; TYPE T = RECORD a,b,c:REAL; END; END Color. MODULE Main; IMPORT Color; TYPE ColorT = RECORD a,b,c: REAL; END; <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = BEGIN END F1; <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = BEGIN END F2; BEGIN ? F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); ? F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); END Main. On SPARC64_SOLARIS there is an assertion failure in the backend: /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1? -mno-app-regs? -quiet -fno-reorder-blocks -funwind-tables -fPIC?? -m64? -gstabs+ Main.mc -o Main.ms ../Main.m3: In function 'Main__F1': ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 I fixed it so F1 is ok. But still F2 isn't. The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. The problem as I understand is we don't tell the backend about imported types. ?There is nothing in the IR about them, judging from -y and a quick look at parse.c. I intend to fix this if I don't here any objections. I'm hoping it isn't too much work. I believe it will mostly/all be in m3front. My opinion of our gcc backend drops.. Perhaps the time is better used on a C front end. Though in this case, I think the work is shared, the same stuff would be missing there too. Thanks, ?- Jay From jay.krell at cornell.edu Fri Aug 27 20:35:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 18:35:00 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: Message-ID: Very wierd: MODULE Main; IMPORT Color; TYPE ColorT = RECORD a,b,c: REAL; END; <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = BEGIN END F1; BEGIN ? F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); END Main. This fails. If you remove the IMPORT, it worked. The declare_record of ColorT comes and goes with that change. So I guess the error really is in F1. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 27 Aug 2010 18:28:47 +0000 > Subject: [M3devel] importing types not described to backend > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > INTERFACE Color; > TYPE T = RECORD a,b,c:REAL; END; > END Color. > > > MODULE Main; > IMPORT Color; > TYPE ColorT = RECORD a,b,c: REAL; END; > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > BEGIN > END F1; > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > BEGIN > END F2; > > > BEGIN > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > END Main. > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > ../Main.m3: In function 'Main__F1': > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > I fixed it so F1 is ok. > But still F2 isn't. > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > The problem as I understand is we don't tell the backend about imported types. > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > I intend to fix this if I don't here any objections. > I'm hoping it isn't too much work. > I believe it will mostly/all be in m3front. > > > My opinion of our gcc backend drops.. > > > Perhaps the time is better used on a C front end. > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > Thanks, > - Jay > From wagner at elegosoft.com Fri Aug 27 20:55:55 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 20:55:55 +0200 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> Message-ID: <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> Quoting Tony Hosking : > cvs checkout gives you a checked out working directory not a repository. > You'd need to *copy* the repository hierarchy verbatim. The CM3 repository is on birch.elegosoft.com:/usr/cvs It contains CVSROOT and cm3 as CVS modules. CVSROOT contains metainformation about the versions. You'll probably need it for git conversion. You can get the whole repository via cvsup, rsync or scp. The last two require an ssh account on birch. Olaf PS: I did mention that Peter Eiserloh is also working on a git conversion of our history? > On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > >> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >>> I was tinkering with a copy of the Modula 3 cvs repository I had made >>> a few months ago using cvsup, seeing of cvs2git would make me a proper >>> git-fast-import file. It complained that what I provided wasn't a valid >>> CVS repository: >>> >>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >>> repository, nor a path within a CVS repository. A CVS repository >>> contains a CVSROOT directory within its root directory. >>> >>> Now I looked around, and couldn't find a CVSROOT directory anywhere >>> except in /usr/lib/cvs, which is probably irrelevant. >>> >>> Is this a problem with cvs2git, a problem with the repository, or a >>> problem with cvsup, or a problem with the way I used cvsup to copy the >>> repository? Or would any regular cvs user know just exactly what to do? >> >> Should I perhaps just create an empty CVSROOT directory somewhere? >> >> In case it indicates what I did wrong, an ancient log indicates that >> when I created the copy of the repository in the first place, I used the >> commands >> >> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login >> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 >> >> -- hendrik > > -- 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 hendrik at topoi.pooq.com Fri Aug 27 21:31:56 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 15:31:56 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> Message-ID: <20100827193155.GB8903@topoi.pooq.com> On Fri, Aug 27, 2010 at 02:02:50PM -0400, Tony Hosking wrote: > cvs checkout gives you a checked out working directory not a repository. > You'd need to *copy* the repository hierarchy verbatim. > > On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > > > On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: > >> I was tinkering with a copy of the Modula 3 cvs repository I had made > >> a few months ago using cvsup, seeing of cvs2git would make me a proper > >> git-fast-import file. It complained that what I provided wasn't a valid > >> CVS repository: > >> > >> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS > >> repository, nor a path within a CVS repository. A CVS repository > >> contains a CVSROOT directory within its root directory. > >> > >> Now I looked around, and couldn't find a CVSROOT directory anywhere > >> except in /usr/lib/cvs, which is probably irrelevant. > >> > >> Is this a problem with cvs2git, a problem with the repository, or a > >> problem with cvsup, or a problem with the way I used cvsup to copy the > >> repository? Or would any regular cvs user know just exactly what to do? > > > > Should I perhaps just create an empty CVSROOT directory somewhere? > > > > In case it indicates what I did wrong, an ancient log indicates that > > when I created the copy of the repository in the first place, I used the > > commands > > > > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > > cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 OK. it looks as if this wasn't the command I used. I do remember using cvsup at some point. I do have a lot of ,v files. so it's not a checkout I'm looking at. I seem to have looked at the wrong set of logs. That's was from the set that records how I compiled cvsup. I found the cvsupfile.cm3 file I used. It looks as if I didn't fully uncomment stuff. Will rerun. I hope it won't overload the server. -- hendrik From wagner at elegosoft.com Fri Aug 27 21:29:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 27 Aug 2010 21:29:06 +0200 Subject: [M3devel] cm3cg running amok Message-ID: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> I was just able to kill this process before my system ran out of swap space: % ps -wwwlp 95345 UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? 0:22.91 /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ RTHeapDebug.mc -o RTHeapDebug.ms It had already acquired more than 16 GB. Any ideas? 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 hendrik at topoi.pooq.com Fri Aug 27 21:38:37 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 27 Aug 2010 15:38:37 -0400 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com> <20100827180902.GA8903@topoi.pooq.com> <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> Message-ID: <20100827193836.GC8903@topoi.pooq.com> On Fri, Aug 27, 2010 at 08:55:55PM +0200, Olaf Wagner wrote: > Quoting Tony Hosking : > >> cvs checkout gives you a checked out working directory not a repository. >> You'd need to *copy* the repository hierarchy verbatim. > > The CM3 repository is on birch.elegosoft.com:/usr/cvs > It contains CVSROOT and cm3 as CVS modules. > CVSROOT contains metainformation about the versions. You'll > probably need it for git conversion. > > You can get the whole repository via cvsup, rsync or scp. The last > two require an ssh account on birch. > > Olaf > > PS: I did mention that Peter Eiserloh is also working on a git > conversion of our history? No. From discussions half a year ago or longer, I thought that monotone was the preferred solution. Git is easier, I suppose, because no one has to write anything to feed git-fast-import into monotone. And a git-fast-import file would probably be the first step to get it into monotone anyway, since the direct cvs import I tried into monotone failed one of monotone's internal sanity checks. Perhaps this means I don't have to do the cvs2mtn stuff any more. Not for Modula 3, anyway. Though git2mtn might still be useful for others. -- hendrik > >> On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: >> >>> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >>>> I was tinkering with a copy of the Modula 3 cvs repository I had made >>>> a few months ago using cvsup, seeing of cvs2git would make me a proper >>>> git-fast-import file. It complained that what I provided wasn't a valid >>>> CVS repository: >>>> >>>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >>>> repository, nor a path within a CVS repository. A CVS repository >>>> contains a CVSROOT directory within its root directory. >>>> >>>> Now I looked around, and couldn't find a CVSROOT directory anywhere >>>> except in /usr/lib/cvs, which is probably irrelevant. >>>> >>>> Is this a problem with cvs2git, a problem with the repository, or a >>>> problem with cvsup, or a problem with the way I used cvsup to copy the >>>> repository? Or would any regular cvs user know just exactly what to do? >>> >>> Should I perhaps just create an empty CVSROOT directory somewhere? >>> >>> In case it indicates what I did wrong, an ancient log indicates that >>> when I created the copy of the repository in the first place, I used the >>> commands >>> >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 >>> >>> -- hendrik >> >> > > > > -- > 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 Sat Aug 28 00:05:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 22:05:38 +0000 Subject: [M3devel] cm3cg running amok In-Reply-To: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> Message-ID: Hm. I've only been testing AMD64_DARWIN lately. ? > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg This path -- to m3-sys/m3cc: When I made the pop_struct change, I changed my cm3cfg.common to only use $PATH, and not root around in the CVS tree. To use old cm3cg with old cm3, new cm3cg with new cm3. Could that be the problem here? ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 21:29:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] cm3cg running amok > > I was just able to kill this process before my system ran out of swap > space: > > % ps -wwwlp 95345 > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? > 0:22.91 > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ RTHeapDebug.mc -o > RTHeapDebug.ms > > It had already acquired more than 16 GB. > > Any ideas? > > 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 Sat Aug 28 00:15:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 27 Aug 2010 22:15:42 +0000 Subject: [M3devel] conversion to another version control system In-Reply-To: <20100827193836.GC8903@topoi.pooq.com> References: <20100827173502.GA8777@topoi.pooq.com>, <20100827180902.GA8903@topoi.pooq.com>, , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, <20100827193836.GC8903@topoi.pooq.com> Message-ID: > I thought that monotone was the preferred solutionMy "ressearch" (not really worth calling it that), suggests the following are good options, roughly in this order: ?perforce ("p4") ?mercurial ("hg") ?git ?monotone ("mtn")? ?subversion ("svn") ?subversion doesn't do branching right, but for us it probably is good enough. ?Perforce is my favorite by far. I know very well how to use it and it works very well. ?I just could never find a hoster for it. ?svn's familiar centralized model might put it up at #2 after p4. ?hg is said to be easier to use and understand than git. ?hg and git seems to be the running favorites of the distributed systems. ?mtn was rejected by Linus because it was too slow. It is better now and ?? probably ok. svn doesn't do branching right and isn't distibuted, but as I said, maybe #2. It also pays to use the heavily used systems. They become the most reliable. (Modula-3 not necessarily a counterexcample...) ?- Jay ---------------------------------------- > Date: Fri, 27 Aug 2010 15:38:37 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] conversion to another version control system > > On Fri, Aug 27, 2010 at 08:55:55PM +0200, Olaf Wagner wrote: > > Quoting Tony Hosking : > > > >> cvs checkout gives you a checked out working directory not a repository. > >> You'd need to *copy* the repository hierarchy verbatim. > > > > The CM3 repository is on birch.elegosoft.com:/usr/cvs > > It contains CVSROOT and cm3 as CVS modules. > > CVSROOT contains metainformation about the versions. You'll > > probably need it for git conversion. > > > > You can get the whole repository via cvsup, rsync or scp. The last > > two require an ssh account on birch. > > > > Olaf > > > > PS: I did mention that Peter Eiserloh is also working on a git > > conversion of our history? > > No. From discussions half a year ago or longer, I thought that monotone > was the preferred solution. Git is easier, I suppose, because no one > has to write anything to feed git-fast-import into monotone. And > a git-fast-import file would probably be the first step to get it into > monotone anyway, since the direct cvs import I tried into monotone > failed one of monotone's internal sanity checks. > > Perhaps this means I don't have to do the cvs2mtn stuff any more. Not > for Modula 3, anyway. Though git2mtn might still be useful for others. > > -- hendrik > > > > >> On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: > >> > >>> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: > >>>> I was tinkering with a copy of the Modula 3 cvs repository I had made > >>>> a few months ago using cvsup, seeing of cvs2git would make me a proper > >>>> git-fast-import file. It complained that what I provided wasn't a valid > >>>> CVS repository: > >>>> > >>>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS > >>>> repository, nor a path within a CVS repository. A CVS repository > >>>> contains a CVSROOT directory within its root directory. > >>>> > >>>> Now I looked around, and couldn't find a CVSROOT directory anywhere > >>>> except in /usr/lib/cvs, which is probably irrelevant. > >>>> > >>>> Is this a problem with cvs2git, a problem with the repository, or a > >>>> problem with cvsup, or a problem with the way I used cvsup to copy the > >>>> repository? Or would any regular cvs user know just exactly what to do? > >>> > >>> Should I perhaps just create an empty CVSROOT directory somewhere? > >>> > >>> In case it indicates what I did wrong, an ancient log indicates that > >>> when I created the copy of the repository in the first place, I used the > >>> commands > >>> > >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login > >>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 > >>> > >>> -- hendrik > >> > >> > > > > > > > > -- > > 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 Sat Aug 28 00:31:51 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 28 Aug 2010 00:31:51 +0200 Subject: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on several platforms In-Reply-To: References: <20100827081459.s88b14400448owk8@mail.elegosoft.com>, , <20100827130123.0p6vdno428ssok4w@mail.elegosoft.com>, <20100827132557.11zmj6wms8gg8kwk@mail.elego.de> Message-ID: <20100828003151.nqk0l9d7w0owcswg@mail.elegosoft.com> I compiled the latest code on my FreeBSD 8 system and found that it sometimes hangs when shutting down the connection. Here is a backtrace: (m3gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x00000008033087dc in poll () from /lib/libc.so.7 (m3gdb) bt #0 0x00000008033087dc in poll () from /lib/libc.so.7 #1 0x000000080315a85e in poll () from /lib/libthr.so.3 #2 0x0000000801d7e0bd in ThreadInternal__Poll (fd=8, read=1, m3timeout=1) at ../src/thread/Common/ThreadInternal.c:31 #3 0x0000000801d8161a in XIOWait (Cannot resolve type with uid DMxDjQ ) at ../src/thread/PTHREAD/ThreadPThread.m3:627 #4 0x0000000801d814c2 in IOAlertWait (fd=8, read=TRUE, timeoutInterval=-1) at ../src/thread/PTHREAD/ThreadPThread.m3:603 #5 0x00000008012f1528 in ReadPipe (fd=8) at ../src/SigHandler.m3:221 #6 0x00000008012f0d80 in DoDispatch () at ../src/SigHandler.m3:138 #7 0x00000008012f0b58 in DispatcherRun (closure=16_00000008005cc378) at ../src/SigHandler.m3:112 #8 0x0000000801d806a5 in RunThread (Cannot resolve type with uid DMxDjQ ) at ../src/thread/PTHREAD/ThreadPThread.m3:450 #9 0x0000000801d80359 in ThreadBase (param=16_0000000803c76f80) at ../src/thread/PTHREAD/ThreadPThread.m3:422 #10 0x0000000803158511 in pthread_getprio () from /lib/libthr.so.3 #11 0x0000000000000000 in ?? () There seem to be no other threads at this point. Olaf Quoting Jay K : > > Michael, thank you. Please add it to the bug. > > ?- Jay > > > ---------------------------------------- >> Date: Fri, 27 Aug 2010 13:25:57 +0200 >> From: michael.anderson at elego.de >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] Fwd: Re: [CM3] #1148: CVSup stalls on >> several platforms >> >> Quoting Olaf Wagner : >> >> > Quoting Jay K : >> > >> >> Can you add more information to the bug as to how to reproduce >> the problem? >> >> Exact files? cvsup.conf or whatnot? >> >> Exact command lines? >> >> >> >> >> I'm able to reliably reproduce the problem with this command: >> >> /usr/local/cm3/bin/cvsup -g -L 2 cvsupfile.cm3 >> >> where the cvsupfile contains: >> >> *default host=birch.elego.de >> *default base=/home/mand/tmp/cvsup >> *default prefix=/home/mand/tmp/cvs >> *default release=cvs >> *default delete use-rel-suffix >> *default preserve >> cm3 >> >> Sometimes the first sync will finish, but a subsequent sync will hang. >> >> >> I don't use cvsup, don't know how to set it up. >> >> Before when I debugging this it wasn't too difficult though. >> >> >> >> Perhaps we can put something in m3-sys/m3tests even? >> > >> > I will try to set up an automated cvsup test at the weekend. >> > In our DCVS distribution we had quite a few replication tests; >> > perhaps I can burrow something from that. >> > >> > It won't go into m3tests though, but rather be a subdir to cvsup. >> > m3-sys/m3tests is for language/compiler tests. >> > >> > 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 >> >> >> >> -- >> Michael Anderson >> IT Services & Support >> >> elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 >> Building 12.3 (BIG) room 227 >> 13355 Berlin, Germany >> >> phone +49 30 23 45 86 96 michael.anderson at elegosoft.com >> fax +49 30 23 45 86 95 http://www.elegosoft.com >> >> Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin >> Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 >> >> > -- 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 Sat Aug 28 00:38:39 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 28 Aug 2010 00:38:39 +0200 Subject: [M3devel] cm3cg running amok In-Reply-To: References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> Message-ID: <20100828003839.izqrqjd14w44owk4@mail.elegosoft.com> Quoting Jay K : > Hm. I've only been testing AMD64_DARWIN lately. > ? > > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg > > This path -- to m3-sys/m3cc: > When I made the pop_struct change, I changed my cm3cfg.common to > only use $PATH, and not root around > in the CVS tree. To use old cm3cg with old cm3, new cm3cg with new cm3. > Could that be the problem here? I don't know. It was part of the Hudson regression, so the upgrade should have been done properly. Let's just see if it happens again. I need to get some sleep now, 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 rodney_bates at lcwb.coop Sat Aug 28 03:43:36 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 27 Aug 2010 20:43:36 -0500 Subject: [M3devel] cm3cg running amok In-Reply-To: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> Message-ID: <4C7869C8.7050600@lcwb.coop> The ticked #1147 I reported a couple of weeks ago would probably show this symptom. That was AMD64_LINUX. Hmm, I think I never got back to supplying the attachment .ms file to reproduce. I'll try to do that tomorrow. I need sleep now too. Olaf Wagner wrote: > I was just able to kill this process before my system ran out of swap > space: > > % ps -wwwlp 95345 > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? 0:22.91 > /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg > -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 > -gstabs+ RTHeapDebug.mc -o RTHeapDebug.ms > > It had already acquired more than 16 GB. > > Any ideas? > > Olaf From darko at darko.org Sat Aug 28 08:31:13 2010 From: darko at darko.org (Darko) Date: Fri, 27 Aug 2010 23:31:13 -0700 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, <20100827180902.GA8903@topoi.pooq.com>, , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, <20100827193836.GC8903@topoi.pooq.com> Message-ID: <45AF1046-B964-4509-878D-406269EEA3EC@darko.org> FWIW, I like and use mercurial which has good support generally. Perforce is commercial and proprietary. On 27/08/2010, at 3:15 PM, Jay K wrote: > >> I thought that monotone was the preferred solutionMy "ressearch" (not really worth calling it that), suggests the following are good > options, roughly in this order: > > perforce ("p4") > mercurial ("hg") > git > monotone ("mtn") > subversion ("svn") > > subversion doesn't do branching right, but for us it probably is good enough. > Perforce is my favorite by far. I know very well how to use it and it works very well. > I just could never find a hoster for it. > > svn's familiar centralized model might put it up at #2 after p4. > hg is said to be easier to use and understand than git. > hg and git seems to be the running favorites of the distributed systems. > mtn was rejected by Linus because it was too slow. It is better now and > probably ok. > svn doesn't do branching right and isn't distibuted, but as I said, maybe #2. > > > It also pays to use the heavily used systems. They become the most > reliable. (Modula-3 not necessarily a counterexcample...) > > > - Jay > > ---------------------------------------- >> Date: Fri, 27 Aug 2010 15:38:37 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] conversion to another version control system >> >> On Fri, Aug 27, 2010 at 08:55:55PM +0200, Olaf Wagner wrote: >>> Quoting Tony Hosking : >>> >>>> cvs checkout gives you a checked out working directory not a repository. >>>> You'd need to *copy* the repository hierarchy verbatim. >>> >>> The CM3 repository is on birch.elegosoft.com:/usr/cvs >>> It contains CVSROOT and cm3 as CVS modules. >>> CVSROOT contains metainformation about the versions. You'll >>> probably need it for git conversion. >>> >>> You can get the whole repository via cvsup, rsync or scp. The last >>> two require an ssh account on birch. >>> >>> Olaf >>> >>> PS: I did mention that Peter Eiserloh is also working on a git >>> conversion of our history? >> >> No. From discussions half a year ago or longer, I thought that monotone >> was the preferred solution. Git is easier, I suppose, because no one >> has to write anything to feed git-fast-import into monotone. And >> a git-fast-import file would probably be the first step to get it into >> monotone anyway, since the direct cvs import I tried into monotone >> failed one of monotone's internal sanity checks. >> >> Perhaps this means I don't have to do the cvs2mtn stuff any more. Not >> for Modula 3, anyway. Though git2mtn might still be useful for others. >> >> -- hendrik >> >>> >>>> On 27 Aug 2010, at 14:09, hendrik at topoi.pooq.com wrote: >>>> >>>>> On Fri, Aug 27, 2010 at 01:35:02PM -0400, hendrik at topoi.pooq.com wrote: >>>>>> I was tinkering with a copy of the Modula 3 cvs repository I had made >>>>>> a few months ago using cvsup, seeing of cvs2git would make me a proper >>>>>> git-fast-import file. It complained that what I provided wasn't a valid >>>>>> CVS repository: >>>>>> >>>>>> ERROR: the path '/farhome/hendrik/newcm3/trywholecvs/cvs' is not a CVS >>>>>> repository, nor a path within a CVS repository. A CVS repository >>>>>> contains a CVSROOT directory within its root directory. >>>>>> >>>>>> Now I looked around, and couldn't find a CVSROOT directory anywhere >>>>>> except in /usr/lib/cvs, which is probably irrelevant. >>>>>> >>>>>> Is this a problem with cvs2git, a problem with the repository, or a >>>>>> problem with cvsup, or a problem with the way I used cvsup to copy the >>>>>> repository? Or would any regular cvs user know just exactly what to do? >>>>> >>>>> Should I perhaps just create an empty CVSROOT directory somewhere? >>>>> >>>>> In case it indicates what I did wrong, an ancient log indicates that >>>>> when I created the copy of the repository in the first place, I used the >>>>> commands >>>>> >>>>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs login >>>>> cvs -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 >>>>> >>>>> -- hendrik >>>> >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >>> > From dragisha at m3w.org Sat Aug 28 10:12:52 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 28 Aug 2010 10:12:52 +0200 Subject: [M3devel] conversion to another version control system In-Reply-To: <45AF1046-B964-4509-878D-406269EEA3EC@darko.org> References: <20100827173502.GA8777@topoi.pooq.com> , <20100827180902.GA8903@topoi.pooq.com> , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com> , <20100827193836.GC8903@topoi.pooq.com> <45AF1046-B964-4509-878D-406269EEA3EC@darko.org> Message-ID: <1282983172.2770.71.camel@boromir.m3w.org> I use mercurial from time to time and from what I found it's excellent little package. Does its work well, is distributed, supported by trac... What else we need? :) On Fri, 2010-08-27 at 23:31 -0700, Darko wrote: > FWIW, I like and use mercurial which has good support generally. > Perforce is commercial and proprietary. -- Dragi?a Duri? From jay.krell at cornell.edu Sat Aug 28 10:40:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Aug 2010 08:40:29 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <4C77D7D3.6070602@lcwb.coop> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , <4C77D7D3.6070602@lcwb.coop> Message-ID: > > There is no way a debugger that has no Modula-3 awareness is going to provide > a Modula-3-like view. The operators will have C spellings and C semantics, How many operators do people use in a debugger? I use very few. Partly because for a long time I used a debugger with a great gui and an awful expression evaluator. Still, I use basically only "+" "->" "*" (dereference) and "=" for assignment. ?Sometimes multiplication and subtraction. I agree it would be nice if all the C debuggers would be lenient about "->" vs. ".". ? That would unify Modula-3, Java, C#, C, C++. ?? Except where C++ has an operator-> overload. But operator overload ?? is an area where.. tangent... C++ is a great language..my compiler implements ?? it well..but my debugger, my editor, plain text search.. can't cope with it. ?? Modula-3, C#, Java run afoul of plain text search too -- anything with prevalent "scoped names". ?? In C you get Window_Init, File_Open, etc. never just Init or Open. ?? How do you search for calls to operator+ in C++? For a certain type? ?? In C, except for the builtin types, they'd be unique function names. ? Anyway, tangent over. + is the same in the various languages. I think "=", ":=", "==" are the main problem. You might try a compare and accidentally to an assignment. > The syntax will be strictly C. Almost the same. ?> The display of values will be C. Almost the same. Also if you have a particularly good C compiler/debugger, we could do ? #define AND &&? ? #define OR ||? getting you back those two operators, which I rarely use in a debugger. ?> TEXT won't work in any reasonable way at all. Sure it might. In Visual Studio you can write little addins to help the debugger display stuff. I believe there is a small builtin "language" or I believe you can write actual code. In Windbg you can write little plugins. You could provide like !m3.text. I don't know if you can tell the debugger ahead of time how to custom display types. I don't know if gdb has a story here. Still, one might imagine a *small* patch to gdb. ?> Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 ?> type info would be lost, and output formats would lose. Um, you think maybe this stuff was done the wrong way in the first place? ?That the names shouldn't be mangled in the first place? ? I strongly suspect so. Other systems don't depend on this. ?? (Yes, I know about C++ name mangling, and even though it does something similar, ?? that's a trick for the linker and now how debug information works. It for ?? in the absence of debug information, among other reasons.) There is "naturally" type information you get just by building up decent gcc trees. Ditto for intermediate C code. For a while you know, every record is a void* or just has a size, and all the type information is buried in the names. This is questionable. I'm sure it has some advantages. You can describe things maybe not easily described in C. ? e.g. Subranges? And then our code in m3gdb is probably very portable, in that, I think, we just ferry along some strings, from our code to our code, and we can decipher them the same in all systems. I think, I'm not sure, there is like no dependence on the vagaries of coff, dwarf, etc., and what they can or cannot represent. However there is a dependency on stabs being available. It is not for example available on HP-UX. Furthermore the lack of correct type information, apart from stabs, causes problems. For some targets the backend wants accurate type information to pass records by value. I again/still think we should probably not rely on the backend for this anyway. We should probably make a copy and pass a pointer to it, kind of like m3x86 does. ?> Things that use pointers at the machine level can never know whether the pointers ?> point to a single value or an array, and if the latter, with what bounds. C programmers can cope with that. Can't we? And..I admit.. I don't know what our machine level mapping looks like. Do we pass a pointer and a size as two parameters? Or a small record with pointer/size by value? The debugger need not be a full blown Modula-3 interpreter. > Probably the worst thing will be calls. They just don't work without the debugger > having knowledge of a lot of stuff. There are extra hidden parameters, method > calls, passing procedure-typed parameters with environments, calling the same, > the three modes of Modula-3, etc. I consider calls in debugger commands very > valuable. I use calls very rarely. I'm not super keen on running some of my code when otherwise my code is all frozen and some of it is misbehaving. I know this is partly me. Even so, generally you only call certain functions that put there for use from a debugger, right? Like gcc's debug_node or such? And they tend to not be fancy? And the extra parameters..debugger would complain about missing them, programmer would figure it out? I'm not saying there aren't drawbacks here. But there are also major advantages. There are major costs and drawbacks to our current approach. ? We have a ton of extra code. ? Which I don't think we are well equipped for. ? Maybe Tony is. Maybe someone else is. I'm not. ? Partly, I'll admit, anything I write, I am much more able to maintain. Or, another lazy angle, anything smaller is easier to maintain. In gcc we have a large code base. It takes me a long time to get just slightly up to speed on it. We have several nagging problems with it. Maybe I just need to look at the C front end more. Or read tree.h. I don't know. ?4.5.1 doesn't work with SPARC32_SOLARIS/SOLgnu/SOLsun. ?4.3.5 maybe not either. ?A few optimizations I have turned off for 4.5.1 because they cause problems. Including inlining. ?Maybe I just need to debug more. ?Apple and OpenBSD each maintain their own forks. So that, *sort of but not really*, triples things. ?? (now, they are all highly related, so it doesn't) So far we don't have the OpenBSD fork. ? But for example 4.5.1 doesn't have the OpenBSD/powerpc stuff quite. And there is a small OpenBSD/mips64 ?? problem I worked around. Minor, I guess. We could just drop these platforms, or OpenBSD entirely. ? Not a huge deal. But it is yet more stuff that C as an intermediate platform solves. ? Exception handling stinks on all platforms but SOLsun/SOLgnu. ?? The ALPHA_OSF code no longer works. I tried. ? Generating C/C++ would significantly improve exception handling nearly across the board. ?? It is possible otherwise, but much more difficult. So, again, C as intermediate code isn't perfect or without drawbacks, but it promises: ? greatly increased portability ? more efficient exception handling ? better codegen by letting the optimizer be full on, even acrosss modules with some C compilers (gcc 4.5, Visual C++, at least) ? better debugging with stock debuggers (including Visual C++, windbg) ? a portable distribution format -- no more having to distribute binaries, though they still have advantages ???? easier to get into the various "ports" systems I think as a result ? a much smaller system overall (no GPL, if it matters) Again, there are drawbacks, but it just seems so very tempting. I'm sure I'll plug away at m3cc a while longer, but I think more and more it is questionable. I can try again to read the LLVM stuff. A new backend I think is unavoidably a lot of work, be it C or LLVM. That's my hangup on both of these. It requires knowing a lot about two big things -- M3CG and the underlying generator. parse.c is "only" 6,000 lines but pretty dense in terms of information gone into it. Maybe I'm just feeling dumb. The thing about C though, is it is a very well understood next layer down. Certainly compared to the gcc trees or LLVM. I don't think it is just me, that I'm some C expert. > This could probably be improved a lot by switching to a better debug info format, > probably the latest Dwarf variant. But that is a big job. I don't believe we have to do *anything* sort of to switch debug formats. We just have to provide gcc with decently formed typeful trees. It should do the rest. Currently I guess it is all custom. I tried -g again, thinking maybe things were better now. It still crashes. It seems related to the fact that _m3_fault is in an unknown location. But that seems actually deliberate and reasonable, and I tried fiddling with it anyway. No luck yet. This debug format problem is also solved by using C intermediate code. You just use -g or -gdb or -Zi or whatever, whatever is normal for C, and it'd just work. Anyway.. ?- Jay From jay.krell at cornell.edu Sat Aug 28 10:46:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Aug 2010 08:46:51 +0000 Subject: [M3devel] conversion to another version control system In-Reply-To: <1282983172.2770.71.camel@boromir.m3w.org> References: <20100827173502.GA8777@topoi.pooq.com>,, <20100827180902.GA8903@topoi.pooq.com>,, ,, <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>,, <20100827193836.GC8903@topoi.pooq.com>, , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, <1282983172.2770.71.camel@boromir.m3w.org> Message-ID: Perforce is closed source, but it is free of charge ("free beer") for Open Source work. It is an excellent excellent system and I can provide good support here for it, writing up introductory and advanced material and answering questions. It is easy to use. It is just an excellent system and I've used it *a lot*. FreeBSD and OpenWatcom use it. The FreeBSD Perforce repository: ? http://p4web.freebsd.org/@md=d&cd=//&c=0qt@//?ac=83 The OpenWatcom Perforce repository: http://perforce.openwatcom.org:4000/@md=d&cd=//&c=bxM@//?ac=83 ?- Jay ---------------------------------------- > From: dragisha at m3w.org > To: darko at darko.org > Date: Sat, 28 Aug 2010 10:12:52 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] conversion to another version control system > > I use mercurial from time to time and from what I found it's excellent > little package. Does its work well, is distributed, supported by trac... > What else we need? :) > > On Fri, 2010-08-27 at 23:31 -0700, Darko wrote: > > FWIW, I like and use mercurial which has good support generally. > > Perforce is commercial and proprietary. > -- > Dragi?a Duri? > From darko at darko.org Sat Aug 28 10:56:11 2010 From: darko at darko.org (Darko) Date: Sat, 28 Aug 2010 01:56:11 -0700 Subject: [M3devel] conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, , <20100827180902.GA8903@topoi.pooq.com>, , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , <20100827193836.GC8903@topoi.pooq.com>, , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, <1282983172.2770.71.camel@boromir.m3w.org> Message-ID: <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org> I sort of meant software support. But isn't this all academic since Elego is a CVS shop and they host the project? On 28/08/2010, at 1:46 AM, Jay K wrote: > > Perforce is closed source, but it is free of charge ("free beer") for Open Source work. > > > It is an excellent excellent system and I can provide good support here for it, > writing up introductory and advanced material and answering questions. > It is easy to use. > It is just an excellent system and I've used it *a lot*. > > > FreeBSD and OpenWatcom use it. > The FreeBSD Perforce repository: http://p4web.freebsd.org/@md=d&cd=//&c=0qt@//?ac=83 > The OpenWatcom Perforce repository: http://perforce.openwatcom.org:4000/@md=d&cd=//&c=bxM@//?ac=83 > > > - Jay > > ---------------------------------------- >> From: dragisha at m3w.org >> To: darko at darko.org >> Date: Sat, 28 Aug 2010 10:12:52 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] conversion to another version control system >> >> I use mercurial from time to time and from what I found it's excellent >> little package. Does its work well, is distributed, supported by trac... >> What else we need? :) >> >> On Fri, 2010-08-27 at 23:31 -0700, Darko wrote: >>> FWIW, I like and use mercurial which has good support generally. >>> Perforce is commercial and proprietary. >> -- >> Dragi?a Duri? >> > From jay.krell at cornell.edu Sat Aug 28 11:54:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 28 Aug 2010 09:54:54 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: , Message-ID: Interesting. TYPE Color1 = RECORD a,b,c: REAL; END; TYPE Color2 = RECORD a,b,c: REAL; END; Have the same id. If the module defining them also imports an interface with a type with the same id, ? or I think, if its interface defines a type with same id (same thing I think, ? no relationship at the cg level between a module and its interface), then the declare_records are skipped. The fix is probably something simple in Type.Compile involve the order it checks the tables in when deciding to call t.compile or not. Or can it just always call t.compile? Worst thing is that extra type information created? A lot of it? (all types in all imports, instead of just the used ones??) ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] importing types not described to backend > Date: Fri, 27 Aug 2010 18:35:00 +0000 > > > Very wierd: > > MODULE Main; > IMPORT Color; > TYPE ColorT = RECORD a,b,c: REAL; END; > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > BEGIN > END F1; > > BEGIN > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > END Main. > > > This fails. If you remove the IMPORT, it worked. > The declare_record of ColorT comes and goes with that change. > So I guess the error really is in F1. > > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Fri, 27 Aug 2010 18:28:47 +0000 > > Subject: [M3devel] importing types not described to backend > > > > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > > > INTERFACE Color; > > TYPE T = RECORD a,b,c:REAL; END; > > END Color. > > > > > > MODULE Main; > > IMPORT Color; > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > BEGIN > > END F1; > > > > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > > BEGIN > > END F2; > > > > > > BEGIN > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > > END Main. > > > > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > > ../Main.m3: In function 'Main__F1': > > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > > > > I fixed it so F1 is ok. > > But still F2 isn't. > > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > > > > The problem as I understand is we don't tell the backend about imported types. > > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > > > > I intend to fix this if I don't here any objections. > > I'm hoping it isn't too much work. > > I believe it will mostly/all be in m3front. > > > > > > My opinion of our gcc backend drops.. > > > > > > Perhaps the time is better used on a C front end. > > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > > > > Thanks, > > - Jay > > > From rodney_bates at lcwb.coop Sat Aug 28 21:15:02 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 28 Aug 2010 14:15:02 -0500 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , <4C77D7D3.6070602@lcwb.coop> Message-ID: <4C796036.1000806@lcwb.coop> Jay K wrote: > >> There is no way a debugger that has no Modula-3 awareness is going to provide >> a Modula-3-like view. The operators will have C spellings and C semantics, > > > How many operators do people use in a debugger? > > I use very few. Partly because for a long time I used a debugger > with a great gui and an awful expression evaluator. > > > Still, I use basically only "+" "->" "*" (dereference) and "=" for assignment. > Sometimes multiplication and subtraction. > I agree it would be nice if all the C debuggers would be lenient about "->" vs. ".". > That would unify Modula-3, Java, C#, C, C++. > Except where C++ has an operator-> overload. But operator overload > is an area where.. tangent... C++ is a great language..my compiler implements > it well..but my debugger, my editor, plain text search.. can't cope with it. > Modula-3, C#, Java run afoul of plain text search too -- anything with prevalent "scoped names". > In C you get Window_Init, File_Open, etc. never just Init or Open. > How do you search for calls to operator+ in C++? For a certain type? > In C, except for the builtin types, they'd be unique function names. > Anyway, tangent over. > > > + is the same in the various languages. > > I think "=", ":=", "==" are the main problem. > You might try a compare and accidentally to an assignment. > > >> The syntax will be strictly C. > > Almost the same. > > > > The display of values will be C. > > Almost the same. On the strength of your comments, I rest my case. > > Also if you have a particularly good C compiler/debugger, we could do > #define AND && > #define OR || > > > getting you back those two operators, which I rarely use in a debugger. > > > > TEXT won't work in any reasonable way at all. > > Sure it might. > In Visual Studio you can write little addins to help the debugger display stuff. > I believe there is a small builtin "language" or I believe you can write actual code. > In Windbg you can write little plugins. You could provide like !m3.text. > I don't know if you can tell the debugger ahead of time how to custom display types. > I don't know if gdb has a story here. > Still, one might imagine a *small* patch to gdb. All of which is just different ways of providing a debugger with proper Modula-3 support. > > > > Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 > > type info would be lost, and output formats would lose. > > > Um, you think maybe this stuff was done the wrong way in the first place? > That the names shouldn't be mangled in the first place? > I strongly suspect so. Other systems don't depend on this. > (Yes, I know about C++ name mangling, and even though it does something similar, > that's a trick for the linker and now how debug information works. It for > in the absence of debug information, among other reasons.) > I think it could be done a lot better if switching to a better debug info format. stabs may have been the best option around at the time it was done. And I don't know if Modula-3's structural type equivalence rules could be supported any better without the uid's. But there will still have to be name mangling to get a standard linker to work, with just about any language. Stock gdb does what it does in part because it has builtin demanglers for the various languages it supports. It chooses the appropriate demangler dynamically. It would be a pretty ugly user interface if it didn't. > There is "naturally" type information you get just by building up decent gcc trees. > Ditto for intermediate C code. > For a while you know, every record is a void* or just has a size, and all the type information > is buried in the names. This is questionable. I'm sure it has some advantages. > You can describe things maybe not easily described in C. > e.g. Subranges? > And then our code in m3gdb is probably very portable, in that, I think, we just ferry along > some strings, from our code to our code, and we can decipher them the same in all systems. > I think, I'm not sure, there is like no dependence on the vagaries of coff, dwarf, etc., and > what they can or cannot represent. However there is a dependency on stabs being available. > It is not for example available on HP-UX. > > > Furthermore the lack of correct type information, apart from stabs, causes problems. > For some targets the backend wants accurate type information to pass records by value. > I again/still think we should probably not rely on the backend for this anyway. > We should probably make a copy and pass a pointer to it, kind of like m3x86 does. > Certainly, a back end needs type information for code generation. That won't do much to help a debugger that is oblivious to the source language. > > > Things that use pointers at the machine level can never know whether the pointers > > point to a single value or an array, and if the latter, with what bounds. > > > C programmers can cope with that. Can't we? Look at the security advisories. Buffer overflow, buffer overrun, buffer overflow, ... over and over. Almost all of them are buffer overruns. But that's a tangent too. > And..I admit.. I don't know what our machine level mapping looks like. > Do we pass a pointer and a size as two parameters? Or a small record with pointer/size by value? > If it's a fixed array, its all in the static type, which the stabs (as extended for Modula-3) info conveys. If it's an open array, there is runtime dope: a pointer to the zero-th array element, followed by a shape, which is just a list of words giving the NUMBER of each dimension. The dimension count is statically known. generally passed by reference, although it is never altered. For heap-allocated arrays, it's located right in the heap object, at the beginning, making the pointer redundant. For Formal parameters, if the actual doesn't already have the needed dope, it is constructed at runtime by code at the call site. This works for, e.g., passing a fixed array or a SUBARRAY to a formal that is open. BTW, this is another thing a debugger has to know about to either pass, display, or alter open array values. Perhaps Dwarf is sophisticated enough that it could just be encoded in Dwarf, but certainly not in stabs. (Well, we could probably cobble up yet another stabs extension, but that would still require specialized debugger support.) > > The debugger need not be a full blown Modula-3 interpreter. > > >> Probably the worst thing will be calls. They just don't work without the debugger >> having knowledge of a lot of stuff. There are extra hidden parameters, method >> calls, passing procedure-typed parameters with environments, calling the same, >> the three modes of Modula-3, etc. I consider calls in debugger commands very >> valuable. > > > I use calls very rarely. > I'm not super keen on running some of my code when otherwise my code is all frozen > and some of it is misbehaving. I know this is partly me. > > > Even so, generally you only call certain functions that put there for use from a debugger, right? > Like gcc's debug_node or such? > And they tend to not be fancy? I regularly type a debugger call to rexecute something that I just stepped over, not knowing whether the problem I am looking for would occur inside the procedure or not. Reverse debugging in the newest gdb could provide an alternative, but I am hearing that the necessary recording costs ~ n*10 slowdown. I also do it as an easy way to test some parameter combination. Kind of like having an interpreter for the language. And I do it with fancy procedures that format some elaborate data structure in a readable, high-level way, which is, I think, what you meant. Sometimes a *lot* of effort. > > And the extra parameters..debugger would complain about missing them, programmer would figure it out? Before I got call support working, I found there were many calls I could not make work at all. Either I couldn't figure out what was needed (This amounts, in part, to manually reading stabs), or there was no way to supply what was needed in a debugger command. Also, on method calls, there was no way to figure out where it would dispatch to, even when you could locate all the possible overrides in all the subtypes, in all the source files of the closure. Language-specific support can take care of this, when done completely. m3gdb is a long way from there now, but it helps a lot. > > > I'm not saying there aren't drawbacks here. > But there are also major advantages. > There are major costs and drawbacks to our current approach. > We have a ton of extra code. > Which I don't think we are well equipped for. > Maybe Tony is. Maybe someone else is. I'm not. > > > Partly, I'll admit, anything I write, I am much more able to maintain. > Or, another lazy angle, anything smaller is easier to maintain. > > > In gcc we have a large code base. It takes me a long time to get just slightly up to speed on it. > We have several nagging problems with it. Maybe I just need to look at the C front end more. > Or read tree.h. I don't know. > > > 4.5.1 doesn't work with SPARC32_SOLARIS/SOLgnu/SOLsun. > 4.3.5 maybe not either. > A few optimizations I have turned off for 4.5.1 because they cause problems. Including inlining. > Maybe I just need to debug more. > Apple and OpenBSD each maintain their own forks. So that, *sort of but not really*, triples things. > (now, they are all highly related, so it doesn't) So far we don't have the OpenBSD fork. > But for example 4.5.1 doesn't have the OpenBSD/powerpc stuff quite. And there is a small OpenBSD/mips64 > problem I worked around. Minor, I guess. We could just drop these platforms, or OpenBSD entirely. > Not a huge deal. But it is yet more stuff that C as an intermediate platform solves. > Exception handling stinks on all platforms but SOLsun/SOLgnu. > The ALPHA_OSF code no longer works. I tried. > Generating C/C++ would significantly improve exception handling nearly across the board. > It is possible otherwise, but much more difficult. > > > So, again, C as intermediate code isn't perfect or without drawbacks, but it promises: > greatly increased portability > more efficient exception handling > better codegen by letting the optimizer be full on, even acrosss modules with some C compilers (gcc 4.5, Visual C++, at least) > better debugging with stock debuggers (including Visual C++, windbg) > a portable distribution format -- no more having to distribute binaries, though they still have advantages > easier to get into the various "ports" systems I think as a result > a much smaller system overall (no GPL, if it matters) > > > Again, there are drawbacks, but it just seems so very tempting. > > > I'm sure I'll plug away at m3cc a while longer, but I think more and more it is questionable. > > > I can try again to read the LLVM stuff. > > > A new backend I think is unavoidably a lot of work, be it C or LLVM. > That's my hangup on both of these. It requires knowing a lot about two big things -- M3CG and the underlying generator. > parse.c is "only" 6,000 lines but pretty dense in terms of information gone into it. Maybe I'm just feeling dumb. > > > The thing about C though, is it is a very well understood next layer down. Certainly compared to > the gcc trees or LLVM. I don't think it is just me, that I'm some C expert. > > > >> This could probably be improved a lot by switching to a better debug info format, >> probably the latest Dwarf variant. But that is a big job. > > > I don't believe we have to do *anything* sort of to switch debug formats. > We just have to provide gcc with decently formed typeful trees. > It should do the rest. > Currently I guess it is all custom. It doesn't provide nearly enough information in stock form. The "stabs" it now produces has a lot of Modula-3-specific stuff crammed inside the fields of stabs entries. This had be be added by the original implementors of the gcc backend. A different debug format will need changes to gcc to emit what is needed. However, it might well be entirely within the "llanguage" of, say Dwarf, which is very general. It certainly would be a lot cleaner, and it could easily be completed in places that are now hard. So there would still be a lot of work. I don't completely understand where the current back end emits all the stabs stuff, but I believe all or almost all of it comes through code in parse.c calling utility code (dbxout.c, e.g.), and is not much taken from the trees gcc uses. This is why I have yet to figure out how to write correct debug info describing the locations of static links, since gcc develops this information by transforming trees, after parse.c has done its thing. > > I tried -g again, thinking maybe things were better now. It still crashes. > It seems related to the fact that _m3_fault is in an unknown location. > But that seems actually deliberate and reasonable, and I tried fiddling with it anyway. > No luck yet. > > > This debug format problem is also solved by using C intermediate code. > You just use -g or -gdb or -Zi or whatever, whatever is normal for C, and it'd just work. > Lots of things, TEXT being probably the worst, won't display in a Modula-3 form this way. And things in expressions/statements won't work either. A debugger user will have to understand a lot of low-level stuff about how the C back end translates Modula-3 code to C, to use it at all, and it will still be far less convenient. > > Anyway.. > - Jay > From mvfranz at gmail.com Sun Aug 29 01:06:45 2010 From: mvfranz at gmail.com (Michael Franz) Date: Sat, 28 Aug 2010 19:06:45 -0400 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system Message-ID: Hi, I have been reading Systems Programming with Modula-3, edited by Greg Nelson. The chapter on Trestle refers to SRC Report 69 - Performance analysis of a multiprocessor window system. I have some link on the web, but they are all broken. The one that did work I cannot display. Does anyone know where I can get the pdf version? Thank you Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Aug 29 01:51:57 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 28 Aug 2010 18:51:57 -0500 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system In-Reply-To: References: Message-ID: <4C79A11D.8010008@lcwb.coop> Inside the cm3 CVS release branch (cm3-58--release) (and no doubt the head too), is file doc/src_reports/src-069.pdf. When I open it, its title page has report number 69 and title "Trestle Tutorial", which agrees with its contents. It is hard to image SRC would have ambiguously numbered reports. The report number must be a mistake in the citation. I have a printed copy of SRC 135a, with a listing in the back of the reports through 133b, with no mention of that title. Not much help, but it might help structure searches more effectively. I think copies of a lot of the SRC stuff are still online somewhere, but I don't remember where. Perhaps an HP site? Michael Franz wrote: > Hi, > > I have been reading Systems Programming with Modula-3, edited by Greg > Nelson. The chapter on Trestle refers to SRC Report 69 - Performance > analysis of a multiprocessor window system. I have some link on the > web, but they are all broken. The one that did work I cannot display. > Does anyone know where I can get the pdf version? > > Thank you > > Michael From rodney_bates at lcwb.coop Sun Aug 29 02:02:17 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 28 Aug 2010 19:02:17 -0500 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system In-Reply-To: <4C79A11D.8010008@lcwb.coop> References: <4C79A11D.8010008@lcwb.coop> Message-ID: <4C79A389.1070202@lcwb.coop> Rodney M. Bates wrote: > Inside the cm3 CVS release branch (cm3-58--release) (and no doubt the > head too), > is file doc/src_reports/src-069.pdf. When I open it, its title page has > report > number 69 and title "Trestle Tutorial", which agrees with its contents. > It is hard to image SRC would have ambiguously numbered reports. > The report number must be a mistake in the citation. > > I have a printed copy of SRC 135a, with a listing in the back of the > reports > through 133b, with no mention of that title. > > Not much help, but it might help structure searches more effectively. > > I think copies of a lot of the SRC stuff are still online somewhere, but I > don't remember where. Perhaps an HP site? P.S.: http://www.hpl.hp.com/techreports/Compaq-DEC/ has them. But not that title. P.P.S. If you are seriously reading either the Trestle tutorial or reference manual are puzzled the concept of a "share of a mutex", I can help, if I can remember it. It took me years to figure out what it meant. > > Michael Franz wrote: >> Hi, >> >> I have been reading Systems Programming with Modula-3, edited by Greg >> Nelson. The chapter on Trestle refers to SRC Report 69 - Performance >> analysis of a multiprocessor window system. I have some link on the >> web, but they are all broken. The one that did work I cannot display. >> Does anyone know where I can get the pdf version? >> >> Thank you >> >> Michael > From jay.krell at cornell.edu Sun Aug 29 02:21:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 00:21:31 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <4C796036.1000806@lcwb.coop> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, ,,, , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , , , <4C77D7D3.6070602@lcwb.coop>, , <4C796036.1000806@lcwb.coop> Message-ID: Ps we don't even have m3gdb for all systems e.g. Darwin, and the Windows debuggers are much better than anything I've seen on Unix. On these systems intermediate C would improve debugging much. Though Darwin gdb I've also been improving. Also you seem to confuse C name mangling with what Modula-3 does. They are quite different. C only mangles things with linkage, for linking reasons, not for debugging information. Locals, parameters, record fields: no mangling. C code analogous to what Modula-3 allows would survive with everything being extern C, no name mangling. In both cases as I understand, an effective hack to tunnel information through systems not quite designed/extended to suit. What we have is flawed. What I favor is flawed. But differently. - Jay/phone > Date: Sat, 28 Aug 2010 14:15:02 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? > > > > Jay K wrote: > > > >> There is no way a debugger that has no Modula-3 awareness is going to provide > >> a Modula-3-like view. The operators will have C spellings and C semantics, > > > > > > How many operators do people use in a debugger? > > > > I use very few. Partly because for a long time I used a debugger > > with a great gui and an awful expression evaluator. > > > > > > Still, I use basically only "+" "->" "*" (dereference) and "=" for assignment. > > Sometimes multiplication and subtraction. > > I agree it would be nice if all the C debuggers would be lenient about "->" vs. ".". > > That would unify Modula-3, Java, C#, C, C++. > > Except where C++ has an operator-> overload. But operator overload > > is an area where.. tangent... C++ is a great language..my compiler implements > > it well..but my debugger, my editor, plain text search.. can't cope with it. > > Modula-3, C#, Java run afoul of plain text search too -- anything with prevalent "scoped names". > > In C you get Window_Init, File_Open, etc. never just Init or Open. > > How do you search for calls to operator+ in C++? For a certain type? > > In C, except for the builtin types, they'd be unique function names. > > Anyway, tangent over. > > > > > > + is the same in the various languages. > > > > I think "=", ":=", "==" are the main problem. > > You might try a compare and accidentally to an assignment. > > > > > >> The syntax will be strictly C. > > > > Almost the same. > > > > > > > The display of values will be C. > > > > Almost the same. > > On the strength of your comments, I rest my case. > > > > > Also if you have a particularly good C compiler/debugger, we could do > > #define AND && > > #define OR || > > > > > > getting you back those two operators, which I rarely use in a debugger. > > > > > > > TEXT won't work in any reasonable way at all. > > > > Sure it might. > > In Visual Studio you can write little addins to help the debugger display stuff. > > I believe there is a small builtin "language" or I believe you can write actual code. > > In Windbg you can write little plugins. You could provide like !m3.text. > > I don't know if you can tell the debugger ahead of time how to custom display types. > > I don't know if gdb has a story here. > > Still, one might imagine a *small* patch to gdb. > > All of which is just different ways of providing a debugger with proper Modula-3 support. > > > > > > > > Demangling names in the compiler's debug output would make them look nice, but then the Modula-3 > > > type info would be lost, and output formats would lose. > > > > > > Um, you think maybe this stuff was done the wrong way in the first place? > > That the names shouldn't be mangled in the first place? > > I strongly suspect so. Other systems don't depend on this. > > (Yes, I know about C++ name mangling, and even though it does something similar, > > that's a trick for the linker and now how debug information works. It for > > in the absence of debug information, among other reasons.) > > > > I think it could be done a lot better if switching to a better debug info format. > stabs may have been the best option around at the time it was done. And I don't > know if Modula-3's structural type equivalence rules could be supported any better > without the uid's. > > But there will still have to be name mangling to get a standard linker to work, > with just about any language. Stock gdb does what it does in part because it > has builtin demanglers for the various languages it supports. It chooses the > appropriate demangler dynamically. It would be a pretty ugly user interface if > it didn't. > > > There is "naturally" type information you get just by building up decent gcc trees. > > Ditto for intermediate C code. > > For a while you know, every record is a void* or just has a size, and all the type information > > is buried in the names. This is questionable. I'm sure it has some advantages. > > You can describe things maybe not easily described in C. > > e.g. Subranges? > > And then our code in m3gdb is probably very portable, in that, I think, we just ferry along > > some strings, from our code to our code, and we can decipher them the same in all systems. > > I think, I'm not sure, there is like no dependence on the vagaries of coff, dwarf, etc., and > > what they can or cannot represent. However there is a dependency on stabs being available. > > It is not for example available on HP-UX. > > > > > > Furthermore the lack of correct type information, apart from stabs, causes problems. > > For some targets the backend wants accurate type information to pass records by value. > > I again/still think we should probably not rely on the backend for this anyway. > > We should probably make a copy and pass a pointer to it, kind of like m3x86 does. > > > > Certainly, a back end needs type information for code generation. That won't do much to > help a debugger that is oblivious to the source language. > > > > > > Things that use pointers at the machine level can never know whether the pointers > > > point to a single value or an array, and if the latter, with what bounds. > > > > > > C programmers can cope with that. Can't we? > > Look at the security advisories. Buffer overflow, buffer overrun, buffer overflow, ... > over and over. Almost all of them are buffer overruns. But that's a tangent too. > > > And..I admit.. I don't know what our machine level mapping looks like. > > Do we pass a pointer and a size as two parameters? Or a small record with pointer/size by value? > > > > If it's a fixed array, its all in the static type, which the stabs (as extended for Modula-3) > info conveys. If it's an open array, there is runtime dope: a pointer to the zero-th array > element, followed by a shape, which is just a list of words giving the NUMBER of each dimension. > The dimension count is statically known. generally passed by reference, although it is never > altered. For heap-allocated arrays, it's located right in the heap object, at the beginning, > making the pointer redundant. For Formal parameters, if the actual doesn't already have the > needed dope, it is constructed at runtime by code at the call site. This works for, e.g., > passing a fixed array or a SUBARRAY to a formal that is open. > > BTW, this is another thing a debugger has to know about to either pass, display, or alter > open array values. Perhaps Dwarf is sophisticated enough that it could just be encoded in > Dwarf, but certainly not in stabs. (Well, we could probably cobble up yet another stabs > extension, but that would still require specialized debugger support.) > > > > > The debugger need not be a full blown Modula-3 interpreter. > > > > > >> Probably the worst thing will be calls. They just don't work without the debugger > >> having knowledge of a lot of stuff. There are extra hidden parameters, method > >> calls, passing procedure-typed parameters with environments, calling the same, > >> the three modes of Modula-3, etc. I consider calls in debugger commands very > >> valuable. > > > > > > I use calls very rarely. > > I'm not super keen on running some of my code when otherwise my code is all frozen > > and some of it is misbehaving. I know this is partly me. > > > > > > Even so, generally you only call certain functions that put there for use from a debugger, right? > > Like gcc's debug_node or such? > > And they tend to not be fancy? > > I regularly type a debugger call to rexecute something that I just stepped over, not knowing whether > the problem I am looking for would occur inside the procedure or not. Reverse debugging in the newest > gdb could provide an alternative, but I am hearing that the necessary recording costs ~ n*10 slowdown. > > I also do it as an easy way to test some parameter combination. Kind of like having an interpreter for > the language. And I do it with fancy procedures that format some elaborate data structure in a readable, > high-level way, which is, I think, what you meant. Sometimes a *lot* of effort. > > > > > > And the extra parameters..debugger would complain about missing them, programmer would figure it out? > > Before I got call support working, I found there were many calls I could not make work at all. Either > I couldn't figure out what was needed (This amounts, in part, to manually reading stabs), or there > was no way to supply what was needed in a debugger command. Also, on method calls, there was no way > to figure out where it would dispatch to, even when you could locate all the possible overrides in all > the subtypes, in all the source files of the closure. Language-specific support can take care of this, > when done completely. m3gdb is a long way from there now, but it helps a lot. > > > > > > > I'm not saying there aren't drawbacks here. > > But there are also major advantages. > > There are major costs and drawbacks to our current approach. > > We have a ton of extra code. > > Which I don't think we are well equipped for. > > Maybe Tony is. Maybe someone else is. I'm not. > > > > > > Partly, I'll admit, anything I write, I am much more able to maintain. > > Or, another lazy angle, anything smaller is easier to maintain. > > > > > > In gcc we have a large code base. It takes me a long time to get just slightly up to speed on it. > > We have several nagging problems with it. Maybe I just need to look at the C front end more. > > Or read tree.h. I don't know. > > > > > > 4.5.1 doesn't work with SPARC32_SOLARIS/SOLgnu/SOLsun. > > 4.3.5 maybe not either. > > A few optimizations I have turned off for 4.5.1 because they cause problems. Including inlining. > > Maybe I just need to debug more. > > Apple and OpenBSD each maintain their own forks. So that, *sort of but not really*, triples things. > > (now, they are all highly related, so it doesn't) So far we don't have the OpenBSD fork. > > But for example 4.5.1 doesn't have the OpenBSD/powerpc stuff quite. And there is a small OpenBSD/mips64 > > problem I worked around. Minor, I guess. We could just drop these platforms, or OpenBSD entirely. > > Not a huge deal. But it is yet more stuff that C as an intermediate platform solves. > > Exception handling stinks on all platforms but SOLsun/SOLgnu. > > The ALPHA_OSF code no longer works. I tried. > > Generating C/C++ would significantly improve exception handling nearly across the board. > > It is possible otherwise, but much more difficult. > > > > > > So, again, C as intermediate code isn't perfect or without drawbacks, but it promises: > > greatly increased portability > > more efficient exception handling > > better codegen by letting the optimizer be full on, even acrosss modules with some C compilers (gcc 4.5, Visual C++, at least) > > better debugging with stock debuggers (including Visual C++, windbg) > > a portable distribution format -- no more having to distribute binaries, though they still have advantages > > easier to get into the various "ports" systems I think as a result > > a much smaller system overall (no GPL, if it matters) > > > > > > Again, there are drawbacks, but it just seems so very tempting. > > > > > > I'm sure I'll plug away at m3cc a while longer, but I think more and more it is questionable. > > > > > > I can try again to read the LLVM stuff. > > > > > > A new backend I think is unavoidably a lot of work, be it C or LLVM. > > That's my hangup on both of these. It requires knowing a lot about two big things -- M3CG and the underlying generator. > > parse.c is "only" 6,000 lines but pretty dense in terms of information gone into it. Maybe I'm just feeling dumb. > > > > > > The thing about C though, is it is a very well understood next layer down. Certainly compared to > > the gcc trees or LLVM. I don't think it is just me, that I'm some C expert. > > > > > > > >> This could probably be improved a lot by switching to a better debug info format, > >> probably the latest Dwarf variant. But that is a big job. > > > > > > I don't believe we have to do *anything* sort of to switch debug formats. > > We just have to provide gcc with decently formed typeful trees. > > It should do the rest. > > Currently I guess it is all custom. > > It doesn't provide nearly enough information in stock form. The "stabs" it now produces has a lot > of Modula-3-specific stuff crammed inside the fields of stabs entries. This had be be added by the > original implementors of the gcc backend. A different debug format will need changes to gcc to > emit what is needed. However, it might well be entirely within the "llanguage" of, say Dwarf, which > is very general. It certainly would be a lot cleaner, and it could easily be completed in places > that are now hard. So there would still be a lot of work. > > I don't completely understand where the current back end emits all the stabs stuff, but I believe > all or almost all of it comes through code in parse.c calling utility code (dbxout.c, e.g.), and > is not much taken from the trees gcc uses. This is why I have yet to figure out how to write > correct debug info describing the locations of static links, since gcc develops this information > by transforming trees, after parse.c has done its thing. > > > > > I tried -g again, thinking maybe things were better now. It still crashes. > > It seems related to the fact that _m3_fault is in an unknown location. > > But that seems actually deliberate and reasonable, and I tried fiddling with it anyway. > > No luck yet. > > > > > > This debug format problem is also solved by using C intermediate code. > > You just use -g or -gdb or -Zi or whatever, whatever is normal for C, and it'd just work. > > > > Lots of things, TEXT being probably the worst, won't display in a Modula-3 form this way. > And things in expressions/statements won't work either. A debugger user will have to understand > a lot of low-level stuff about how the C back end translates Modula-3 code to C, to use it at all, > and it will still be far less convenient. > > > > > Anyway.. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvfranz at gmail.com Sun Aug 29 05:40:12 2010 From: mvfranz at gmail.com (Michael Franz) Date: Sat, 28 Aug 2010 23:40:12 -0400 Subject: [M3devel] Looking For SRC Report 69 - Performance analysis of a multiprocessor window system In-Reply-To: <4C79A389.1070202@lcwb.coop> References: <4C79A11D.8010008@lcwb.coop> <4C79A389.1070202@lcwb.coop> Message-ID: I did manage to find a version of SRC-69, but it is as you pointed out the Trestle Tutorial. I have found reference to Performance analysis of a multiprocessor window system, but not the actual report. Either the citation is wrong or SRC numbers there reports from 1 every year. The report I am looking for is from 1991, but the tutorial is from 1992. When I get to the shared mutex and have issues I will contact you, for now, I am just reading for an overview. Thank you On Sat, Aug 28, 2010 at 8:02 PM, Rodney M. Bates wrote: > > > Rodney M. Bates wrote: > >> Inside the cm3 CVS release branch (cm3-58--release) (and no doubt the head >> too), >> is file doc/src_reports/src-069.pdf. When I open it, its title page has >> report >> number 69 and title "Trestle Tutorial", which agrees with its contents. >> It is hard to image SRC would have ambiguously numbered reports. >> The report number must be a mistake in the citation. >> >> I have a printed copy of SRC 135a, with a listing in the back of the >> reports >> through 133b, with no mention of that title. >> >> Not much help, but it might help structure searches more effectively. >> >> I think copies of a lot of the SRC stuff are still online somewhere, but I >> don't remember where. Perhaps an HP site? >> > > P.S.: http://www.hpl.hp.com/techreports/Compaq-DEC/ has them. But not > that title. > > P.P.S. If you are seriously reading either the Trestle tutorial or > reference manual are puzzled the concept of a "share of a mutex", > I can help, if I can remember it. It took me years to figure out > what it meant. > > > >> Michael Franz wrote: >> >>> Hi, >>> >>> I have been reading Systems Programming with Modula-3, edited by Greg >>> Nelson. The chapter on Trestle refers to SRC Report 69 - Performance >>> analysis of a multiprocessor window system. I have some link on the web, >>> but they are all broken. The one that did work I cannot display. Does >>> anyone know where I can get the pdf version? >>> >>> Thank you >>> >>> Michael >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Aug 29 09:35:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 07:35:24 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: , , Message-ID: I've been quite banging my head against this. I believe basically every type referenced in a module must be "described" to the backend, such as with declare_opaque, declare_record, etc. Type.Compile should call t.compile on more stuff. You need not declare everything in every imported module. Only types that are used. There is at least one hard to solve problem here, for some level of lack of understanding at least. Specifically if you call t.compile on all types in Type.Compile, RecordType.Compiler => Scope.InitValues ?=> assertion failures about non-empty stack. It seems Type.Compile gets called "in the middle of stuff" instead of just from CompileAll. I'm almost stumped. I have to check still where Type.Compile vs. Type.CompileAll are called. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] importing types not described to backend > Date: Sat, 28 Aug 2010 09:54:54 +0000 > > > Interesting. > > TYPE Color1 = RECORD a,b,c: REAL; END; > TYPE Color2 = RECORD a,b,c: REAL; END; > > Have the same id. > If the module defining them also imports an interface with a type with the same id, > or I think, if its interface defines a type with same id (same thing I think, > no relationship at the cg level between a module and its interface), > then the declare_records are skipped. > > The fix is probably something simple in Type.Compile involve the order it checks the tables in > when deciding to call t.compile or not. > > Or can it just always call t.compile? > Worst thing is that extra type information created? > A lot of it? (all types in all imports, instead of just the used ones??) > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: RE: [M3devel] importing types not described to backend > > Date: Fri, 27 Aug 2010 18:35:00 +0000 > > > > > > Very wierd: > > > > MODULE Main; > > IMPORT Color; > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > BEGIN > > END F1; > > > > BEGIN > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > END Main. > > > > > > This fails. If you remove the IMPORT, it worked. > > The declare_record of ColorT comes and goes with that change. > > So I guess the error really is in F1. > > > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Date: Fri, 27 Aug 2010 18:28:47 +0000 > > > Subject: [M3devel] importing types not described to backend > > > > > > > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > > > > > INTERFACE Color; > > > TYPE T = RECORD a,b,c:REAL; END; > > > END Color. > > > > > > > > > MODULE Main; > > > IMPORT Color; > > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > > BEGIN > > > END F1; > > > > > > > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > > > BEGIN > > > END F2; > > > > > > > > > BEGIN > > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > > > END Main. > > > > > > > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > > > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > > > ../Main.m3: In function 'Main__F1': > > > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > > > > > > > I fixed it so F1 is ok. > > > But still F2 isn't. > > > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > > > > > > > The problem as I understand is we don't tell the backend about imported types. > > > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > > > > > > > I intend to fix this if I don't here any objections. > > > I'm hoping it isn't too much work. > > > I believe it will mostly/all be in m3front. > > > > > > > > > My opinion of our gcc backend drops.. > > > > > > > > > Perhaps the time is better used on a C front end. > > > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > > > > > > > Thanks, > > > - Jay > > > > > > From jay.krell at cornell.edu Sun Aug 29 09:52:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 07:52:23 +0000 Subject: [M3devel] importing types not described to backend In-Reply-To: References: , , , , , Message-ID: Arg. Another problem I see in some attempted fixes is: opaque type defined twice: _t9a0e5dbc ? defined in? FileWr.i3 ? and also??? System.m3 ? I don't need to reveal opaque types repeatedly but I do need to declare them repeatedly -- so that backend knows they are pointers.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sun, 29 Aug 2010 07:35:24 +0000 > Subject: Re: [M3devel] importing types not described to backend > > > I've been quite banging my head against this. > I believe basically every type referenced in a module must be > "described" to the backend, such as with declare_opaque, declare_record, etc. > > Type.Compile should call t.compile on more stuff. > You need not declare everything in every imported module. Only types that are used. > > There is at least one hard to solve problem here, for some level of lack of understanding at least. > Specifically if you call t.compile on all types in Type.Compile, RecordType.Compiler => Scope.InitValues > => assertion failures about non-empty stack. > > It seems Type.Compile gets called "in the middle of stuff" instead of just from CompileAll. > > I'm almost stumped. > I have to check still where Type.Compile vs. Type.CompileAll are called. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Subject: RE: [M3devel] importing types not described to backend > > Date: Sat, 28 Aug 2010 09:54:54 +0000 > > > > > > Interesting. > > > > TYPE Color1 = RECORD a,b,c: REAL; END; > > TYPE Color2 = RECORD a,b,c: REAL; END; > > > > Have the same id. > > If the module defining them also imports an interface with a type with the same id, > > or I think, if its interface defines a type with same id (same thing I think, > > no relationship at the cg level between a module and its interface), > > then the declare_records are skipped. > > > > The fix is probably something simple in Type.Compile involve the order it checks the tables in > > when deciding to call t.compile or not. > > > > Or can it just always call t.compile? > > Worst thing is that extra type information created? > > A lot of it? (all types in all imports, instead of just the used ones??) > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Subject: RE: [M3devel] importing types not described to backend > > > Date: Fri, 27 Aug 2010 18:35:00 +0000 > > > > > > > > > Very wierd: > > > > > > MODULE Main; > > > IMPORT Color; > > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > > BEGIN > > > END F1; > > > > > > BEGIN > > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > > END Main. > > > > > > > > > This fails. If you remove the IMPORT, it worked. > > > The declare_record of ColorT comes and goes with that change. > > > So I guess the error really is in F1. > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > > > From: jay.krell at cornell.edu > > > > To: m3devel at elegosoft.com > > > > Date: Fri, 27 Aug 2010 18:28:47 +0000 > > > > Subject: [M3devel] importing types not described to backend > > > > > > > > > > > > This is distilled from m3-ui/anim3d/src/x-opengl/X_OpenGL_Base.m3 > > > > > > > > INTERFACE Color; > > > > TYPE T = RECORD a,b,c:REAL; END; > > > > END Color. > > > > > > > > > > > > MODULE Main; > > > > IMPORT Color; > > > > TYPE ColorT = RECORD a,b,c: REAL; END; > > > > > > > > > > > > <*NOWARN*> PROCEDURE F1 (a,b,c,d,e,f:INTEGER; g:ColorT) = > > > > BEGIN > > > > END F1; > > > > > > > > > > > > <*NOWARN*> PROCEDURE F2 (a,b,c,d,e,f:INTEGER; g:Color.T) = > > > > BEGIN > > > > END F2; > > > > > > > > > > > > BEGIN > > > > F1(1,2,3,4,5,6,ColorT{1.0,2.0,3.0}); > > > > F2(2,3,4,5,6,7,Color.T{2.0,3.0,4.0}); > > > > END Main. > > > > > > > > > > > > On SPARC64_SOLARIS there is an assertion failure in the backend: > > > > /dev2/cm3/m3-sys/m3cc/SPARC64_SOLARIS/gcc/m3cgc1 -mno-app-regs -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ Main.mc -o Main.ms > > > > ../Main.m3: In function 'Main__F1': > > > > ../Main.m3:13: internal compiler error: in function_arg_record_value, at config/sparc/sparc.c:5038 > > > > > > > > > > > > I fixed it so F1 is ok. > > > > But still F2 isn't. > > > > The error is reported for F1, though that is wrong. If you comment out F2, it compiles ok. > > > > > > > > > > > > The problem as I understand is we don't tell the backend about imported types. > > > > There is nothing in the IR about them, judging from -y and a quick look at parse.c. > > > > > > > > > > > > I intend to fix this if I don't here any objections. > > > > I'm hoping it isn't too much work. > > > > I believe it will mostly/all be in m3front. > > > > > > > > > > > > My opinion of our gcc backend drops.. > > > > > > > > > > > > Perhaps the time is better used on a C front end. > > > > Though in this case, I think the work is shared, the same stuff would be missing there too. > > > > > > > > > > > > Thanks, > > > > - Jay > > > > > > > > > > From jay.krell at cornell.edu Sun Aug 29 11:54:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 09:54:16 +0000 Subject: [M3devel] representation of opaque types? Message-ID: Are values of opaque types always pointers? Is that something that might change/improve? This for purposes of fixing the type information in the gcc backend. The backend really would like accurate type information. For purposes of passing records by value, and for debugging, at least. ?? Unless we would/should/could/will just deoptimize passing records by value, which would cover up this headache. I'll poke around more.. http://www.cs.tut.fi/lintula/manual/modula3/m3defn/html/opaques.html TYPE T <: U where T is an identifier and U an expression denoting a reference type. It introduces the name T as an opaque type and reveals that U is a supertype of T. The concrete type of T must be revealed elsewhere in the program. That clears it up -- U is a reference type. Seems like it might be nice if the "linker" could optimize and teach clients of opaque types their sizes and allow them to be stack-allocated. What does it mean when the front end says "new opaque info, recompiling"? I'll poke around.. ?- Jay From wagner at elegosoft.com Sun Aug 29 12:45:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 12:45:13 +0200 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, ,,, , , <20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, , , , <4C77D7D3.6070602@lcwb.coop>, , <4C796036.1000806@lcwb.coop> Message-ID: <20100829124513.otk0e8am8ww00gw8@mail.elegosoft.com> Quoting Jay K : > Ps we don't even have m3gdb for all systems e.g. Darwin, and the > Windows debuggers are much better than anything I've seen on Unix. > On these systems intermediate C would improve debugging much. Though > Darwin gdb I've also been improving. > > Also you seem to confuse C name mangling with what Modula-3 does. > They are quite different. C only mangles things with linkage, for > linking reasons, not for debugging information. Locals, parameters, > record fields: no mangling. C code analogous to what Modula-3 > allows would survive with everything being extern C, no name mangling. > > In both cases as I understand, an effective hack to tunnel > information through systems not quite designed/extended to suit. > > What we have is flawed. What I favor is flawed. But differently. We don't need to give up what we have in order to try something else additionally, do we? I think m3gdb works quite well on some platforms these days. Unfortunately, it doesn't build on others. On Windows we'll need something for the native debuggers anyway. Improving the use of other C debuggers will be good, too, for platforms we haven't got anything else. What I've learned from this discussion is that we should definitely try to support dwarf debugging format for the gcc backend. I'll add that as a task for the 5.9 release. And Jay has already announced that he will be working on a C backend. That should open up other possibilities. 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 Sun Aug 29 13:15:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 13:15:44 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org> References: <20100827173502.GA8777@topoi.pooq.com>, , <20100827180902.GA8903@topoi.pooq.com>, , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , <20100827193836.GC8903@topoi.pooq.com>, , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, <1282983172.2770.71.camel@boromir.m3w.org> <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org> Message-ID: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Quoting Darko : > I sort of meant software support. But isn't this all academic since > Elego is a CVS shop and they host the project? No. Elego is no CVS shop. We're not a shop at all in the sense that you can buy anything from our shelves. We help other companies improve their development processes wrt. software configuration management. Actually, almost all our work in the recent 2 yours has been Subversion-related. For more information of what we do, have a look at our web pages at http://www.elegosoft.com/. We used CVS for M3 at the start because it was the only reasonable possibility several years ago. I always opposed a switch of the system because it will bind a lot of resources we could use better, e.g. for improving the debugging support, IPv6 support, writing a C backend, etc. And we don't really need more than CVS offers. I still doubt that somebody will do all the work to set up a new version control infrastructure with easy migration, Hudson and trac integration, etc. If anybody sets up something that works better than what we have, we will of course use it. Elego will continue to provide some resources for the M3 project in form of CPU time, disk space and administration support if the community wants that. And we'll provide git or mercurial or svn access for M3 if it is needed. Actually, svn should be rather easy. We currently have some overload problems with the server that hosts CVS and the M3 continuous integration, which led me to reduce the number of checkouts and builds. This will be sorted out during the fall. Unfortunately, we don't have hard data about i/o needs of other systems compared to CVS yet (but we'll get them). BTW, CI is working quite well now, and produces nightly snapshots that can be downloaded for almost all supported platforms, so this is better than ever before. See http://hudson.modula3.com:8080/view/cm3-current/ for details. 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 Sun Aug 29 14:02:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 12:02:01 +0000 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: ?> We're not a shop at all in the sense that you can buy anything from our shelves "Shop" has a different meaning in this context. English is wierd. Roughly speaking "an X shop" is a "company that tends to use product X or products from company X, not necessarily to the exclusion of others" "a Microsoft shop" "a Java shop" "a Unix shop" "an Oracle shop" "a .NET shop" ?> And we don't really need more than CVS offers. ? A few things bug me. The number one is that there are no change lists, just multiple independent changes to independent files. I want to be able to browse history as a list of changes, and click on them, not navigate to each file individually. I would also like a system that keeps enough local state so that I can diff my local version against current without going to the slow unreliable network. The network is indeed very slow and unreliable. Perforce seems ideal in so many ways. Its command line interface is excellent. Its gui is very good. Its feature set is excellent. Its branching support is excellent. I don't know if it has good offline support though. I think I would settle for SVN. Though SVN has completely broken branching last I checked, and they acknowledged it. SVN also has relatively large dependencies to build from source. I would also like a system that doesn't drop files/directories all over the place. Just in the root of a checkout should suffice and be ideal. CVS is awful here and I believe SVN is too. Perforce maybe doesn't have the portability I'd like -- e.g. I don't see OpenBSD. But that might be an ok compromise, if copying can be done, or if those platforms can be requested. It seems they are extremely extremely portable but just don't bother to provide the binaries. Through time they do have excellent platform coverage. I'm sure we don't go for this, but I do recommend it wholeheartedly. I want a system that makes me do *something* before editing a file. ? Run some command to acknowledge I'm editing it, so it can keep track. I want a systerm with a command to undo the edits. With CVS I delete and update. Lame. I want a system that quickly knows which files I have changed. Perforce meets all these requirements. When I'm lazy I do: ? p4 edit ... ? spend a while editing ? p4 revert -a? to revert anything I didn't actually change ? It is wasteful, but plenty fast. I'd prefer a system that knows how to use windiff or some other decent gui to show diffs. I've gradually become comfortable with textual diffs. But I like gui diffs. Windiff is nice. Some people think it is old and limited, but it is much better than textual diffs. CVS handling of merges and conflicts is also very poor. ?- Jay ---------------------------------------- > Date: Sun, 29 Aug 2010 13:15:44 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system > > Quoting Darko : > > > I sort of meant software support. But isn't this all academic since > > Elego is a CVS shop and they host the project? > > No. Elego is no CVS shop. We're not a shop at all in the sense > that you can buy anything from our shelves. We help other companies > improve their development processes wrt. software configuration > management. Actually, almost all our work in the recent 2 yours > has been Subversion-related. For more information of what we do, > have a look at our web pages at http://www.elegosoft.com/. > > We used CVS for M3 at the start because it was the only reasonable > possibility several years ago. > > I always opposed a switch of the system because it will bind a lot > of resources we could use better, e.g. for improving the debugging > support, IPv6 support, writing a C backend, etc. And we don't > really need more than CVS offers. > > I still doubt that somebody will do all the work to set up a new > version control infrastructure with easy migration, Hudson and trac > integration, etc. If anybody sets up something that works better > than what we have, we will of course use it. > > Elego will continue to provide some resources for the M3 project > in form of CPU time, disk space and administration support if the > community wants that. And we'll provide git or mercurial or svn > access for M3 if it is needed. Actually, svn should be rather easy. > > We currently have some overload problems with the server that hosts > CVS and the M3 continuous integration, which led me to reduce the > number of checkouts and builds. This will be sorted out during > the fall. Unfortunately, we don't have hard data about i/o needs > of other systems compared to CVS yet (but we'll get them). > > BTW, CI is working quite well now, and produces nightly snapshots > that can be downloaded for almost all supported platforms, so this > is better than ever before. See > > http://hudson.modula3.com:8080/view/cm3-current/ > > for details. > > 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 Sun Aug 29 14:25:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 29 Aug 2010 12:25:33 +0000 Subject: [M3devel] additional CVS repositories for additional gcc forks? In-Reply-To: <20100829124513.otk0e8am8ww00gw8@mail.elegosoft.com> References: <20100826125916.lfqgdj816og84wo8@mail.elegosoft.com>, , , , , , ,,<20100826141022.i8ntzebv7kwowscs@mail.elegosoft.com>, ,,, , , <4C77D7D3.6070602@lcwb.coop>, , , , <4C796036.1000806@lcwb.coop>, , <20100829124513.otk0e8am8ww00gw8@mail.elegosoft.com> Message-ID: > What I've learned from this discussion is that we should definitely try > to support dwarf debugging format for the gcc backend. I'll add that > as a task for the 5.9 release. I am not certain this makes any sense at all. I'm not sure. I don't think it is the job of a gcc front end (as Modula-3 is structured) to do anything for debugging, to know about debug formats, *except* to provide type-ful trees to the backend, which they should do anyway, except which Modula-3 historically doesn't do much. It is the job of the gcc backend -- below parse.c -- to generate debugging information. I think what Modula-3 currently does is "tunnel" a bunch of private data through to m3gdb. I think "stabs" might help associate the data with the code. Again, I don't know. And I think the trees are slightly well formed such that gcc can generate line numbers and knows a little bit about locals -- it shows pretty much everything as? void*. This is getting better lately though. I'm not doing anything specific to debugging or stabs or dwarf or something. I'm just filling in the types in the trees. There was already some code. I couldn't have figured this out so fast otherwise. We were already building struct types. But we weren't associating them with locals/parameters. What got me started down this area is actually that gcc cannot generate SPARC64_SOLARIS code that passes records by value without type information for the records. As well, if you only provide information to the caller or callee but not both, then AMD64_DARWIN and possibly others generate incorrect code. Then I realized what I had actually discovered is how to get stock gdb to work significantly better. What the code should have been doing all along. I suppose we could tunnel the private data through dwarf, but I don't think it would provide much gain. Mainly that HP-UX might stand a chance of working with a debugger. Might. Given the "data intensity" of the many debugging tasks, sprinking in RTIO calls is actually often much more effective than any debugger could be. You know, the code I want to debug gets hit many many times and I don't want to debug it until a certain late point. Getting there in a debugger is too difficult. Though easier if there is a way to get the debugger to stop, like by putting int 3 in x86 code. Win32 has the portable (to Win32 architectures) DebugBreak() call. Macintosh has similar. Too bad I haven't seen anything like this in Posix. Posix is generally very small and limiting.. ?- Jay ---------------------------------------- > Date: Sun, 29 Aug 2010 12:45:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] additional CVS repositories for additional gcc forks? > > Quoting Jay K : > > > Ps we don't even have m3gdb for all systems e.g. Darwin, and the > > Windows debuggers are much better than anything I've seen on Unix. > > On these systems intermediate C would improve debugging much. Though > > Darwin gdb I've also been improving. > > > > Also you seem to confuse C name mangling with what Modula-3 does. > > They are quite different. C only mangles things with linkage, for > > linking reasons, not for debugging information. Locals, parameters, > > record fields: no mangling. C code analogous to what Modula-3 > > allows would survive with everything being extern C, no name mangling. > > > > In both cases as I understand, an effective hack to tunnel > > information through systems not quite designed/extended to suit. > > > > What we have is flawed. What I favor is flawed. But differently. > > We don't need to give up what we have in order to try something else > additionally, do we? > > I think m3gdb works quite well on some platforms these days. Unfortunately, > it doesn't build on others. > > On Windows we'll need something for the native debuggers anyway. > > Improving the use of other C debuggers will be good, too, for platforms > we haven't got anything else. > > What I've learned from this discussion is that we should definitely try > to support dwarf debugging format for the gcc backend. I'll add that > as a task for the 5.9 release. > > And Jay has already announced that he will be working on a C backend. > That should open up other possibilities. > > 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 Sun Aug 29 15:58:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 15:58:21 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> Quoting Jay K : > I think I would settle for SVN. > Though SVN has completely broken branching last I checked, and they > acknowledged it. > SVN also has relatively large dependencies to build from source. Branching in SVN is OK, merging is still wanting in case of tree conflicts. > I would also like a system that doesn't drop files/directories all > over the place. Just in the root of a checkout should > suffice and be ideal. CVS is awful here and I believe SVN is too. The working copy overhaul expected to be included in SVN 1.7 will keep all metadata at the root of the checkout in an SQL database. > I want a system that makes me do *something* before editing a file. > ? Run some command to acknowledge I'm editing it, so it can keep track. You can use cvs watch and cvs edit for that. I really wouldn't recommend it though. See also CVSREAD. > I want a systerm with a command to undo the edits. With CVS I delete > and update. Lame. cvs unedit > I'd prefer a system that knows how to use windiff or some other > decent gui to show diffs. tkcvs should work on all platforms. You may want to look at that. It also show graphical development line trees. > I've gradually become comfortable with textual diffs. > But I like gui diffs. Windiff is nice. Some people think it is old > and limited, but it is > much better than textual diffs. > > CVS handling of merges and conflicts is also very poor. Yes. No way to improve that, I'm afraid. 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 Sun Aug 29 17:05:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 29 Aug 2010 17:05:44 +0200 Subject: [M3devel] cm3cg running amok In-Reply-To: <4C7869C8.7050600@lcwb.coop> References: <20100827212906.qn26kwsy88scckkk@mail.elegosoft.com> <4C7869C8.7050600@lcwb.coop> Message-ID: <20100829170544.l9x4yvd5340g0gkg@mail.elegosoft.com> The Hudson job for package tests on AMD64_FREEBSD was actually using a cm3cg binary from 2010-06-04 due to a configuration mistake. It may well be that changes in the interface or tree construction since then caused the problem. Currently the test-all-pkgs job progresses well on my system. Olaf Quoting "Rodney M. Bates" : > The ticked #1147 I reported a couple of weeks ago would probably show > this symptom. > That was AMD64_LINUX. > > Hmm, I think I never got back to supplying the attachment .ms file to > reproduce. > I'll try to do that tomorrow. I need sleep now too. > > Olaf Wagner wrote: >> I was just able to kill this process before my system ran out of swap >> space: >> >> % ps -wwwlp 95345 >> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND >> 4012 95345 95159 0 44 0 16794772 3027680 swread DL ?? >> 0:22.91 >> /ad0e/home/hudson/workspace/cm3-current-test-all-pkgs-AMD64_FREEBSD/cm3/m3-sys/m3cc/AMD64_FREEBSD/cm3cg -mno-align-double -quiet -fno-reorder-blocks -funwind-tables -fPIC -m64 -gstabs+ RTHeapDebug.mc -o >> RTHeapDebug.ms >> >> It had already acquired more than 16 GB. >> >> Any ideas? >> >> 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 rcolebur at SCIRES.COM Sun Aug 29 19:19:28 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 29 Aug 2010 13:19:28 -0400 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com>, Message-ID: >I'd prefer a system that knows how to use windiff or some other decent gui to show diffs. >I've gradually become comfortable with textual diffs.> >But I like gui diffs. Windiff is nice. Some people think it is old and limited, but it is >much better than textual diffs. Jay, have you looked into WinMerge on Windows? I use WinMerge and TortoiseCVS with cm3. http://winmerge.org/ http://www.tortoisecvs.org/ Regards, Randy From hendrik at topoi.pooq.com Sun Aug 29 20:40:12 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 29 Aug 2010 14:40:12 -0400 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: <20100829184012.GA17077@topoi.pooq.com> On Sun, Aug 29, 2010 at 12:02:01PM +0000, Jay K wrote: > > ?> We're not a shop at all in the sense that you can buy anything from our shelves > > > "Shop" has a different meaning in this context. > English is wierd. > > > Roughly speaking "an X shop" is a "company that tends to use product X or products from company X, not necessarily to the exclusion of others" > "a Microsoft shop" > "a Java shop" > "a Unix shop" > "an Oracle shop" > "a .NET shop" > > > ?> And we don't really need more than CVS offers. > ? > > A few things bug me. > The number one is that there are no change lists, just multiple independent changes to independent files. monotone does this. > I want to be able to browse history as a list of changes, and click on them, not navigate to each file individually. One of the independent GUIs associated with monotone does this. > I would also like a system that keeps enough local state so that I can diff my local version against current > without going to the slow unreliable network. The network is indeed very slow and unreliable. monotone does this withoug using the unreliable network. > > > Perforce seems ideal in so many ways. Its command line interface is excellent. > Its gui is very good. > Its feature set is excellent. > Its branching support is excellent. > I don't know if it has good offline support though. > > > I think I would settle for SVN. > Though SVN has completely broken branching last I checked, and they acknowledged it. > SVN also has relatively large dependencies to build from source. > > > I would also like a system that doesn't drop files/directories all over the place. Just in the root of a checkout should > suffice and be ideal. CVS is awful here and I believe SVN is too. I don't know what you mean with files/directories all over the place. monotone does allow you to have mutiple workspaces (perhaps you are working on several bugs simultaneousle, on the same of different branches, without having more than one local copy of the entire repository. But I suspect this isn't what you mean with "all over the place". > > > Perforce maybe doesn't have the portability I'd like -- e.g. I don't see OpenBSD. > But that might be an ok compromise, if copying can be done, or if those platforms can be requested. > It seems they are extremely extremely portable but just don't bother to provide the binaries. > Through time they do have excellent platform coverage. > I'm sure we don't go for this, but I do recommend it wholeheartedly. monotone available for * Cygwin * Debian Linux * FreeBSD Ports * Mac OS X MacPorts * NetBSD pkgsrc * openSuSE Linux * Fedora Linux * Gentoo Linux and it's free and open source. So are quite a few other VCS's. We certainly don't want to be in the position the Linux kernel got into with bitkeeper. > I want a system that makes me do *something* before editing a file. > ? Run some command to acknowledge I'm editing it, so it can keep track. monotone can tell you what *has* been edited. Though it doesn't have a specific command that allows editing ... just what do you mean here? What do you really need? > I want a systerm with a command to undo the edits. With CVS I delete and update. Lame. I'm not sure what you mean here. > I want a system that quickly knows which files I have changed. > Perforce meets all these requirements. > > > When I'm lazy I do: > ? p4 edit ... > ? spend a while editing > ? p4 revert -a? to revert anything I didn't actually change > ? It is wasteful, but plenty fast. In monotone, you can just discard the entire workspace, create another. But you can also use the mtn revert ... command, where ... is a list od files and directories you specifically want to revert. There's also a command to remove the last revision you committed to the repository, as long as you haven't sync'd with another copy of the repositiry (in that case it would just com back the next time you sync'd) Is that wnat you want? > > > I'd prefer a system that knows how to use windiff or some other decent gui to show diffs. > I've gradually become comfortable with textual diffs. > But I like gui diffs. Windiff is nice. Some people think it is old and limited, but it is > much better than textual diffs. > > > CVS handling of merges and conflicts is also very poor. > Monotone on my system deals with merge conflicts by using emacs merge mode. Is that what you're talking about? But it's possible to have multiple heads on a branch. But that's not why I use monotone in my own work. I chose it primarily because of its utter paranoia about data loss. It's primarily its internal self-checking that makes it slow to the extent that it still is slow. I like that. For example, it will *not* sync with a damaged repository, thereby limiting contagion. I've heard of occasional problems checing out extremely old versions from CVS. Single-bit errors can have long-lasting consequences. But converting CVS to monotone seems still to be a pain. Monotone's own cvs to monotone conversion campaign failed on my (it turns out incomplete) copy of the Modula 3 repository I made several months ago, failing on some kind of internal consistency check, thereby protecting the monotone repository it was building. I should try it again after I re-cvsup the whole repository. For all I know, it may be a problem with my missing CVSROOT. -- hendrik P.S. I don't know how other version control systems rate on these issues at present. I suspect several would rate as well. Input on this from people with actual experience would be very useful. -- hendrik > > ?- Jay > From hendrik at topoi.pooq.com Sun Aug 29 20:43:28 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 29 Aug 2010 14:43:28 -0400 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> References: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> Message-ID: <20100829184327.GB17077@topoi.pooq.com> On Sun, Aug 29, 2010 at 03:58:21PM +0200, Olaf Wagner wrote: > >> I would also like a system that doesn't drop files/directories all >> over the place. Just in the root of a checkout should >> suffice and be ideal. CVS is awful here and I believe SVN is too. > > The working copy overhaul expected to be included in SVN 1.7 will > keep all metadata at the root of the checkout in an SQL database. There's some mechanism in monotone to handle checkouts from one package in a subdirectory of a checkout of another package, possibly from another repository. I don't kno whow it works. Other than this, all the metadata is indeed kept in the _MTN subdirectory of the root directory of a workspace. -- hendrik From hosking at cs.purdue.edu Mon Aug 30 15:58:36 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Aug 2010 09:58:36 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100830070111.78809247400F@birch.elegosoft.com> Message-ID: <77612C42-A038-4D0D-A47D-F731DB3D825C@cs.purdue.edu> This code using NARROW in RecordType.m3 is unfortunate. Should you not implement the "declare" method for Field.T instead, and then invoke Value.Declare on it? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 30 Aug 2010, at 03:09, Jay K wrote: > > diff attached > > - Jay > > ---------------------------------------- >> Date: Mon, 30 Aug 2010 09:01:11 +0000 >> To: m3commit at elegosoft.com >> From: jkrell at elego.de >> Subject: [M3commit] CVS Update: cm3 >> >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/08/30 09:01:11 >> >> Modified files: >> cm3/m3-sys/m3front/src/values/: Field.i3 Field.m3 >> cm3/m3-sys/m3front/src/types/: Type.m3 RecordType.m3 >> cm3/m3-sys/m3front/src/builtinOps/: BitSize.m3 >> >> Log message: >> Pass more type information to backend. Hopefully it will use it. >> >> In particular, if you imported: >> >> TYPE Foo = RECORD a:INTEGER; END: >> >> and you also defined yourself unrelated: >> >> TYPE Bar = RECORD a:INTEGER; END; >> >> then the anonymous "RECORD a:INTEGER END;" >> >> would not be described to the backend. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Aug 30 22:46:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 30 Aug 2010 20:46:00 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <77612C42-A038-4D0D-A47D-F731DB3D825C@cs.purdue.edu> References: <20100830070111.78809247400F@birch.elegosoft.com> , <77612C42-A038-4D0D-A47D-F731DB3D825C@cs.purdue.edu> Message-ID: I'll look into that. My home network is down currently. There's still problems in this area, at least in the backend, probably not in the frontend at this point. - Jay Subject: Re: [M3commit] CVS Update: cm3 From: hosking at cs.purdue.edu Date: Mon, 30 Aug 2010 09:58:36 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu This code using NARROW in RecordType.m3 is unfortunate. Should you not implement the "declare" method for Field.T instead, and then invoke Value.Declare on it? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 30 Aug 2010, at 03:09, Jay K wrote: diff attached - Jay ---------------------------------------- Date: Mon, 30 Aug 2010 09:01:11 +0000 To: m3commit at elegosoft.com From: jkrell at elego.de Subject: [M3commit] CVS Update: cm3 CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/08/30 09:01:11 Modified files: cm3/m3-sys/m3front/src/values/: Field.i3 Field.m3 cm3/m3-sys/m3front/src/types/: Type.m3 RecordType.m3 cm3/m3-sys/m3front/src/builtinOps/: BitSize.m3 Log message: Pass more type information to backend. Hopefully it will use it. In particular, if you imported: TYPE Foo = RECORD a:INTEGER; END: and you also defined yourself unrelated: TYPE Bar = RECORD a:INTEGER; END; then the anonymous "RECORD a:INTEGER END;" would not be described to the backend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Aug 31 13:25:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 11:25:43 +0000 Subject: [M3devel] a trouble with passing records by value.. Message-ID: Given something like this: jbook2:p247 jay$ more 1.c #include typedef struct { long code; long value; } T1; void ActionLookup(T1 t, long code, long value); void ActionLookup(T1 t, long code, long value) { ? assert(t.code == code); ? assert(t.value == value); } int main() { ? T1 t1 = {2,2}; ? ActionLookup(t1, 2, 2); ? return 0; } j on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. Darn. If m3cg were higher level this could be better. There should be a viable compromise where the parameter is passed in registers, and only "homed" to some stack location if its address is used -- e.g. to pass unused parameters in registers. But given the inefficiency of field accesses, I'm not sure it is worth trying? Maybe we should have M3CG include field references? There is this basic problem that the interface between m3front and m3cc isn't really at the right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. ?- Jay From hosking at cs.purdue.edu Tue Aug 31 15:15:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Aug 2010 09:15:32 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: Message-ID: What happens if you take the address of t inside ActionLookup? What happens if you take the address of t1 inside main? On 31 Aug 2010, at 07:25, Jay K wrote: > > Given something like this: > > jbook2:p247 jay$ more 1.c > #include > > typedef struct { long code; long value; } T1; > > void ActionLookup(T1 t, long code, long value); > > void ActionLookup(T1 t, long code, long value) > { > assert(t.code == code); > assert(t.value == value); > } > > int main() > { > T1 t1 = {2,2}; > ActionLookup(t1, 2, 2); > return 0; > } > j > > > on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > > However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > Darn. > > > If m3cg were higher level this could be better. > > > There should be a viable compromise where the parameter is passed in registers, and only "homed" > to some stack location if its address is used -- e.g. to pass unused parameters in registers. > But given the inefficiency of field accesses, I'm not sure it is worth trying? > > > Maybe we should have M3CG include field references? > > > There is this basic problem that the interface between m3front and m3cc isn't really at the > right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > > - Jay >