April 2010 - postmodern-devel - mailman3.common-lisp.net

[postmodern-devel] cl-postgres/sbcl crashes with bogus stack frame
by david thompson 06 May '10

06 May '10

Any ideas what might trigger cl-postgres (postmodern 1.14) coming to its knees with the backtrace shown below? No error or condition description is given - sbcl (1.0.28) just retires from active duty and drops into the debugger with the ("bogus stack frame") indication. The postgresql server (8.3) log doesn't have any indication of trouble at the time cl-postgres seems to run into trouble. This seems to only happen intermittently (every few thousand queries), irreproducibly (doesn't seem to be associated with a specific query or anything along those lines), and only when the postgresql server is being utilized by several lisp instances concurrently. Thanks in advance for any input/ideas/troubleshooting suggestions... - Alan ... 32: ("bogus stack frame") 33: (SB-IMPL::SUB-SUB-SERVE-EVENT NIL NIL) 34: (SB-IMPL::SUB-SERVE-EVENT NIL NIL NIL) 35: (SB-SYS:WAIT-UNTIL-FD-USABLE 5 :INPUT NIL) 36: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "a socket" {C265BA9}>) 37: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE #<SB-SYS:FD-STREAM for "a socket" {C265BA9}> T NIL) 38: (CL-POSTGRES::SKIP-BYTES #<unavailable argument> #<unavailable argument>) 39: (CL-POSTGRES::TRY-TO-SYNC #<SB-SYS:FD-STREAM for "a socket" {C265BA9}> T) 40: ((FLET #:CLEANUP-FUN-[FORM-FUN-[SEND-QUERY]389]390))[:CLEANUP] 41: (CL-POSTGRES::SEND-QUERY #<unavailable argument> #<unavailable argument> #<unavailable argument>) 42: ((LABELS #:G161)) 43: (SQLG::QUERY-CORE "select program from programs where programskey = '192828' ;" 20 #<unused argument>)

4 5

[postmodern-devel] Examples of using CLOS interface
by Patrick May 15 Apr '10

15 Apr '10

I've recently found Postmodern and it looks like a nice, lighter weight alternative to CL-SQL. Is there any detailed documentation for using Postmodern with CLOS? How about a richer example than that in the Database access objects section of the manual? Thanks, Patrick

1 0

[postmodern-devel] PATCH: New query formats - plists and plist
by Andrey Moskvitin 14 Apr '10

14 Apr '10

Hi, I propose to add new query formats: diff --git a/doc/postmodern.html b/doc/postmodern.html index 3691ae8..9ac466f 100644 --- a/doc/postmodern.html +++ b/doc/postmodern.html @@ -202,6 +202,10 @@ row.</td></tr> <tr><td><code>:list</code>, <code>:row</code></td><td>Return a single row as a list.</td></tr> + <tr><td><code>:plists</code></td><td>Return a list of plists which map column + names to values,with the names represented as + keywords.</td></tr> + <tr><td><code>:plist</code></td><td>Return a single row as an plist.</td></tr> <tr><td><code>:alists</code></td><td>Return a list of alists which map column names to values,with the names represented as keywords.</td></tr> diff --git a/postmodern/query.lisp b/postmodern/query.lisp index 3e5bfa5..921d03d 100644 --- a/postmodern/query.lisp +++ b/postmodern/query.lisp @@ -9,6 +9,15 @@ :for symbol :in symbols :collect (cons symbol (next-field field)))))) +;; Like symbol-alist-row-reader, but return plist +(def-row-reader symbol-plist-row-reader (fields) + (let ((symbols (map 'list (lambda (desc) (from-sql-name (field-name desc))) fields))) + (loop :while (next-row) + :collect (loop :for field :across fields + :for symbol :in symbols + :collect symbol + :collect (next-field field))))) + ;; A row-reader for reading only a single column, and returning a list ;; of single values. (def-row-reader column-row-reader (fields) @@ -22,6 +31,8 @@ (:list list-row-reader t) (:rows list-row-reader nil) (:row list-row-reader t) + (:plists symbol-plist-row-reader nil) + (:plist symbol-plist-row-reader t) (:alists symbol-alist-row-reader nil) (:alist symbol-alist-row-reader t) (:str-alists alist-row-reader nil) Moskvitin Andrey

3 6

[postmodern-devel] PATCH: Add support for asynchronous notifications
by Zach Beane 08 Apr '10

08 Apr '10

Attached is a patch that adds Postmodern support for asynchronous notifications, as documented here: http://www.postgresql.org/docs/current/static/sql-listen.html http://www.postgresql.org/docs/current/static/sql-notify.html http://www.postgresql.org/docs/current/static/sql-unlisten.html and http://www.postgresql.org/docs/current/interactive/protocol-message-formats… (under "NotificationResponse") It updates MESSAGE-CASE to watch for async notifications and, by default, issue a warning that looks very similar to what the psql client displays for async notifications: WARNING: Asynchornous notification "lisp" received from server process with PID 22063. It also adds a blocking function, WAIT-FOR-NOTIFICATION, that adds a handler-bind around the warning and returns the notification data when a notification is received. The patch isn't complete, though -- I wasn't sure how best to integrate the new public function, condition, and condition accessors into the documentation. How should I proceed? Zach

2 1

[postmodern-devel] Sorry about the git repository confusion!
by Marijn Haverbeke 08 Apr '10

08 Apr '10

Initially, I published a 'git clone' example that didn't even work. Then, it worked, but was dog-slow because I hadn't enabled git's HTTP cgi script. Now finally, things are ducky, but the URL changed again: git clone http://marijn.haverbeke.nl/git/postmodern GitHub also continues to work, of course. Cheers, Marijn

1 0

[postmodern-devel] [patch] Erratic behavior when NIL password is given
by J.P. Larocque 07 Apr '10

07 Apr '10

Hi, I usually use host-based authentication with ident to connect to PostgreSQL from trusted machines, so I've been specifying a password of NIL for a long time. However, when passwordless authentication fails and NIL is given as a password, POSTMODERN:CONNECT will behave erratically. In my case, the symptoms are: * SBCL (Debian 1:1.0.18.0-2) RAM usage balloons to hundreds of megabytes. * I get this condition printed, along with a tag-along (obscure and what I assume to be) object, for the heck of it: ---8<---8<--- * (postmodern:connect "piranha" "piranha" nil "localhost") debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {1002669C31}>: The value NIL is not of type (MOD 1152921504606846975). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-KERNEL:UB32-BASH-COPY "piranha" 0 "" NIL 7)[:EXTERNAL] --->8--->8--- That's invoking SBCL on the command-line. When I use SLIME: * SBCL, like a gas, expands to fill all available space (e.g. ~1.8GiB before I ran out of RAM+swap and rebooted the virtual machine). * During this time, nothing ever comes back to emacs. * If I do a SLIME interrupt before the system completely dies, emacs takes a while to do anything, then enters the emacs (not SLIME!) debugger, and informs me that the "variable binding depth exceeds max-specpdl-size" at every available opportunity until I restart emacs. It turns out bad things happen when you optimize for safety 0. Making this change: diff -x'*~' -urN postmodern-1.16/cl-postgres/package.lisp postmodern-1.16-no_opt/cl-postgres/package.lisp --- postmodern-1.16/cl-postgres/package.lisp 2010-04-02 04:23:24.000000000 -0700 +++ postmodern-1.16-no_opt/cl-postgres/package.lisp 2010-04-06 06:00:47.000000000 -0700 @@ -83,5 +83,5 @@ (eval-when (:compile-toplevel :load-toplevel :execute) ;; Optimization settings (only used by functions that need it). (defparameter *optimize* - '(optimize (speed 3) (safety 0) (space 1) (debug 1) + '(optimize (speed 3) (space 1) (debug 1) (compilation-speed 0)))) yields a much more sensible, instantaneous, and non-ballooning: The value NIL is not of type STRING. [Condition of type TYPE-ERROR] Of course, bad things also happen when you pass objects of the wrong type to a function. (It just never sat well with me to pass a string password when no password was needed; NIL seemed to make much more sense, and it worked...) I've attached a patch to: * Check the types of arguments given to CL-POSTGRES:OPEN-DATABASE. * Update the HTML documentation to describe the expected types of arguments to CL-POSTGRES:OPEN-DATABASE and POSTMODERN:CONNECT. * Update the documentation strings for the above two functions to contain the same content as their descriptions in the HTML documentation. I also humbly suggest not optimizing for safety 0. One of the big reasons I use CL, and not something like C, is because I value safety: when one thing breaks, that breakage is self-contained and can be tracked down due to conditions. I don't want my Lisp process to go down like the Hindenburg when one little thing goes wrong. Thanks for your time, -- J.P. Larocque <jpl(a)thoughtcrime.us>

2 2

[postmodern-devel] simple-date:day-of-week doc mismatch?
by Daniel Janus 02 Apr '10

02 Apr '10

Hi, DB> (make-date nil nil nil) #<DATE 30-03-2010> DB> (day-of-week *) 1 That would indicate Monday, according to the docs, while my system calendar tells me it's Tuesday today... What gives? (I'm on SBCL 1.0.34.) Best regards, Daniel

2 1

[postmodern-devel] Release 1.16 (and new project page url, and new version control system)
by Marijn Haverbeke 02 Apr '10

02 Apr '10

Changes in this version: * Introduces a save-dao/transaction, because the old semantics were broken (originally inside of transactions, after fixing that outside of them). * Add support for passing vectors as argument to prepared queries, and reading them from query results. * Add :on-update and :on-delete arguments to !foreign. * Add :plist and :plists query result formats. * Guarantee that deftable definitions are executed in the order they were defined in. * Moves the ieee-floats and trivial-utf-8 dependencies into the repository, so they don't have to separately fetched. The project page is now no longer at common-lisp.net, but can instead be found at http://marijn.haverbeke.nl/postmodern . We will continue to use the common-lisp.net mailing lists. And finally, the darcs repository will no longer be updated. The new git repository lives at http://marijn.haverbeke.nl/postmodern/postmodern , and http://github.com/marijnh/Postmodern will be kept in sync with that. Best, Marijn

1 0