James M. Lawrence | 25 Jul 17:51 2014
Picon

[PATCH] Fix default ARRAY-INDEX and ARRAY-LENGTH.

ARRAY-DIMENSION-LIMIT is an exclusive upper bound.
---
 types.lisp |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/types.lisp b/types.lisp
index 6aa722f..1942d0e 100644
--- a/types.lisp
+++ b/types.lisp
 <at>  <at>  -1,14 +1,14  <at>  <at> 
 (in-package :alexandria)

-(deftype array-index (&optional (length array-dimension-limit))
+(deftype array-index (&optional (length (1- array-dimension-limit)))
   "Type designator for an index into array of LENGTH: an integer between
-0 (inclusive) and LENGTH (exclusive). LENGTH defaults to
+0 (inclusive) and LENGTH (exclusive). LENGTH defaults to one less than
 ARRAY-DIMENSION-LIMIT."
   `(integer 0 (,length)))

-(deftype array-length (&optional (length array-dimension-limit))
+(deftype array-length (&optional (length (1- array-dimension-limit)))
   "Type designator for a dimension of an array of LENGTH: an integer between
-0 (inclusive) and LENGTH (inclusive). LENGTH defaults to
+0 (inclusive) and LENGTH (inclusive). LENGTH defaults to one less than
 ARRAY-DIMENSION-LIMIT."
   `(integer 0 ,length))

--

-- 
1.7.9.5
(Continue reading)

Jan Moringen | 11 May 22:58 2014
Picon
Picon

BISECT-BIG in %MULTIPLY-RANGE is never called

Hi,

out of curiosity, I tried

  (alexandria:binomial-coefficient 2000000000000 20)

on a x86 machine (in SBCL between 1.1.18 and master with debug = 3,
safety = 3 compiler policy) which resulted in the below session.

Looking at %MULTIPLY-RANGE, I noticed that BISECT-BIG was never called.
Calling BISECT-BIG when at least one argument is not a fixnum fixes the
problem. The attached patch does that and adds a test case to the test
suite.

Kind regards,
Jan

CL-USER(5): (alexandria:binomial-coefficient 2000000000000 20)

debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {B4748E9}>:
  The value 1999999999981 is not of type (INTEGER 1 536870911).

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(ALEXANDRIA.0.DEV::%MULTIPLY-RANGE 1999999999981 2000000000000)
; file: /home/jmoringe/code/cl/alexandria/numbers.lisp
(Continue reading)

James M. Lawrence | 27 Feb 03:10 2013
Picon

Re: Implementation of DELETE-FROM-PLIST

Apologies to Robert for stealing his thunder.
_______________________________________________
alexandria-devel mailing list
alexandria-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel
Robert Smith | 25 Feb 00:11 2013

Re: Implementation of DELETE-FROM-PLIST

Looks good! Much cleaner/better.

-Robert

On Sun, Feb 24, 2013 at 6:30 AM, James M. Lawrence <llmjjmll <at> gmail.com> wrote:
> On Sat, Feb 23, 2013 at 4:09 AM, Robert Smith <quad <at> symbo1ics.com> wrote:
>>
>> (defun delete-from-plist (plist &rest keys)
>>   "Delete all keys and pairs indicated by KEYS from the plist PLIST."
>>   (labels ((assert-proper-plist (x)
>>              (assert x () "Expected a proper plist, got ~S" plist))
>>            (bad-key-p (key)
>>              (member key keys :test #'eq))
>>            (find-first ()
>>              "Find the first cons in PLIST to keep."
>>              (loop :for the-cons :on plist :by #'cddr
>>                    :unless (prog1 (bad-key-p (car the-cons))
>>                              (assert-proper-plist (cdr the-cons)))
>>                      :do (return the-cons)
>>                    :finally (return nil))))
>>     (declare (inline assert-proper-plist
>>                      bad-key-p
>>                      find-first))
>>     ;; Find the first good key and delete any bad key-value pairs
>>     ;; between it and the start.
>>     (let ((first (find-first)))
>>       (unless (eq first plist)
>>         (setf (cddr plist)
>>               first))
>>
(Continue reading)

Zach Beane | 24 Feb 16:56 2013

Re: Implementation of DELETE-FROM-PLIST

"James M. Lawrence" <llmjjmll <at> gmail.com> writes:

> Using two loops seems awkward to me. How about one?
>
> (defun delete-from-plist (plist &rest keys)
>   (loop with head = plist
>         with tail = nil
>         for (key . rest) on plist by #'cddr
>         do (assert rest () "Expected a proper plist, got ~S" plist)
>            (if (member key keys :test #'eq)
>                (let ((next (cdr rest)))
>                  (if tail
>                      (setf (cdr tail) next)
>                      (setf head next)))
>                (setf tail rest))
>         finally (return head)))

I mention this for completeness and novelty, not for suitability:

  (defun sans (plist &rest keys)
    (let ((sans ()))
      (loop
        (let ((tail (nth-value 2 (get-properties plist keys))))
          ;; this is how it ends
          (unless tail
            (return (nreconc sans plist)))
          ;; copy all the unmatched keys
          (loop until (eq plist tail) do
                (push (pop plist) sans)
                (push (pop plist) sans))
(Continue reading)

Robert Smith | 23 Feb 10:09 2013

Implementation of DELETE-FROM-PLIST

Hey:

Here's a destructive/non-consing version of DELETE-FROM-PLIST. I've
tested with (I think) all corner cases from the REPL, but I ought to
write tests proper.

The function is here http://tinyurl.com/adqkssu ;or the following huge
link, in case the last one is invalidated
https://bitbucket.org/tarballs_are_good/lisp-random/src/3db634111d35e788c6ea2f4a1b3ab38334e24cde/miscellaneous_exercises/delete-from-plist.lisp?at=default#cl-30
.

For simplicity or ease of review from an email client, I've pasted the
function at the end of this email.

Additionally, this function would make it pretty easy to write
DELETE-FROM-PLIST-IF{-NOT}, since the function to determine if a key
is bad is factored out. If one did write this function, then it would
be easy to define DELETE-FROM-PLIST in terms of it.

Let me know if there are any changes that should be made.

Cheers,

Robert Smith

;;;; from delete-from-plist.lisp

(defun delete-from-plist (plist &rest keys)
  "Delete all keys and pairs indicated by KEYS from the plist PLIST."
  (labels ((assert-proper-plist (x)
(Continue reading)

Andy Peterson | 4 Feb 19:14 2013
Picon

Bug in gaussian-random

Hello,

Four months ago, I reported a bug in gaussian-random when either optional parameter min or max is nil but not both are nil. The docstring has been modified since then but the code is still the same and the bug remains. In such a situation it is possible to enter an infinite loop.

This is easy to demonstrate by the call (gaussian-random 0 nil). You may need to repeat the call a few times because the bug depends on the values returned by the first call to the local function gauss.  An infinite loop will occur if gauss returns a negative number. 

I have attached a patch which fixes the bug.

Sincerely,

Andy Peterson

Attachment (gaussian-random.patch): application/octet-stream, 3768 bytes
_______________________________________________
alexandria-devel mailing list
alexandria-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel
Faré | 26 Jan 17:47 2013
Picon

More open development

On Sat, Jan 26, 2013 at 9:14 AM, Nikodemus Siivola
<nikodemus <at> random-state.net> wrote:
> On 6 November 2012 07:26, Faré <fahree <at> gmail.com> wrote:
>
>> And/or I want another library in which utilities can be speedily updated.
>
> Speed of evolution is an explicit non-goal for Alexandria. Also,
> please don't hijack threads.
>
Maybe alexandria needs more people with commit rights?

Or else, maybe we need a different reference library that will have
a more open development style.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Government's view of the economy could be summed up in a few short phrases :
If it moves, tax it. If it keeps moving, regulate it. And if it stops
moving, subsidize it. — Ronald Reagan (1986)

_______________________________________________
alexandria-devel mailing list
alexandria-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel
Garrett Kolpin | 16 Jan 05:29 2013
Picon

flatten depth param

Hi,

I've found it useful to be able to specify a depth when flattening a list structure. The attached patch adds a :to-depth keyword parameter to the flatten function. For instance, 

(flatten '((a b) (c (d)) :to-depth 1) => (a b c (d))

Is this something that could be added?

Thanks,
-Garrett
Attachment (flatten-depth.patch): application/octet-stream, 2496 bytes
_______________________________________________
alexandria-devel mailing list
alexandria-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel
Marco Baringer | 24 Nov 17:59 2012
Picon

if-let*


(i think i've already sent this, but it hasn't shown up on the list,
sorry if you get it twice)

hi,

  i recently needed (or just decided that i wanted it) a version of
  if-let with sequential binding. The bindings form is as with if-let,
  however to ensure that only the 'true' bindings are seen in the else
  form (and i'm not convinced this is worth it) the else form is
  repeated multiple times (once per binding) in the macro's expansion.

  the docstring should explain how it works (and if not i'll fix the
  docstring).

  and, since it made sense to me at the time, when-let and when-let* are
  implemented in terms of if-let and if-let* (instead of repeating the
  binding expansion and and code).


--
-marco
_______________________________________________
alexandria-devel mailing list
alexandria-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel
Marco Baringer | 22 Nov 09:02 2012
Picon

multiple values in switch clauses


hi,

  i'd like switch to, just like case and typecase do, allow multiple
  values in the 'value' position of the condition:

  (switch (foo)
    ((bar baz) ...))

  So the attached patch checks for the key form being a cons and, if so,
  expands into a (member value :test test) instead of (test value)
  form. Of course, this means that your key values can no longer be
  forms, so this may break existing code. I don't have any code which
  actually uses a function call in the value form of the clause (and a
  quick grep over my locally installed lisp libs shows nobody else does
  either), so i'm ok with the change, but i can understand if others
  don't agree.


--
-marco
_______________________________________________
alexandria-devel mailing list
alexandria-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel

Gmane