From: joswig on
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
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
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
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
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!