From: joswig on 16 Mar 2010 07:26 On 16 Mrz., 11:43, Tim Bradshaw <t...(a)tfeb.org> wrote: > On 2010-03-16 10:08:57 +0000, Nicolas Neuss said: > > > When he grows older, he will learn that this is not a very clever thing > > to do, for it allows evil people to make all sorts of sneaky remarks > > about you without fear that you will answer them :-) > > It's kind of sad actually. In some earlier article he actually made a > point which was worth discussing (the one about macros, packages and > modules): there really is an issue there, which I think comes down > (from the CL perspective) to packages not being really first-class in > CL (packages can only exist in a registry), which means you can't use > them in a sufficiently lightweight way. > > Of course, CL people would argue that this is not a problem in > practice, and I think it generally is not: the existing heavyweight > namespace system, combined with CL being a Lisp 2, make it far less a > problem than it would be in Scheme. I tend to agree with it not being > a problem in practice, but I would also quite like to see a fix, and I > am wondering if making the package system more lightweight (in > particular allowing "uninterned" packages) would work (obviously it is > not a theoretically *pretty* fix, but I'm a CL person: I'm used to ugly > hacks). relative packages and logical packages
From: Tim Bradshaw on 16 Mar 2010 08:02 On 2010-03-16 11:26:27 +0000, joswig(a)corporate-world.lisp.de said: > relative packages and logical packages No, I want more than that: I want it to be the case that I can have packages which will be garbage collected when all the references to them are gone. I want a version of MAKE-PACKAGE which does not put the package in a registry.
From: Slobodan Blazeski on 16 Mar 2010 15:50 On Mar 14, 8:34 pm, Eli Barzilay <e...(a)barzilay.org> wrote: > Slobodan Blazeski <slobodan.blaze...(a)gmail.com> writes: > > On Mar 13, 11:27 pm, Eli Barzilay <e...(a)barzilay.org> wrote: > >> Hugh Aguilar <hughaguila...(a)yahoo.com> writes: > >> > On Mar 12, 6:33 pm, Helmut Eller <eller.hel...(a)gmail.com> wrote: > >> >> The text was "abcdefghijklmnopqrstuvwxyz". > > >> > This file is too short. > > >> (FWIW, I tried to have a quick and naive translation of the CL code to > >> PLT, and on a 64 bit machine with that input file it takes about 19 > >> seconds. > > Eli I've tried your code and it takes forever 8min 36 sec to run on my > > Machine(*). I've run the file from DrScheme IDE with both Dr Scheme > > 4.15 that was in the ubuntu repositories and now I've downloaded and > > installed 4.24 Linux - Fedora 7 (x86_64). The result is same over > > By default, DrScheme runs code in "debug mode", which means that it > inserts lots of code instrumentation bits into the code, and that will > make it run much faster. Usually the difference is neglegible, but of > course it is much more noticeable in code like this. To turn > debugging off, hit the "show details" and disable all debugging on the > top part. But even with this there is additional overhead for running > in DrScheme -- I see a runtime of 35 seconds. Running the code > directly in mzscheme should make sure that you don't get any of these > costs. > > Another strange thing is that your junk output looks very different > from my junk output... I've changed the code a bit (you can get it > from the same URL) to always use the "abc...xyz" string and print the > contents in ASCII-friendly form -- this is the output that I see: > > #"abcdefghijklmnopqrstuvwxyz" > > SAMPLE is encrypted and seed is zeroed; commencing cracking...cpu time: 19292 real time: 19295 gc time: 320 > > The seed is: 174187923 > The file is: > #"<B!q\25z\1oP\vDJgm\17I]m\vUXwD\31\34@" Thanks bobi(a)deus:~$ /home/bobi/lisp/plt/bin/mzscheme eli.scm #"abcdefghijklmnopqrstuvwxyz" SAMPLE is encrypted and seed is zeroed; commencing cracking...cpu time: 33540 real time: 33596 gc time: 670 The seed is: 174187923 The file is: #"<B!q\25z\1oP\vDJgm\17I]m\vUXwD\31\34@"
From: Eli Barzilay on 16 Mar 2010 16:33 Slobodan Blazeski <slobodan.blazeski(a)gmail.com> writes: > On Mar 14, 8:34 pm, Eli Barzilay <e...(a)barzilay.org> wrote: >> Slobodan Blazeski <slobodan.blaze...(a)gmail.com> writes: >> > On Mar 13, 11:27 pm, Eli Barzilay <e...(a)barzilay.org> wrote: >> >> Hugh Aguilar <hughaguila...(a)yahoo.com> writes: >> >> > On Mar 12, 6:33 pm, Helmut Eller <eller.hel...(a)gmail.com> wrote: >> >> >> The text was "abcdefghijklmnopqrstuvwxyz". >> >> >> > This file is too short. >> >> >> (FWIW, I tried to have a quick and naive translation of the CL code to >> >> PLT, and on a 64 bit machine with that input file it takes about 19 >> >> seconds. >> > Eli I've tried your code and it takes forever 8min 36 sec to run on my >> > Machine(*). I've run the file from DrScheme IDE with both Dr Scheme >> > 4.15 that was in the ubuntu repositories and now I've downloaded and >> > installed 4.24 Linux - Fedora 7 (x86_64). The result is same over >> >> By default, DrScheme runs code in "debug mode", which means that it >> inserts lots of code instrumentation bits into the code, and that will >> make it run much faster. Usually the difference is neglegible, but of >> course it is much more noticeable in code like this. To turn >> debugging off, hit the "show details" and disable all debugging on the >> top part. But even with this there is additional overhead for running >> in DrScheme -- I see a runtime of 35 seconds. Running the code >> directly in mzscheme should make sure that you don't get any of these >> costs. >> >> Another strange thing is that your junk output looks very different >> from my junk output... I've changed the code a bit (you can get it >> from the same URL) to always use the "abc...xyz" string and print the >> contents in ASCII-friendly form -- this is the output that I see: >> >> #"abcdefghijklmnopqrstuvwxyz" >> >> SAMPLE is encrypted and seed is zeroed; commencing cracking...cpu time: 19292 real time: 19295 gc time: 320 >> >> The seed is: 174187923 >> The file is: >> #"<B!q\25z\1oP\vDJgm\17I]m\vUXwD\31\34@" > Thanks > > bobi(a)deus:~$ /home/bobi/lisp/plt/bin/mzscheme eli.scm > #"abcdefghijklmnopqrstuvwxyz" > > SAMPLE is encrypted and seed is zeroed; commencing cracking...cpu > time: 33540 real time: 33596 gc time: 670 > > The seed is: 174187923 > The file is: > #"<B!q\25z\1oP\vDJgm\17I]m\vUXwD\31\34@" OK, so you have 33 seconds instead of 19 seconds. I'm not sure what would lead to such a difference (machine specs below), but it's not the 8.5 minutes that would indicate something very wrong. [The machine I'm using has two dual core Intel Xeon 5160 3GHz cpus, it was pretty fast when we got it ~2 years ago, and I assumed (perhaps falsly) that it's a representative of an average machine these days. Also, it has 4gb of ram, and the OS is Fedora 7 (it's the build machine for the x86_64 installer on our site).] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!
From: Eli Barzilay on 16 Mar 2010 16:34
Tim Bradshaw <tfb(a)tfeb.org> writes: > On 2010-03-15 20:59:13 +0000, Hugh Aguilar said: > >> I don't know what "subjective redundantism" is. I've never heard >> the term "plonk" either, but I suppose that it means he's going to >> go sulk. > > That's what he means. In particular he has a nice habit of posting > long articles and then announcing he will not read replies to them. > Someone not interested in discussing stuff, I guess. Just not in the how such threads on c.l.l usually degrade to -- I don't want to suffer being in the center of such a thread, and I don't want to make other people suffer from reading through such threads. (With apologies to those who do enjoy flames for the sake of flames...) Dealing with a basement->swimming-pool transformation makes avoiding it even more necessary. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! |