From julien at danjou.info Wed Jul 24 14:37:27 2013 From: julien at danjou.info (Julien Danjou) Date: Wed, 24 Jul 2013 16:37:27 +0200 Subject: Timezone handling In-Reply-To: (Sabra Crolleton's message of "Wed, 24 Jul 2013 04:55:59 -0700") References: <874nbkew8w.fsf@dex.adm.naquadah.org> <87vc40ctvd.fsf@dex.adm.naquadah.org> Message-ID: <87k3kgaus8.fsf@dex.adm.naquadah.org> On Wed, Jul 24 2013, Sabra Crolleton wrote: Hi Sabra, > Are you thinking that PG will allow you to have different timezones in your > timestamp? If my understanding of PG is correct, it keeps everything in a > single timezone - UTC. Then everything else is set using the offset. See, > e.g. http://www.postgresql.org/docs/9.1/static/datatype-datetime.html No, I've stumbled upon this page too yesterday actually and learnt it stores eveything in UTC. > So, looking at a server that is set for PDT, for table test with fields > name, text and updated_at > > Default with no timezone or offset: > (query (:insert-into 'test :set 'name "george" 'text "insert here" > 'updated-at > (local-time:encode-timestamp 0 0 0 12 01 01 2013))) > > 2013-01-01 12:00:00-08 (looking at the default timezone for the server, PG > has set the timezone to UTC less 8 hours - UTC time would be 04:00:00) Agreed. The problem in this case is that you don't know the timezone of the serverm and I want to insert an UTC timestamp. > Using offset to explicitly offset 1 hour from UTC (e.g. Paris) > (query (:insert-into 'test :set 'name "ringo" 'text "offset 1 hour" > 'updated-at > (local-time:encode-timestamp 0 0 0 12 01 01 2013 > :offset 3600))) > > 2013-01-01 03:00:00-08 (looking at the default timezone for the server, PG > has kept the timezone as PDT - UTC less 8 hours - but set the time as > 03:00:00, which is 1 hour ahead of UTC) Yeah, because `encode-timestamp' returned 2013-01-01 11:00:00, and what's got inserted. > Using timezone to explicitly set it for UTC > (query (:insert-into 'test > :set 'name "paul" 'text "insert here using timezone > utc" > 'updated-at > (local-time:encode-timestamp 0 0 0 12 01 01 2013 > :timezone > local-time::+utc-zone+))) > > 2013-01-01 04:00:00-08 (looking at the default timezone for the server, PG > has kept the timezone as PDT - UTC less 8 hours - but set the time as > 04:00:00, which is the time in UTC relative to the PDT time at the server. > > Does this help? Not really unfortunatelly, unless I've missed the obvious. I've still have no clue on how to insert "2013-01-01 12:00:00 UTC" into PG. Your first example inserted "2013-01-01 04:00:00 UTC", and the second example inserted "2013-01-01 03:00:00 UTC". Thanks! -- Julien Danjou /* Free Software hacker * freelance consultant http://julien.danjou.info */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From julien at danjou.info Sun Jul 28 14:17:46 2013 From: julien at danjou.info (Julien Danjou) Date: Sun, 28 Jul 2013 16:17:46 +0200 Subject: cl-postgres convert nil to false In-Reply-To: <877ggdwebf.fsf@dex.adm.naquadah.org> (Julien Danjou's message of "Fri, 26 Jul 2013 17:06:44 +0200") References: <877ggdwebf.fsf@dex.adm.naquadah.org> Message-ID: <87ehaircol.fsf@dex.adm.naquadah.org> On Fri, Jul 26 2013, Julien Danjou wrote: > Does that sounds like a good idea, or do I miss an obvious problem? For the record and people interested in that hack, I really find it quite handy in the end. And it's easy enough to change cl-postgres/s-sql behaviour: (defmethod s-sql:sql-escape ((arg symbol)) "Overrides the s-sql provided function so it handles correctly the :false keyword and get it converted to false." (if (or (typep arg 'boolean) (eq arg :null) (eq arg :false)) (call-next-method) (s-sql:to-sql-name arg))) (defmethod cl-postgres:to-sql-string ((arg (eql nil))) "Overrides the cl-postgres provided function so it handles nil as NULL instead of false." "NULL") (defmethod cl-postgres:to-sql-string ((arg (eql :false))) "Overrides the cl-postgres provided function so it handles :false." "false") -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From sabra.crolleton at gmail.com Wed Jul 24 11:55:59 2013 From: sabra.crolleton at gmail.com (Sabra Crolleton) Date: Wed, 24 Jul 2013 04:55:59 -0700 Subject: Timezone handling In-Reply-To: <87vc40ctvd.fsf@dex.adm.naquadah.org> References: <874nbkew8w.fsf@dex.adm.naquadah.org> <87vc40ctvd.fsf@dex.adm.naquadah.org> Message-ID: Julien, Are you thinking that PG will allow you to have different timezones in your timestamp? If my understanding of PG is correct, it keeps everything in a single timezone - UTC. Then everything else is set using the offset. See, e.g. http://www.postgresql.org/docs/9.1/static/datatype-datetime.html "For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's timezoneparameter, and is converted to UTC using the offset for the timezone zone. When a timestamp with time zone value is output, it is always converted from UTC to the current timezone zone, and displayed as local time in that zone. To see the time in another time zone, either change timezone or use the AT TIME ZONE construct." So, looking at a server that is set for PDT, for table test with fields name, text and updated_at Default with no timezone or offset: (query (:insert-into 'test :set 'name "george" 'text "insert here" 'updated-at (local-time:encode-timestamp 0 0 0 12 01 01 2013))) 2013-01-01 12:00:00-08 (looking at the default timezone for the server, PG has set the timezone to UTC less 8 hours - UTC time would be 04:00:00) Using offset to explicitly offset 1 hour from UTC (e.g. Paris) (query (:insert-into 'test :set 'name "ringo" 'text "offset 1 hour" 'updated-at (local-time:encode-timestamp 0 0 0 12 01 01 2013 :offset 3600))) 2013-01-01 03:00:00-08 (looking at the default timezone for the server, PG has kept the timezone as PDT - UTC less 8 hours - but set the time as 03:00:00, which is 1 hour ahead of UTC) Using timezone to explicitly set it for UTC (query (:insert-into 'test :set 'name "paul" 'text "insert here using timezone utc" 'updated-at (local-time:encode-timestamp 0 0 0 12 01 01 2013 :timezone local-time::+utc-zone+))) 2013-01-01 04:00:00-08 (looking at the default timezone for the server, PG has kept the timezone as PDT - UTC less 8 hours - but set the time as 04:00:00, which is the time in UTC relative to the PDT time at the server. Does this help? Sabra On Wed, Jul 24, 2013 at 12:14 AM, Julien Danjou wrote: > On Wed, Jul 24 2013, Sabra Crolleton wrote: > > > I use the local-time package with encode-timestamp to create the > timestamp > > and just put that into the database. > > > > Function: local-time:encode-timestamp nsec sec minute hour day month year > > &key timezone offset into > > > > Returns a new timestamp instance corresponding to the specified time > > elements. The offset is the number of seconds offset from UTC of the > > locale. If offset is not specified, the offset will be guessed from the > > timezone. If a timestamp is passed as the into argument, its value will > be > > set and that timestamp will be returned. Otherwise, a new timestamp is > > created. > > The problem is that it returns a timestamp without any timezone > information, it just convert the time given into an UTC representation > based on the timezone arguments. > Or when INSERTed, if your Postgresql session runs with a default > timezone different than UTC (which is usually the case), PG will insert > it considering the timezine is in the locale timestamp, not UTC. > > When your PG server is in GMT+2 and has such a default session, if: > a. you INSERT (encode-timestamp 0 0 0 12 01 01 2013) it will insert > 2013-01-01 12:00:00+02 > (which is correct because the CL timezone and the PG timezone matches) > > b. you INSERT (encode-timestamp 0 0 0 12 01 01 2013 :timezone UTC) it will > insert > 2013-01-01 10:00:00+02 > (which is wrong since the timestamp is in UTC) > > And here I'm on case b. > > -- > Julien Danjou > # Free Software hacker # freelance consultant > # http://julien.danjou.info > -------------- next part -------------- An HTML attachment was scrubbed... URL: From russ at acceleration.net Wed Jul 24 17:36:15 2013 From: russ at acceleration.net (Russ Tyndall) Date: Wed, 24 Jul 2013 13:36:15 -0400 Subject: Timezone handling In-Reply-To: <87k3kgaus8.fsf@dex.adm.naquadah.org> References: <874nbkew8w.fsf@dex.adm.naquadah.org> <87vc40ctvd.fsf@dex.adm.naquadah.org> <87k3kgaus8.fsf@dex.adm.naquadah.org> Message-ID: <51F0108F.1030300@acceleration.net> On 7/24/2013 10:37 AM, Julien Danjou wrote: > Not really unfortunatelly, unless I've missed the obvious. I've still > have no clue on how to insert "2013-01-01 12:00:00 UTC" into PG. Your > first example inserted "2013-01-01 04:00:00 UTC", and the second > example inserted "2013-01-01 03:00:00 UTC". Thanks! Baring the rest of the issues you might be experiencing with these layered systems, "2013-01-01 11:00:00" is considered timezoneless (ie: local zone of whatever computer is interpreting it). If you wish to insert "2013-01-01 04:00:00 UTC" the correct spelling is "2013-01-01 04:00:00Z" or "2013-01-01 04:00:00+0" which are two spellings of a timestamp in UTC. Both should be recognized by postegresql correctly. This call to local-time:format-timestring should allow you to produce timestamps in the correct zone. (local-time:format-timestring nil (local-time:encode-timestamp 0 0 0 12 01 01 2013) :timezone local-time:+utc-zone+) This wikipedia article should help. https://en.wikipedia.org/wiki/ISO_8601 Hope this helps, Russ Tyndall Acceleration.net Software Developer From julien at danjou.info Thu Jul 25 21:47:35 2013 From: julien at danjou.info (Julien Danjou) Date: Thu, 25 Jul 2013 23:47:35 +0200 Subject: Timezone handling References: <874nbkew8w.fsf@dex.adm.naquadah.org> <87vc40ctvd.fsf@dex.adm.naquadah.org> <87k3kgaus8.fsf@dex.adm.naquadah.org> <51F0108F.1030300@acceleration.net> Message-ID: <87ob9q71mw.fsf@dex.adm.naquadah.org> On Wed, Jul 24 2013, Russ Tyndall wrote: > Baring the rest of the issues you might be experiencing with these layered > systems, "2013-01-01 11:00:00" is considered timezoneless (ie: local zone of > whatever computer is interpreting it). If you wish to insert "2013-01-01 > 04:00:00 UTC" the correct spelling is "2013-01-01 04:00:00Z" or "2013-01-01 > 04:00:00+0" which are two spellings of a timestamp in UTC. Both should be > recognized by postegresql correctly. > > This call to local-time:format-timestring should allow you to produce > timestamps in the correct zone. > (local-time:format-timestring nil > (local-time:encode-timestamp 0 0 0 12 01 01 2013) > :timezone local-time:+utc-zone+) Thanks, that's helpful. I hoped there was a way to insert a timestamp with a timezone attached without passing by a conversion to its string representation, but it seems impossible. But this seems to work fine, event with DAO as far as I can see. Cheers, -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From marijnh at gmail.com Thu Jul 25 05:54:51 2013 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 25 Jul 2013 07:54:51 +0200 Subject: nyef's postmodern gripes In-Reply-To: <877ggsudu0.fsf@zpobx.site.sys> References: <877ggsudu0.fsf@zpobx.site.sys> Message-ID: Below is what I annotated the paste with. Zach, I couldn't find any info on this nyef character -- could you send nyef in the direction of my annotation on the paste next time you see him on irc -- and maybe notify me if he/she replies? Thanks. ----------- Hello nyef, It appears you've used Postmodern quite a bit. But you don't appear to have ever submitted a patch or even a bug report. For things like the macro/function confusion in the documentation (which I couldn't find), and the bad link to the mailing list (which was the case shortly after common-lisp.net changed their mailing list system, and was fixed a month ago when someone -- *not* you, of course -- mailed me about it), it'd be trivial to submit a report. For some of your others gripes, the ones that sound like actual bugs instead of vague complaints, it'd be slightly more work to isolate and investigate (or just report them). You did no such thing. What you did was piss negativity about the project in an IRC channel that I don't read. This accomplishes nothing, except possibly turn people away from useful software. Please either start being a productive community member, or stop talking about Postmodern altogether. (And no, the fact that the mailing list link was broken doesn't excuse the lack of feedback -- that was only for a few weeks, there's still the github issue tracker, and it is extremely easy to find my e-mail address.) Best, Marijn Haverbeke From sabra.crolleton at gmail.com Sat Jul 20 23:52:54 2013 From: sabra.crolleton at gmail.com (Sabra Crolleton) Date: Sat, 20 Jul 2013 16:52:54 -0700 Subject: nyef's postmodern gripes Message-ID: Is there a better way to write "common table expressions " (with and with recursive) than: (def-sql-op :with (&rest args) (let ((x (butlast args)) (y (last args))) `("WITH " ,@(sql-expand-list x) ,@(sql-expand (car y))))) (def-sql-op :with-recursive (&rest args) (let ((x (butlast args)) (y (last args))) `("WITH RECURSIVE " ,@(sql-expand-list x) ,@(sql-expand (car y))))) They work for me, but I have the feeling there is a better way to do it. Actual use would be something like the following (using the example from the postgresql website): (defun test2 () (query (:with-recursive (:as 'regional-sales (:select 'region (:as (:sum 'amount) 'total-sales) :from 'orders :group-by 'region)) (:as 'top-regions (:select 'region :from 'regional-sales :where (:> 'total-sales (:select (:/ (:sum 'total-sales) 10) :from 'regional-sales)))) (:select 'region 'product (:as (:sum 'quantity) 'product-units) (:as (:sum 'amount) 'product-sales) :from 'orders :where (:in 'region (:select 'region :from 'top-regions)) :group-by 'region 'product)))) Sabra -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien at danjou.info Wed Jul 24 07:14:14 2013 From: julien at danjou.info (Julien Danjou) Date: Wed, 24 Jul 2013 09:14:14 +0200 Subject: Timezone handling In-Reply-To: (Sabra Crolleton's message of "Tue, 23 Jul 2013 21:26:16 -0700") References: <874nbkew8w.fsf@dex.adm.naquadah.org> Message-ID: <87vc40ctvd.fsf@dex.adm.naquadah.org> On Wed, Jul 24 2013, Sabra Crolleton wrote: > I use the local-time package with encode-timestamp to create the timestamp > and just put that into the database. > > Function: local-time:encode-timestamp nsec sec minute hour day month year > &key timezone offset into > > Returns a new timestamp instance corresponding to the specified time > elements. The offset is the number of seconds offset from UTC of the > locale. If offset is not specified, the offset will be guessed from the > timezone. If a timestamp is passed as the into argument, its value will be > set and that timestamp will be returned. Otherwise, a new timestamp is > created. The problem is that it returns a timestamp without any timezone information, it just convert the time given into an UTC representation based on the timezone arguments. Or when INSERTed, if your Postgresql session runs with a default timezone different than UTC (which is usually the case), PG will insert it considering the timezine is in the locale timestamp, not UTC. When your PG server is in GMT+2 and has such a default session, if: a. you INSERT (encode-timestamp 0 0 0 12 01 01 2013) it will insert 2013-01-01 12:00:00+02 (which is correct because the CL timezone and the PG timezone matches) b. you INSERT (encode-timestamp 0 0 0 12 01 01 2013 :timezone UTC) it will insert 2013-01-01 10:00:00+02 (which is wrong since the timestamp is in UTC) And here I'm on case b. -- Julien Danjou # Free Software hacker # freelance consultant # http://julien.danjou.info -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From xach at xach.com Thu Jul 25 10:44:45 2013 From: xach at xach.com (FZach Beane) Date: Thu, 25 Jul 2013 06:44:45 -0400 Subject: nyef's postmodern gripes In-Reply-To: (Marijn Haverbeke's message of "Thu, 25 Jul 2013 07:54:51 +0200") References: <877ggsudu0.fsf@zpobx.site.sys> Message-ID: <87hafiq5pe.fsf@zpobx.site.sys> Marijn Haverbeke writes: > Below is what I annotated the paste with. Zach, I couldn't find any > info on this nyef character -- could you send nyef in the direction of > my annotation on the paste next time you see him on irc -- and maybe > notify me if he/she replies? Thanks. Will do. "nyef" is the nickname of Alistair Bridgewater, who ported SBCL to Windows initially and who still hacks on SBCL from time to time. Zach From sabra.crolleton at gmail.com Wed Jul 24 04:26:16 2013 From: sabra.crolleton at gmail.com (Sabra Crolleton) Date: Tue, 23 Jul 2013 21:26:16 -0700 Subject: Timezone handling In-Reply-To: <874nbkew8w.fsf@dex.adm.naquadah.org> References: <874nbkew8w.fsf@dex.adm.naquadah.org> Message-ID: I use the local-time package with encode-timestamp to create the timestamp and just put that into the database. Function: local-time:encode-timestamp nsec sec minute hour day month year &key timezone offset into Returns a new timestamp instance corresponding to the specified time elements. The offset is the number of seconds offset from UTC of the locale. If offset is not specified, the offset will be guessed from the timezone. If a timestamp is passed as the into argument, its value will be set and that timestamp will be returned. Otherwise, a new timestamp is created. Hope that helps. Sabra On Tue, Jul 23, 2013 at 3:39 PM, Julien Danjou wrote: > Hi there, > > I'm struggling with timezone handling in Postmodern. I'm using timestamp > with time zone column types, and I'm looking for the correct way to feed > postmodern such information on insert. Basically, I don't see any class > that would fit. I've tried to grep through the code but didn't find much > about timestamp/timezone handling. > > Concretely, I'm having UTC timestamp that I want to insert into those > timestamp-with-time-zone columns, but I don't know how to tell > Postmodern that it should postfix them with something like +00 so PG > understand it should not default them to its default timezone. > > On the same topic, I thought that one easy solution would be to set the > session timezone to UTC. It's easy enough to come with a macro doing a > SET TIMEZONE='UTC' before each request, but honestly, I'd like to avoid > that and do it only at connection time. > Now, I've read through cl-postgres code, and I was hoping being able to > plug my code at connection time, but it seems everything is defined as > function and not as method, which seems weird to me, and not really > pluggable in the end. > > Any hint appreciated! > > Cheers, > -- > Julien Danjou > ;; Free Software hacker ; freelance consultant > ;; http://julien.danjou.info > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien at danjou.info Fri Jul 26 15:06:44 2013 From: julien at danjou.info (Julien Danjou) Date: Fri, 26 Jul 2013 17:06:44 +0200 Subject: cl-postgres convert nil to false Message-ID: <877ggdwebf.fsf@dex.adm.naquadah.org> Hi there, I'm dealing with a problem and I'd like some enlightenment. I've a table with text columns that can't be NULL. In my Lisp program, sometimes I'm assigning `nil' as value for this column, either via a direct query execution or via the DAO. What I would expect in this case, is to PostgreSQL to raise an error. But this does not happen. What happens is that (cl-postgres:to-sql-string nil) returns "false", and that the query is built to: INSERT INTO mytable (mytextfield) VALUES (false); PostgreSQL implicit type conversion kicks in and insert the string 'false' into the field, which does not trigger an error since this it not NULL. The obvious fix here is to patch all my code to convert nil to :null, but this is a pain. I don't want to do the type checking I'm doing with PostgreSQL one more time in my application. What I'd like is for cl-postgres to consider nil as being NULL. The boolean false value could be mapped as :false, which would also make sure no code is inserting false just because a value is actually nil. The change is pretty trivial and I'm running with it right now, which allowed me to debug a lot of implicit nil conversion to 'false' in text fields. I recognize this is something that would break compatibility, so that might be enabled via a defparameter or something. Does that sounds like a good idea, or do I miss an obvious problem? -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From julien at danjou.info Tue Jul 23 22:39:59 2013 From: julien at danjou.info (Julien Danjou) Date: Wed, 24 Jul 2013 00:39:59 +0200 Subject: Timezone handling Message-ID: <874nbkew8w.fsf@dex.adm.naquadah.org> Hi there, I'm struggling with timezone handling in Postmodern. I'm using timestamp with time zone column types, and I'm looking for the correct way to feed postmodern such information on insert. Basically, I don't see any class that would fit. I've tried to grep through the code but didn't find much about timestamp/timezone handling. Concretely, I'm having UTC timestamp that I want to insert into those timestamp-with-time-zone columns, but I don't know how to tell Postmodern that it should postfix them with something like +00 so PG understand it should not default them to its default timezone. On the same topic, I thought that one easy solution would be to set the session timezone to UTC. It's easy enough to come with a macro doing a SET TIMEZONE='UTC' before each request, but honestly, I'd like to avoid that and do it only at connection time. Now, I've read through cl-postgres code, and I was hoping being able to plug my code at connection time, but it seems everything is defined as function and not as method, which seems weird to me, and not really pluggable in the end. Any hint appreciated! Cheers, -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From marijnh at gmail.com Mon Jul 29 06:28:35 2013 From: marijnh at gmail.com (Marijn Haverbeke) Date: Mon, 29 Jul 2013 08:28:35 +0200 Subject: cl-postgres convert nil to false In-Reply-To: <877ggdwebf.fsf@dex.adm.naquadah.org> References: <877ggdwebf.fsf@dex.adm.naquadah.org> Message-ID: The distinction between nil and :null in Postmodern is a conscious decision. It makes the CL type 'boolean neatly correspond to Postgres booleans, and introduces a new type to indicate nullability. I've also had to write code to convert nils to :nulls in deep data structures a few occasions, but I think that this is a less problematic situation than having to convert boolean nils to :false. Add to that backwards incompatibility, and I just don't think this is a worthwhile change to make. Best, Marijn On Fri, Jul 26, 2013 at 5:06 PM, Julien Danjou wrote: > Hi there, > > I'm dealing with a problem and I'd like some enlightenment. > > I've a table with text columns that can't be NULL. > In my Lisp program, sometimes I'm assigning `nil' as value for this > column, either via a direct query execution or via the DAO. What I > would expect in this case, is to PostgreSQL to raise an error. > > But this does not happen. > > What happens is that (cl-postgres:to-sql-string nil) returns "false", > and that the query is built to: > > INSERT INTO mytable (mytextfield) VALUES (false); > > PostgreSQL implicit type conversion kicks in and insert the string > 'false' into the field, which does not trigger an error since this it > not NULL. > > The obvious fix here is to patch all my code to convert nil to :null, > but this is a pain. I don't want to do the type checking I'm doing with > PostgreSQL one more time in my application. > > What I'd like is for cl-postgres to consider nil as being NULL. > The boolean false value could be mapped as :false, which would also make > sure no code is inserting false just because a value is actually nil. > > The change is pretty trivial and I'm running with it right now, which > allowed me to debug a lot of implicit nil conversion to 'false' in text > fields. > > I recognize this is something that would break compatibility, so that > might be enabled via a defparameter or something. > > Does that sounds like a good idea, or do I miss an obvious problem? > > -- > Julien Danjou > ;; Free Software hacker ; freelance consultant > ;; http://julien.danjou.info From xach at xach.com Mon Jul 15 13:56:07 2013 From: xach at xach.com (Zach Beane) Date: Mon, 15 Jul 2013 09:56:07 -0400 Subject: nyef's postmodern gripes Message-ID: <877ggsudu0.fsf@zpobx.site.sys> Postmodern fits my needs very well, but whenever it comes up in discussion, nyef has dropped vague disparagement. I pestered him to write down some specifics, so here they are: http://paste.lisp.org/display/138060 Zach