Re: Patch for tests/run-program.impure.lisp

> I merged the patch from Launchpad, but had to hack this a bit -- I
> don't see how this could work on Solaris either, because the sequence
> of calls to ASSERT-ED is
>
>       (assert-ed nil "4")
>       (assert-ed ".s/bar/baz/g" "")
>       (assert-ed "w" "4")
>       (assert-ed "q" "")
>
> -- not the second one, where an empty response is expected, followed
> by another one. On Darwin plugging in your patch results in third
> assertion failing since it gets #\newline from the stream before #\4
> #\newline.

Actually, s/bar/baz/g#\newline echoes back the characters and newline  
typed, but doesn't echo an additional newline, so I'm not sure why the  
new version worked.  (I may be missing something obvious, though!)

But I definitely like the explicit nil for no response expected better.

In any case, both versions work on SunOS.  I can start testing these  
on Darwin as well when I get a chance.

Thanks again for merging these!

--
				Jim Wise
				jwise <at> draga.com

Re: Patch for tests/run-program.impure.lisp

On 31 August 2010 18:07, Jim Wise <jwise <at> draga.com> wrote:
> Index: tests/run-program.impure.lisp
> ===================================================================
> RCS file: /cvsroot/sbcl/sbcl/tests/run-program.impure.lisp,v
> retrieving revision 1.13
> diff -p -u -u -w -r1.13 run-program.impure.lisp
> --- tests/run-program.impure.lisp       20 May 2010 22:09:39 -0000      1.13
> +++ tests/run-program.impure.lisp       31 Aug 2010 14:59:02 -0000
>  <at>  <at>  -91,9 +91,10  <at>  <at> 
>   (when command
>     (write-line command *ed-in*)
>     (force-output *ed-in*))
> +  (unless (string= response "")
>   (let ((got (read-linish *ed-out*)))
>     (unless (equal response got)
> -      (error "wanted ~S from ed, got ~S" response got)))
> +       (error "wanted ~S from ed, got ~S" response got))))
>   *ed*)

I merged the patch from Launchpad, but had to hack this a bit -- I
don't see how this could work on Solaris either, because the sequence
of calls to ASSERT-ED is

       (assert-ed nil "4")
       (assert-ed ".s/bar/baz/g" "")
       (assert-ed "w" "4")
       (assert-ed "q" "")

-- not the second one, where an empty response is expected, followed
by another one. On Darwin plugging in your patch results in third

Re: Patch for tests/run-program.impure.lisp

On Sep 1, 2010, at 2:20 PM, Jim Wise wrote:

> Actually, s/bar/baz/g#\newline echoes back the characters and  
> newline typed, but doesn't echo an additional newline, so I'm not  
> sure why the new version worked.  (I may be missing something  
> obvious, though!)
>
> But I definitely like the explicit nil for no response expected  
> better.
>
> In any case, both versions work on SunOS.  I can start testing these  
> on Darwin as well when I get a chance.
>
> Thanks again for merging these!

Actually, I spoke too soon -- your new version is also hanging  
indefinitely on Solaris, but changing this:

	(assert-ed ".s/bar/baz/g" "")

to this

        (assert-ed ".s/bar/baz/g" nil)

fixes the problem.  Again, this happens because there is no output  
*from ed* for either the s/// or q commands -- and read-linish doesn't  
see the echo of the input sent to the pty.

This version should work on Darwin as well -- I'll test this later,  

Re: sb-pcl:fast-method's in the slime backtrace

So, I decided to try to tackle this. As I've said before, I don't want
to push the responsibility for frame cleaning to Slime -- setting
options yes, but actually doing the cleaning should be done by SBCL.

Without getting into implementation details right now, here's my
proposal for a brave new SB-DEBUG:BACKTRACE interface. I think
FRAME-CALL-AS-LIST and PRINT-FRAME-CALL should have similar toggles.

(defun backtrace (&key
                  (stream *debug-io*)
                  (count *backtrace-frame-count*)
                  (skip 0)
                  (print-thread t)
                  (print-frame-source nil)
                  (method-frame-style *method-frame-style*)
                  (show-entry-point-details *show-entry-point-details*))
  "Print a listing of the call stack to STREAM, going down from the current
frame. In the debugger, the current frame is indicated by the prompt.

COUNT is the number of frames to print (defaulting to *BACKTRACE-FRAME-COUNT*,
initially MOST-POSITIVE-FIXNUM), and SKIP is the number of frames to skip
before starting to print (defaulting to zero).

If PRINT-THREAD is true (the default), the backtrace is preceded by printing
the current thread object.

If PRINT-FRAME-SOURCE is true (the default is false), each frame is followed
by printing the source responsible for it, when available.

METHOD-FRAME-STYLE (defaulting to *METHOD-FRAME-STYLE*, initially :NORMAL),

Stupid git scripts

Hello all,

(Is that subject line really as stupid as it sounds?)

Attached should be a copy of the shell script that I currently use for
committing a sequence of changes from git to CVS.  It is undoubtedly a
bit of a hack, as my shellscript-fu is not particularly strong, but I
spent some time over the past couple of days adding documentation,
removing dependencies, et cetera, including making notes on what I
think could be improved.  For the record, this is an improved version
of the script that I used to commit the PPC threading changes.

I am offering this script in the hope that it might be of use to
someone (either as-is or as a starting point) and as an opening to ask
the question, "does anyone else have any little scripts they use to
make SBCL development easier?"

Having trouble thinking of a good closing,

-- Alastair Bridgewater

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

Sorting algorithms

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: Sorting algorithms

Gustavo <gugamilare <at> gmail.com> writes:

> According to tests I've run in my machine, STABLE-SORT is actually
> faster than SORT. The reason seems to be that STABLE-SORT uses merge
> sort and SORT uses heapsort. The problem with heapsort (according to
> wikipedia) is that it does not access the elements of the array in
> sequential order, so merge sort plays better with modern computer.
>
> I've run various tests with randomly-generated vectors, the code is
> in the (hackish) file sort.lisp attached and the output is in
> sort.log. The only tests where SORT is faster as STABLE-SORT is when
> all elements of the vector were the same. In other tests,
> STABLE-SORT is a lot faster than SORT (often twice as fast).
>
> Of course, this is just in my system, but, if STABLE-SORT is faster
> than SORT, it makes more sense to always use STABLE-SORT and comment
> away SORT's code.

Yes, and bubble sort is faster when the vector is already sorted.

> My system is an Athlon 64 X2 4200+ with 2GiB of DDR2 800MHZ RAM.
>
> As part of a project in a discipline at college, I intend to write
> some sorting algorithms and compare them performance-wise in various
> cases, specially merge sort, heapsort, introsort and a modification
> of quicksort with a selection algorithm (which is also O(n *
> log(n)). Unless someone has an objection, I can port the "winner" to
> SBCL after verifying it is better than current algorithms in SBCL.

The problem is that it would have to be better on all the target,
whatever the processor, cache architecture and memory size, and
whatever the size of the sequence being sorted, and its amount of
"unsortedness".

The point is that there won't be a unique best algorithm.

For a generic library sort such as CL:SORT and CL:STABLE-SORT,
selecting an algorithm that's good enough in general is all that is
needed.

Then you could provide all the other algorithms, well optimized, in a
library, to let the application developers needing a little speed, to
choose a sorting algorithm better adapted to his circumstances,
processor and data.

--

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

Re: Sorting algorithms

2010/9/3 Gustavo <gugamilare <at> gmail.com>:

> According to tests I've run in my machine, STABLE-SORT is actually faster
> than SORT. The reason seems to be that STABLE-SORT uses merge sort and SORT
> uses heapsort. The problem with heapsort (according to wikipedia) is that it
> does not access the elements of the array in sequential order, so merge sort
> plays better with modern computer.

Good catch! Will need to check if this holds true across other
architectures, but if so, either giving SORT some extra love or using
mergesort for both is in order.

> with a selection algorithm (which is also O(n * log(n)). Unless someone has
> an objection, I can port the "winner" to SBCL after verifying it is better
> than current algorithms in SBCL.

Improvements are always welcome.

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: Sorting algorithms

Hello Gustavo,

> As part of a project in a discipline at college, I intend to write some
> sorting algorithms and compare them performance-wise in various cases,
> specially merge sort, heapsort,
> introsort<http://en.wikipedia.org/wiki/Introsort>and a modification of
> quicksort with a selection algorithm (which is also
> O(n * log(n)).
Some years ago I read about a cache-conscious dynamic burst trie sort;
it might have been crpit.com/confpapers/CRPITV62Askitis.pdf, but I'm
not entirely sure.

Maybe that would be interesting to you, too.

> Unless someone has an objection, I can port the "winner" to
> SBCL after verifying it is better than current algorithms in SBCL.
If you could provide any you write as libraries, that would be very fine!

Regards,

Phil

--

-- 
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd

Re: Stupid git scripts

So, there turns out to be a bug in this version of the script,
introduced during dependency reduction.

Line 68, which says "local old_version=`grep ^\" version.lisp-expr`"
should say $CVS_DIR/version.lisp-expr instead of just
version.lisp-expr, hence my thrashing about with a botched commit last
night (AFAIR, my first such botch, and hopefully also my last).

--Alastair Bridgewater

On Thu, Sep 2, 2010 at 8:48 PM, Alastair Bridgewater
<alastair.bridgewater <at> gmail.com> wrote:
> Hello all,
>
> (Is that subject line really as stupid as it sounds?)
>
> Attached should be a copy of the shell script that I currently use for
> committing a sequence of changes from git to CVS.  It is undoubtedly a
> bit of a hack, as my shellscript-fu is not particularly strong, but I
> spent some time over the past couple of days adding documentation,
> removing dependencies, et cetera, including making notes on what I
> think could be improved.  For the record, this is an improved version
> of the script that I used to commit the PPC threading changes.
>
> I am offering this script in the hope that it might be of use to
> someone (either as-is or as a starting point) and as an opening to ask
> the question, "does anyone else have any little scripts they use to
> make SBCL development easier?"
>
> Having trouble thinking of a good closing,
>
> -- Alastair Bridgewater
>

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd