From graemec at mysoul.com.au Mon Oct 30 08:22:42 2006 From: graemec at mysoul.com.au (RGC) Date: Mon Oct 30 08:24:56 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? Message-ID: <4545FCA2.30306@mysoul.com.au> Hi folks, I've just recently tried to implement the Universal Machine and am having some difficulty. I thought I might try to get a few hints here. The resulting codex.umz file, when run under my executable and given the command 'p' to dump, gives, it seems, 15,924,056 bytes to standard output (redirected to a file). A small program I wrote strips off the leading unwanted stuff, and leaves a 15,923,864 byte file, which I've tried to run under my UM. It shows a UMIX login screen, suggesting that there's a 'guest' account for visitor access, but when I try to log in as guest I get nothing more but echoes of my keystrokes. CPU utilisation after that is near zero, so it's not busy doing anything. Any idea what the problem is? Is it just that there's some as yet unfound bug in my UM implementation, or am I missing something else? Regards, Graeme. From nnunley at gmail.com Mon Oct 30 08:42:27 2006 From: nnunley at gmail.com (Norman Nunley, Jr) Date: Mon Oct 30 08:42:34 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <4545FCA2.30306@mysoul.com.au> References: <4545FCA2.30306@mysoul.com.au> Message-ID: <12742ED3-CBD5-4E7E-82EE-E5F654B2567A@gmail.com> Hi Graeme, If there's no cpu utilization, then you've probably hit an edge case with your VM implementation. Have you run the sandmark.umz on it? It provides a rather thorough set of tests against the VM, which would be more likely to demonstrate the bug that you're currently encountering. Norman On 30 Oct 2006, at 13:22, RGC wrote: > Hi folks, > > I've just recently tried to implement the Universal Machine and am > having some difficulty. I thought I might try to get a few hints > here. > > The resulting codex.umz file, when run under my executable and given > the command 'p' to dump, gives, it seems, 15,924,056 bytes to standard > output (redirected to a file). A small program I wrote strips off the > leading unwanted stuff, and leaves a 15,923,864 byte file, which I've > tried to run under my UM. > > It shows a UMIX login screen, suggesting that there's a 'guest' > account for visitor access, but when I try to log in as guest I get > nothing more but echoes of my keystrokes. CPU utilisation after > that is near zero, so it's not busy doing anything. > > Any idea what the problem is? > > Is it just that there's some as yet unfound bug in my UM > implementation, or am I missing something else? > > > Regards, Graeme. > > _______________________________________________ > icfpcontest-discuss mailing list > icfpcontest-discuss@lists.andrew.cmu.edu > https://lists.andrew.cmu.edu/mailman/listinfo/icfpcontest-discuss From triska at gmx.at Mon Oct 30 08:56:25 2006 From: triska at gmx.at (Markus Triska) Date: Mon Oct 30 08:48:44 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <4545FCA2.30306@mysoul.com.au> References: <4545FCA2.30306@mysoul.com.au> Message-ID: <17734.1161.913400.506398@localhost.localdomain> RGC writes: > leading unwanted stuff, and leaves a 15,923,864 byte file, which I've > tried to run under my UM. For us, the first version resulted in file with 15,901,931 bytes, and the updated version (which I assume you are using) yielded a file with 15,923,875 bytes during the contest. First few lines of "hd" output: 00000000 d0 00 10 8d c0 00 00 30 00 00 00 00 00 00 00 00 |.......0........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000230 00 00 00 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 |................| 00000240 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 |................| tail is: 00f2fa80 20 00 01 b8 d0 00 00 91 10 00 00 30 de 00 00 8e | ..........0....| 00f2fa90 20 00 01 b8 c0 00 00 34 68 61 6c 74 69 6e 67 2e | ......4halting.| 00f2faa0 2e 2e 0a |...| 00f2faa3 Best wishes! Markus Triska From windenntw at gmail.com Mon Oct 30 09:03:05 2006 From: windenntw at gmail.com (Antonio Vargas) Date: Mon Oct 30 09:03:08 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <17734.1161.913400.506398@localhost.localdomain> References: <4545FCA2.30306@mysoul.com.au> <17734.1161.913400.506398@localhost.localdomain> Message-ID: <69304d110610300603i6a99b858r95ae3076b7fc928@mail.gmail.com> On 10/30/06, Markus Triska wrote: > RGC writes: > > > leading unwanted stuff, and leaves a 15,923,864 byte file, which I've > > tried to run under my UM. > > For us, the first version resulted in file with 15,901,931 bytes, and > the updated version (which I assume you are using) yielded a file with > 15,923,875 bytes during the contest. First few lines of "hd" output: > > 00000000 d0 00 10 8d c0 00 00 30 00 00 00 00 00 00 00 00 |.......0........| > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > * > 00000230 00 00 00 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 |................| > 00000240 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 |................| > > tail is: > > 00f2fa80 20 00 01 b8 d0 00 00 91 10 00 00 30 de 00 00 8e | ..........0....| > 00f2fa90 20 00 01 b8 c0 00 00 34 68 61 6c 74 69 6e 67 2e | ......4halting.| > 00f2faa0 2e 2e 0a |...| > 00f2faa3 > > Best wishes! > Markus Triska > _______________________________________________ > icfpcontest-discuss mailing list > icfpcontest-discuss@lists.andrew.cmu.edu > https://lists.andrew.cmu.edu/mailman/listinfo/icfpcontest-discuss > I'm copying you a mail sent while the competition days... but I recall maybe the generated file depended on the key you got first on mail? --- this is what i got after removing the headers "...delete all before..." from the output of the codex: $ md5 umix.umz MD5 (umix.umz) = f7c83a04997316fd25c14382876419fb $ ls -l umix.umz -rw-r--r-- 1 xxxxxxxxx xxxxxxxxxx 15923865 23 Jul 13:39 umix.umz $ --- -- Greetz, Antonio Vargas aka winden of network http://network.amigascne.org/ windNOenSPAMntw@gmail.com thesameasabove@amigascne.org Every day, every year you have to work you have to study you have to scene. From dklein at dmk.dyndns.org Mon Oct 30 09:24:38 2006 From: dklein at dmk.dyndns.org (Daniel M. Klein) Date: Mon Oct 30 09:22:49 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <69304d110610300603i6a99b858r95ae3076b7fc928@mail.gmail.com> References: <4545FCA2.30306@mysoul.com.au> <17734.1161.913400.506398@localhost.localdomain> <69304d110610300603i6a99b858r95ae3076b7fc928@mail.gmail.com> Message-ID: <45460B26.9000408@dmk.dyndns.org> From the official announce list, http://lists.andrew.cmu.edu/pipermail/icfpcontest-announce/Week-of-Mon-20060717/000007.html "The size of the decompressed UM binary is 15923864 bytes" Regards, DMK Antonio Vargas wrote: > On 10/30/06, Markus Triska wrote: >> RGC writes: >> >> > leading unwanted stuff, and leaves a 15,923,864 byte file, which I've >> > tried to run under my UM. >> >> For us, the first version resulted in file with 15,901,931 bytes, and >> the updated version (which I assume you are using) yielded a file with >> 15,923,875 bytes during the contest. First few lines of "hd" output: >> >> 00000000 d0 00 10 8d c0 00 00 30 00 00 00 00 00 00 00 00 >> |.......0........| >> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> |................| >> * >> 00000230 00 00 00 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 >> |................| >> 00000240 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 >> |................| >> >> tail is: >> >> 00f2fa80 20 00 01 b8 d0 00 00 91 10 00 00 30 de 00 00 8e | >> ..........0....| >> 00f2fa90 20 00 01 b8 c0 00 00 34 68 61 6c 74 69 6e 67 2e | >> ......4halting.| >> 00f2faa0 2e 2e 0a |...| >> 00f2faa3 >> >> Best wishes! >> Markus Triska >> _______________________________________________ >> icfpcontest-discuss mailing list >> icfpcontest-discuss@lists.andrew.cmu.edu >> https://lists.andrew.cmu.edu/mailman/listinfo/icfpcontest-discuss >> > > I'm copying you a mail sent while the competition days... but I recall > maybe the generated file depended on the key you got first on mail? > > --- > > this is what i got after removing the headers "...delete all > before..." from the output of the codex: > > $ md5 umix.umz > MD5 (umix.umz) = f7c83a04997316fd25c14382876419fb > $ ls -l umix.umz > -rw-r--r-- 1 xxxxxxxxx xxxxxxxxxx 15923865 23 Jul 13:39 umix.umz > $ > > --- > From graemec at mysoul.com.au Mon Oct 30 09:43:05 2006 From: graemec at mysoul.com.au (RGC) Date: Mon Oct 30 09:43:21 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <12742ED3-CBD5-4E7E-82EE-E5F654B2567A@gmail.com> References: <4545FCA2.30306@mysoul.com.au> <12742ED3-CBD5-4E7E-82EE-E5F654B2567A@gmail.com> Message-ID: <45460F79.80408@mysoul.com.au> Norman Nunley, Jr wrote: > Hi Graeme, > > If there's no cpu utilization, then you've probably hit an edge case > with your VM implementation. > Have you run the sandmark.umz on it? It provides a rather thorough set > of tests against > the VM, which would be more likely to demonstrate the bug that you're > currently encountering. > > Norman Thanks for the reply, Norman. I forgot to mention that I had already got the thing to successfully pass the sandmark test. I have since added checks to the UM emulator to check for most of the error conditions mentioned at the end of the specification docs, so I'll check again that what I'm currently using still passes sandmark. I'm not hopeful of finding pathological behavior there, though. Regards, Graeme. From graemec at mysoul.com.au Mon Oct 30 09:49:03 2006 From: graemec at mysoul.com.au (RGC) Date: Mon Oct 30 09:49:10 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <17734.1161.913400.506398@localhost.localdomain> References: <4545FCA2.30306@mysoul.com.au> <17734.1161.913400.506398@localhost.localdomain> Message-ID: <454610DF.7070007@mysoul.com.au> Markus Triska wrote: > RGC writes: > > >> leading unwanted stuff, and leaves a 15,923,864 byte file, which I've >> tried to run under my UM. >> > > For us, the first version resulted in file with 15,901,931 bytes, and > the updated version (which I assume you are using) yielded a file with > 15,923,875 bytes during the contest. First few lines of "hd" output: > > 00000000 d0 00 10 8d c0 00 00 30 00 00 00 00 00 00 00 00 |.......0........| > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > * > 00000230 00 00 00 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 |................| > 00000240 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 |................| > That's what I find at the start too. > tail is: > > 00f2fa80 20 00 01 b8 d0 00 00 91 10 00 00 30 de 00 00 8e | ..........0....| > 00f2fa90 20 00 01 b8 c0 00 00 34 68 61 6c 74 69 6e 67 2e | ......4halting.| > 00f2faa0 2e 2e 0a |...| > 00f2faa3 > I'm finding something similar, except that it's truncated. My last byte is at 0x00f2fa97. Curious. Unfortunately, that's not the extent of the problem, because grafting on the extra bytes from your file doesn't solve it. Regards, Graeme. From kurt.rinnert at cern.ch Mon Oct 30 09:49:39 2006 From: kurt.rinnert at cern.ch (Kurt Rinnert) Date: Mon Oct 30 09:49:51 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <45460F79.80408@mysoul.com.au> References: <4545FCA2.30306@mysoul.com.au> <12742ED3-CBD5-4E7E-82EE-E5F654B2567A@gmail.com> <45460F79.80408@mysoul.com.au> Message-ID: <20061030144939.GA2049@hep55.ph.liv.ac.uk> Hi Graeme, maybe it's just your console I/O? Sandmark does not test console input. And your original post sounded like your UM does respond to your input... cheers, Kurt On Tue, Oct 31, 2006 at 12:43:05AM +1000, RGC wrote: > Norman Nunley, Jr wrote: > >Hi Graeme, > > > >If there's no cpu utilization, then you've probably hit an edge case > >with your VM implementation. > >Have you run the sandmark.umz on it? It provides a rather thorough set > >of tests against > >the VM, which would be more likely to demonstrate the bug that you're > >currently encountering. > > > >Norman > > Thanks for the reply, Norman. > > I forgot to mention that I had already got the thing to successfully pass > the sandmark test. > > I have since added checks to the UM emulator to check for most of > the error conditions mentioned at the end of the specification docs, > so I'll check again that what I'm currently using still passes sandmark. > > I'm not hopeful of finding pathological behavior there, though. > > > Regards, Graeme. > > _______________________________________________ > icfpcontest-discuss mailing list > icfpcontest-discuss@lists.andrew.cmu.edu > https://lists.andrew.cmu.edu/mailman/listinfo/icfpcontest-discuss -- Kurt Rinnert, University of Liverpool - Department of Physics From dklein at dmk.dyndns.org Mon Oct 30 10:06:26 2006 From: dklein at dmk.dyndns.org (Daniel M. Klein) Date: Mon Oct 30 10:04:37 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <20061030144939.GA2049@hep55.ph.liv.ac.uk> References: <4545FCA2.30306@mysoul.com.au> <12742ED3-CBD5-4E7E-82EE-E5F654B2567A@gmail.com> <45460F79.80408@mysoul.com.au> <20061030144939.GA2049@hep55.ph.liv.ac.uk> Message-ID: <454614F2.3030504@dmk.dyndns.org> Console IO is definitely a 'gotcha' on this problem; I was hit with something similar. -- DMK Kurt Rinnert wrote: > Hi Graeme, > > maybe it's just your console I/O? Sandmark does not test console input. > And your original post sounded like your UM does respond to your > input... > > cheers, > > Kurt > > On Tue, Oct 31, 2006 at 12:43:05AM +1000, RGC wrote: > >> Norman Nunley, Jr wrote: >> >>> Hi Graeme, >>> >>> If there's no cpu utilization, then you've probably hit an edge case >>> with your VM implementation. >>> Have you run the sandmark.umz on it? It provides a rather thorough set >>> of tests against >>> the VM, which would be more likely to demonstrate the bug that you're >>> currently encountering. >>> >>> Norman >>> >> Thanks for the reply, Norman. >> >> I forgot to mention that I had already got the thing to successfully pass >> the sandmark test. >> >> I have since added checks to the UM emulator to check for most of >> the error conditions mentioned at the end of the specification docs, >> so I'll check again that what I'm currently using still passes sandmark. >> >> I'm not hopeful of finding pathological behavior there, though. >> >> >> Regards, Graeme. >> >> _______________________________________________ >> icfpcontest-discuss mailing list >> icfpcontest-discuss@lists.andrew.cmu.edu >> https://lists.andrew.cmu.edu/mailman/listinfo/icfpcontest-discuss >> > > From graemec at mysoul.com.au Mon Oct 30 10:07:03 2006 From: graemec at mysoul.com.au (RGC) Date: Mon Oct 30 10:07:54 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <69304d110610300603i6a99b858r95ae3076b7fc928@mail.gmail.com> References: <4545FCA2.30306@mysoul.com.au> <17734.1161.913400.506398@localhost.localdomain> <69304d110610300603i6a99b858r95ae3076b7fc928@mail.gmail.com> Message-ID: <45461517.1090502@mysoul.com.au> Antonio Vargas wrote: > I'm copying you a mail sent while the competition days... but I recall > maybe the generated file depended on the key you got first on mail? > > --- > > this is what i got after removing the headers "...delete all > before..." from the output of the codex: > > $ md5 umix.umz > MD5 (umix.umz) = f7c83a04997316fd25c14382876419fb > $ ls -l umix.umz > -rw-r--r-- 1 xxxxxxxxx xxxxxxxxxx 15923865 23 Jul 13:39 umix.umz > $ > > --- Thanks for the reply, Antonio. I've been informed that there are at least 2 versions of the codex, but I hadn't come across one that expanded to 15,923,865 bytes. I thought that the expanded codex probably ought to have a .um extension rather than .umz, but the UM knows nothing of that, so it can't matter. Regards, Graeme. From graemec at mysoul.com.au Mon Oct 30 10:13:04 2006 From: graemec at mysoul.com.au (RGC) Date: Mon Oct 30 10:13:12 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <45460B26.9000408@dmk.dyndns.org> References: <4545FCA2.30306@mysoul.com.au> <17734.1161.913400.506398@localhost.localdomain> <69304d110610300603i6a99b858r95ae3076b7fc928@mail.gmail.com> <45460B26.9000408@dmk.dyndns.org> Message-ID: <45461680.9000008@mysoul.com.au> Daniel M. Klein wrote: > From the official announce list, > > http://lists.andrew.cmu.edu/pipermail/icfpcontest-announce/Week-of-Mon-20060717/000007.html > > > "The size of the decompressed UM binary is 15923864 bytes" > > > Regards, > > DMK > Thanks, Kurt. So at least I've got a file of the correct length. Any other pearls of wisdom to cast my way? Maybe I should look into the announce list archives. Regards, Graeme. From ccasingh at andrew.cmu.edu Mon Oct 30 10:31:34 2006 From: ccasingh at andrew.cmu.edu (Big Chris) Date: Mon Oct 30 10:31:36 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <4545FCA2.30306@mysoul.com.au> References: <4545FCA2.30306@mysoul.com.au> Message-ID: Hi Graeme, As others have suggested, this is most likely a problem with your console input. In particular, we observed a number of people with this particular problem (no response after they typed guest and hit enter), and in almost all cases, the problem was that their UM implementation was stripping off the newline at the end of their input. This is a fairly easy mistake to make with most string manipulation tools. Hope this helps! --Chris Casinghino On Mon, 30 Oct 2006, RGC wrote: > Hi folks, > > I've just recently tried to implement the Universal Machine and am > having some difficulty. I thought I might try to get a few hints here. > > The resulting codex.umz file, when run under my executable and given > the command 'p' to dump, gives, it seems, 15,924,056 bytes to standard > output (redirected to a file). A small program I wrote strips off the > leading unwanted stuff, and leaves a 15,923,864 byte file, which I've > tried to run under my UM. > > It shows a UMIX login screen, suggesting that there's a 'guest' > account for visitor access, but when I try to log in as guest I get > nothing more but echoes of my keystrokes. CPU utilisation after > that is near zero, so it's not busy doing anything. > > Any idea what the problem is? > > Is it just that there's some as yet unfound bug in my UM > implementation, or am I missing something else? > > > Regards, Graeme. > > _______________________________________________ > icfpcontest-discuss mailing list > icfpcontest-discuss@lists.andrew.cmu.edu > https://lists.andrew.cmu.edu/mailman/listinfo/icfpcontest-discuss > > From graemec at mysoul.com.au Mon Oct 30 11:00:02 2006 From: graemec at mysoul.com.au (RGC) Date: Mon Oct 30 11:00:12 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: <20061030144939.GA2049@hep55.ph.liv.ac.uk> References: <4545FCA2.30306@mysoul.com.au> <12742ED3-CBD5-4E7E-82EE-E5F654B2567A@gmail.com> <45460F79.80408@mysoul.com.au> <20061030144939.GA2049@hep55.ph.liv.ac.uk> Message-ID: <45462182.1090107@mysoul.com.au> Kurt Rinnert wrote: > Hi Graeme, > > maybe it's just your console I/O? Sandmark does not test console input. > And your original post sounded like your UM does respond to your > input... > > cheers, > > Kurt > Thanks, Kurt, but I think I can rule that out. It _seems_ to decompress the codex okay, and that requires console input. I'm missing something. And it seems someone thinks it's fun to crack my systems and reset the smtp port to 0 on them. Regards, Graeme. From graemec at mysoul.com.au Mon Oct 30 11:33:39 2006 From: graemec at mysoul.com.au (RGC) Date: Mon Oct 30 11:33:52 2006 Subject: [icfp-discuss] Bad UM implementation or something else I'm missing? In-Reply-To: References: <4545FCA2.30306@mysoul.com.au> Message-ID: <45462963.6090008@mysoul.com.au> To Big Chris and Daniel, and especially to Kurt: It was indeed a problem with console input. The newline was getting lost. I'm now past the login and I have mail. :-) Thanks to all those who replied. Regards, Graeme.