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

[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

[postmodern-devel] Git?
by Marijn Haverbeke 27 Mar '10

27 Mar '10

Hello list, Would it cause problems, effort, or needless pain for any of you if I switched Postmodern development from darcs to git? I've been using git in pretty much all of my other work, and it's been so ingrained in my system that I'm starting to have trouble working with darcs. The whole project history can be converted using darcs-to-git. Also, I am planning to move over hosting of the project from common-lisp.net to my own server, since I have more control there (not to mention a better uptime record). If I make the switch to git, I'll probably make the server switch at the same time. Best, Marijn

4 3

[postmodern-devel] Developing with postmodern
by Mariano Montone 22 Mar '10

22 Mar '10

Hi! When developing with postmodern I'm having two problems: If a query is wrong, my slime connection seems to get disconnected or waiting for something (I have to hit C-c c to get the REPL back). Besides, when an error ocurrs, I don't get notified immediatly, but after I make another query, in which case I get a "the database is processing another query" (the screwed up query). So I have to restart the connection or the application (I'm developing a Web application)... :( Do someone else have the same problems? How do you fix them? Thanks! Mariano

3 13

[postmodern-devel] one-way array/record/coercion support
by Daniel Janus 22 Mar '10

22 Mar '10

Dear list, first of all, many thanks to Marijn and all the contributors for the excellent piece of code that is Postmodern. In my project I'm using it to connect to a database that heavily uses some of the advanced PostgreSQL functionality, including PL/pgSQL functions taking arrays of records as arguments. I found S-SQL to be a little lacking in expressiveness for that, so I've quickly hacked some methods that let me pass Lisp vectors to SQL and QUERY (they will be rendered into PostgreSQL array literals): ;;; code starts here (in-package :cl-postgres) (defmethod to-sql-string ((arg vector)) (cond ((typep arg '(vector (unsigned-byte 8))) (values (escape-bytes arg) t)) (t (format nil "ARRAY[~{~A~^, ~}]" (mapcar #'s-sql::sql-ize (coerce arg 'list)))))) (defmethod to-sql-string ((arg list)) (format nil "(~{~A~^, ~})" (mapcar #'s-sql::sql-ize arg))) (in-package :s-sql) (def-sql-op :coerce (form type) `(,@(sql-expand form) "::" ,type)) ;;; code ends here I'm sending it along in case it is useful to anyone else. Or perhaps it might make its way to the main repo? For the latter, presumably a full support would be needed, but I didn't find time to dive into Postmodern's way of passing back PostgreSQL-returned data into Lisp values of proper types, as I currently don't need that. Best regards, Daniel Janus

4 7

[postmodern-devel] Postgres transaction warnings and save-dao
by Peter Stiernström 09 Mar '10

09 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm using postmodern with great success but I keep seeing these two warnings in my log: - "Postgres warning: there is no transaction in progress" - "Warning while processing connection: Postgres warning: there is already a transaction in progress" As far as I can tell these are merely warnings but they're filling up my logs so I had a look at what was causing it and I found that save-dao has a (with-transaction () ...) wrapping an insert-dao and I was calling save-dao from within my own transaction block. Now if just remove the with-transaction from save-dao an duplicate key violation will ruin the outer transaction by just aborting it (regardless of the error handling code. However if I add a savepoint just before trying insert-dao and in the error handling code use rollback-savepoint to restore to this savepoint I can make the warnings go away. The problem now being that save-dao expects to be called within a with-transaction form. So I was wondering if there is some way to tell if we are within a transaction (e.g. within-transaction-p)? Then I would be able to make a modification that handles both cases. It might then look something like this: (defun save-dao (dao) (if (within-transaction-p) (with-savepoint save-dao (handler-case (progn (insert-dao dao) t) (cl-postgres-error:unique-violation () (rollback-savepoint save-dao) (update-dao dao) nil)))) (handler-case (with-transaction () (insert-dao dao) t) (cl-postgres-error:unique-violation () (update-dao dao) nil))) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuWEs8ACgkQ0brSZD05ZzAj7wCfbhPynKyGMStzsRP/3MIGpOSH 6IcAni232P2lQ8/hAh5+03NmFr0FSbMs =EIRi -----END PGP SIGNATURE-----

3 5

[postmodern-devel] Release 1.15
by Marijn Haverbeke 01 Mar '10

01 Mar '10

I just bundled the changes (all relatively minor) made in the past year as release 1.15, so that those not pulling directly from darcs can also see them. Cheers, Marijn

1 0

Re: [postmodern-devel] Postmodern SBCL UNIX sockets
by Marijn Haverbeke 02 Feb '10

02 Feb '10

Hello Stian, I've pushed a patch to the repository that allows people to pass :unix as hostname on SBCL to cause cl-postgres to try and use a unix socket. I've also dropped the usocket dependency on that platform and switched to directly using sb-bsd-sockets, since usocket has half-a-zillion dependencies and doesn't really do anything useful -- there are only two places that have to be conditionalized, the connect call and the socket-error type. Best, Marijn

1 0