From khaelin at gmail.com Sun Jun 5 19:47:30 2011 From: khaelin at gmail.com (Nicolas Martyanoff) Date: Sun, 05 Jun 2011 21:47:30 +0200 Subject: [cl-json-devel] bug report Message-ID: <87zklwcb71.fsf@gmail.com> Hi, The following form breaks when evaluated: (json:encode-json-to-string '((:a . ((:b . ((:c . 42))))))) Help! 11 nested errors. SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded. 0: (SB-DEBUG::MAP-BACKTRACE # :START 0 :COUNT 1152921504606846975) 1: (BACKTRACE 1152921504606846975 #) 2: ((LAMBDA NIL)) 3: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #) 4: (SB-IMPL::ERROR-ERROR "Help! " 11 " nested errors. " "SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.") 5: (SB-IMPL::INFINITE-ERROR-PROTECTOR) 6: (ERROR JSON:UNENCODABLE-VALUE-ERROR :DATUM (:C . 42) :CONTEXT JSON:ENCODE-JSON) 7: (JSON:UNENCODABLE-VALUE-ERROR (:C . 42) JSON:ENCODE-JSON) 8: (SIGNAL #) 9: (ERROR TYPE-ERROR :DATUM 42 :EXPECTED-TYPE LIST) 10: (SB-KERNEL::OBJECT-NOT-LIST-ERROR-HANDLER # #.(SB-SYS:INT-SAP #X7FFFF6D8CC20) # (405)) 11: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #X7FFFF6D8C600) #) 12: ("foreign function: #x417860") debugger invoked on a SIMPLE-ERROR in thread #: Maximum error nesting depth exceeded 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. Regards, -- Nicolas Martyanoff http://codemore.org khaelin at gmail.com From boris.smilga at gmail.com Sun Jun 5 21:53:20 2011 From: boris.smilga at gmail.com (Boris Smilga) Date: Mon, 6 Jun 2011 01:53:20 +0400 Subject: [cl-json-devel] bug report In-Reply-To: <87zklwcb71.fsf@gmail.com> References: <87zklwcb71.fsf@gmail.com> Message-ID: On 5 Jun 2011, at 23:47, Nicolas Martyanoff wrote: > The following form breaks when evaluated: > > (json:encode-json-to-string '((:a . ((:b . ((:c . 42))))))) > > Help! 11 nested errors. SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded. Hello. That's expected behaviour (sort of). Essentially, when ENCODE-JSON is passed a cons cell, it has no way of telling whether the cell is the head of A) an alist (which should be encoded as a JSON Object), or B) of a proper list which is not an alist (which should be encoded as a JSON Array), or C) of an improper list (which is unencodable and so should produce an error). So it tries the option B first, and, if that fails, the option A. In your case, this situation is reproduced on every level of nesting. The problem is that SB-KERNEL:*MAXIMUM-ERROR-DEPTH* is quite shallow by default (10), and the try-proper-list-fall-back-to-alist approach results in a layering of nested conditions which is deeper than that number. Writing, e. g., (let ((sb-kernel:*maximum-error-depth* 20)) (json:encode-json-to-string '((:a . ((:b . ((:c . 42)))))))) produces the correct result, "{\"a\":{\"b\":{\"c\":42}}}" . I know this is not a sustainable approach, but at this moment I have no good idea how to modify CL-JSON to get around this issue. Your best options at this moment would be to use either CLOS objects instead of alists, or the explicit encoder from the repository version: (json:with-explicit-encoder (json:encode-json-to-string '(:object :a (:object :b (:object :c 42))))) or (json:with-explicit-encoder (json:encode-json-to-string '(:object (:a . (:object (:b . (:object (:c . 42)))))))) Sincerely, - B. Smilga. From rpgoldman at sift.info Sun Jun 5 21:42:37 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Sun, 05 Jun 2011 16:42:37 -0500 Subject: [cl-json-devel] bug report In-Reply-To: <87zklwcb71.fsf@gmail.com> References: <87zklwcb71.fsf@gmail.com> Message-ID: <4DEBF84D.9090906@sift.info> On 6/5/11 Jun 5 -2:47 PM, Nicolas Martyanoff wrote: > (json:encode-json-to-string '((:a . ((:b . ((:c . 42))))))) On Allegro, this encounters no error. Clozure CL likewise. It certainly does explode in an exciting way on SBCL, and in a way that seems to bork SLIME (SBCL 1.0.47, SLIME who-knows-what from cvs). The following is enough to cause SBCL to choke: (json:encode-json-to-string '(:c . 42)) and somehow this seems to be invoked by the above, although (json:encode-json-to-string '((:c . 42))) makes cl-json happy. This really looks like an SBCL internal hiccup; may I suggest submitting the bug report also to sbcl-devel? best, r From daniel at dbrunner.de Wed Jun 22 08:23:48 2011 From: daniel at dbrunner.de (Daniel Brunner) Date: Wed, 22 Jun 2011 10:23:48 +0200 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT Message-ID: <4E01A694.4060303@dbrunner.de> Hi everybody, I flipped through the archives but did not find that question: I get some numbers (DOUBLE-FLOAT) from CLSQL, e.g. 0.0570714084012434D0 If I encode this to JSON I get a "0.0570714084012434D0" but it seems that the notation with "D" is not valid JSON because when I try to decode this string say from R with rjson I get an error. Any help or suggestions? Kind regards, Daniel. From boris.smilga at gmail.com Wed Jun 22 09:03:20 2011 From: boris.smilga at gmail.com (Boris Smilga) Date: Wed, 22 Jun 2011 09:03:20 +0000 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <4E01A694.4060303@dbrunner.de> References: <4E01A694.4060303@dbrunner.de> Message-ID: On Wed, Jun 22, 2011 at 8:23 AM, Daniel Brunner wrote: > I get some numbers (DOUBLE-FLOAT) from CLSQL, e.g. > > 0.0570714084012434D0 > > If I encode this to JSON I get a "0.0570714084012434D0" but it seems > that the notation with "D" is not valid JSON because when I try to > decode this string say from R with rjson I get an error. This is very strange. I get: (json:encode-json-to-string 0.0570714084012434D0) ? "0.0570714084012434" How exactly do you get your output with D? Yours, - B. Sm. From daniel at dbrunner.de Wed Jun 22 16:59:15 2011 From: daniel at dbrunner.de (Daniel Brunner) Date: Wed, 22 Jun 2011 18:59:15 +0200 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: References: <4E01A694.4060303@dbrunner.de> Message-ID: <4E021F63.2020502@dbrunner.de> Hm. I am using exact the same line of code: CL-USER> (json:encode-json-to-string 0.0570714084012434D0) "0.0570714084012434D0" I have cl-json 0.4.0 on Cluzure Common Lisp "Version 1.7-dev-r14406M-trunk (LinuxX8664)" Kind regards, Daniel Am 22.06.2011 11:03, schrieb Boris Smilga: > On Wed, Jun 22, 2011 at 8:23 AM, Daniel Brunner wrote: > >> I get some numbers (DOUBLE-FLOAT) from CLSQL, e.g. >> >> 0.0570714084012434D0 >> >> If I encode this to JSON I get a "0.0570714084012434D0" but it seems >> that the notation with "D" is not valid JSON because when I try to >> decode this string say from R with rjson I get an error. > > This is very strange. I get: > > (json:encode-json-to-string 0.0570714084012434D0) > ? "0.0570714084012434" > > How exactly do you get your output with D? > > Yours, > - B. Sm. > From rpgoldman at sift.info Wed Jun 22 21:10:44 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Wed, 22 Jun 2011 16:10:44 -0500 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <4E021F63.2020502@dbrunner.de> References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> Message-ID: <4E025A54.5060006@sift.info> On 6/22/11 Jun 22 -11:59 AM, Daniel Brunner wrote: > (json:encode-json-to-string 0.0570714084012434D0) I have replicated this error.... The bug is here: (defun write-json-number (nr stream) "Write the JSON representation of the number NR to STREAM." (typecase nr (integer (format stream "~d" nr)) (real (format stream "~f" nr)) (t (unencodable-value-error nr 'write-json-number)))) As can be seen by CL-USER> (format t "~f" 0.0570714084012434D0) 0.0570714084012434D0 NIL This suggests that we must avoid using FORMAT in translating floats to strings for JSON, or that there's a recipe for getting FORMAT to shun the D that I don't know about.... Not incredibly well thought out or tested patch: (defun write-json-number (nr stream) "Write the JSON representation of the number NR to STREAM." (typecase nr (integer (format stream "~d" nr)) (real (let* ((raw (format nil "~f" nr)) (dpos (position #\d raw :test 'char-equal))) (princ (subseq raw 0 dpos) stream))) (t (unencodable-value-error nr 'write-json-number)))) This checks for D in the output. I /believe/ that this is the only such character that can creep in, but I am far from being an expert on this. Best, r From rpgoldman at sift.info Wed Jun 22 21:16:06 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Wed, 22 Jun 2011 16:16:06 -0500 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <4E025A54.5060006@sift.info> References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> Message-ID: <4E025B96.5010806@sift.info> I have only barely remembered how to use darcs. Here's a patch file that captures the mod in the last email. R -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-for-cl-json URL: From boris.smilga at gmail.com Wed Jun 22 23:25:18 2011 From: boris.smilga at gmail.com (Boris Smilga) Date: Thu, 23 Jun 2011 03:25:18 +0400 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <4E025A54.5060006@sift.info> References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> Message-ID: <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> On 23 Jun 2011, at 01:10, Robert Goldman wrote: > On 6/22/11 Jun 22 -11:59 AM, Daniel Brunner wrote: >> (json:encode-json-to-string 0.0570714084012434D0) > > I have replicated this error.... > > The bug is here: > > (defun write-json-number (nr stream) > "Write the JSON representation of the number NR to STREAM." > (typecase nr > (integer (format stream "~d" nr)) > (real (format stream "~f" nr)) > (t (unencodable-value-error nr 'write-json-number)))) > > As can be seen by > > CL-USER> (format t "~f" 0.0570714084012434D0) > 0.0570714084012434D0 > NIL I have located it, too. Actually, it's a confusing matter bearing on the interpretation of one passage in the Common Lisp standard. To wit, the standard behaviour of the ~F formatting directive (CLHS, sec. 22.3.3.1) is to print ?a sequence of digits, containing a single embedded decimal point?. Exponent markers are never mentioned in that section. However, a little further below it tells us that ?If both w and d [prefix parameters of the directive ? B. Sm.] are omitted, then the effect is to print the value using ordinary free- format output; prin1 uses this format for any number whose magnitude is either zero or between 10^-3 (inclusive) and 10^7 (exclusive).? Now the problem is that the expression ?ordinary free-format output? has no well-defined meaning in the standard. One reasonable interpretation is that it means the same as ?output produced by print- object?. In this case, the implementer is bound by sec. 22.1.3.1.3: ?If the format of the number does not match that specified by *read- default-float-format*, then the exponent marker for that format and the digit 0 are also printed.? If we adopt this reading, then CCL does the right thing, and SBCL (which prints no exponent marker) is in violation of the standard. However, if we opt for a different interpretation (what?), then SBCL might end up compliant after all, and CCL might or might not be in violation. > This suggests that we must avoid using FORMAT in translating floats to > strings for JSON, or that there's a recipe for getting FORMAT to shun > the D that I don't know about.... I would advocate a different approach: to check the type of the float, and to bind *read-default-float-format* to the corresponding format designator: (defun write-json-number (nr stream) "Write the JSON representation of the number NR to STREAM." (typecase nr (integer (format stream "~d" nr)) (real (let ((*read-default-float-format* (typecase nr (long-float 'long-float) (double-float 'double-float) (short-float 'short-float) (t 'single-float)))) (format stream "~f" nr))) (t (unencodable-value-error nr 'write-json-number)))) > This checks for D in the output. I /believe/ that this is the only > such > character that can creep in, but I am far from being an expert on > this. There are also F, L, and S (CLHS, sec. 2.3.2.2). Yours, - B. Sm. From rpgoldman at sift.info Thu Jun 23 01:04:10 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Wed, 22 Jun 2011 20:04:10 -0500 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> Message-ID: <4E02910A.5060802@sift.info> On 6/22/11 Jun 22 -6:25 PM, Boris Smilga wrote: > (defun write-json-number (nr stream) > "Write the JSON representation of the number NR to STREAM." > (typecase nr > (integer (format stream "~d" nr)) > (real (let ((*read-default-float-format* > (typecase nr > (long-float 'long-float) > (double-float 'double-float) > (short-float 'short-float) > (t 'single-float)))) > (format stream "~f" nr))) > (t (unencodable-value-error nr 'write-json-number)))) I agree that this is better, but when I compile this in Clozure on a 64 bit Intel Mac, I get this warning: ;Compiler warnings for "/Users/rpg/lisp/cl-json/src/encoder.lisp" : ; In WRITE-JSON-NUMBER: Clause (DOUBLE-FLOAT 'DOUBLE-FLOAT) ignored in TYPECASE form - shadowed by (LONG-FLOAT 'LONG-FLOAT) Would it be better to rewrite this from shortest to longest as: (defun write-json-number (nr stream) "Write the JSON representation of the number NR to STREAM." (typecase nr (integer (format stream "~d" nr)) (real (let ((*read-default-float-format* (etypecase nr (short-float 'short-float) (single-float 'single-float) (double-float 'double-float) (long-float 'long-float)))) (format stream "~f" nr))) (t (unencodable-value-error nr 'write-json-number)))) This still yields warnings on Clozure, because SHORT-FLOAT == SINGLE-FLOAT and DOUBLE-FLOAT == LONG-FLOAT (IIUC), but I think that's implementation-dependent, so we can't do away with the intermediates in general, can we? Not sure how to muffle these warnings, or even if it's desirable, since the Clozure implementers might split apart single and short and double and long at some point, right? Best, r From boris.smilga at gmail.com Thu Jun 23 12:05:23 2011 From: boris.smilga at gmail.com (Boris Smilga) Date: Thu, 23 Jun 2011 12:05:23 +0000 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <4E02910A.5060802@sift.info> References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> <4E02910A.5060802@sift.info> Message-ID: On Thu, Jun 23, 2011 at 1:04 AM, Robert Goldman wrote: > Would it be better to rewrite this from shortest to longest as: > > (defun write-json-number (nr stream) > ?"Write the JSON representation of the number NR to STREAM." > ?(typecase nr > ? ?(integer (format stream "~d" nr)) > ? ?(real (let ((*read-default-float-format* > ? ? ? ? ? ? ? ? (etypecase nr > ? ? ? ? ? ? ? ? ? (short-float 'short-float) > ? ? ? ? ? ? ? ? ? (single-float 'single-float) > ? ? ? ? ? ? ? ? ? (double-float 'double-float) > ? ? ? ? ? ? ? ? ? (long-float 'long-float)))) > ? ? ? ? ? ?(format stream "~f" nr))) > ? ?(t (unencodable-value-error nr 'write-json-number)))) What about rationals? They too are a subtype of REAL, but your etypecase doesn't take them into account. > This still yields warnings on Clozure, because SHORT-FLOAT == > SINGLE-FLOAT and DOUBLE-FLOAT == LONG-FLOAT (IIUC), but I think that's > implementation-dependent, so we can't do away with the intermediates in > general, can we? > > Not sure how to muffle these warnings, or even if it's desirable, since > the Clozure implementers might split apart single and short and double > and long at some point, right? In principle, yes (although in practive such design choices tend to be very stable, undergoing changes only when radically different hardware architectures become available). If these warnings bother you so much, you might just use #-CCL et al. to exclude the TYPECASE clauses that cause them. Yours, - B. Sm. From rpgoldman at sift.info Thu Jun 23 14:47:41 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Thu, 23 Jun 2011 09:47:41 -0500 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> <4E02910A.5060802@sift.info> Message-ID: <4E03520D.5010209@sift.info> On 6/23/11 Jun 23 -7:05 AM, Boris Smilga wrote: > On Thu, Jun 23, 2011 at 1:04 AM, Robert Goldman wrote: >> Would it be better to rewrite this from shortest to longest as: >> >> (defun write-json-number (nr stream) >> "Write the JSON representation of the number NR to STREAM." >> (typecase nr >> (integer (format stream "~d" nr)) >> (real (let ((*read-default-float-format* >> (etypecase nr >> (short-float 'short-float) >> (single-float 'single-float) >> (double-float 'double-float) >> (long-float 'long-float)))) >> (format stream "~f" nr))) >> (t (unencodable-value-error nr 'write-json-number)))) > > What about rationals? They too are a subtype of REAL, but your > etypecase doesn't take them into account. Should we check for rationals before we check for reals (i.e., check for integer, rational, real, and then have the error case)? And presumably we should print rationals as if they are floats, correct? So we would have: (defun write-json-number (nr stream) "Write the JSON representation of the number NR to STREAM." (typecase nr (integer (format stream "~d" nr)) (rational (format stream "~f" nr)) (real (let ((*read-default-float-format* (etypecase nr (short-float 'short-float) (single-float 'single-float) (double-float 'double-float) (long-float 'long-float)))) (format stream "~f" nr))) (t (unencodable-value-error nr 'write-json-number)))) > >> This still yields warnings on Clozure, because SHORT-FLOAT == >> SINGLE-FLOAT and DOUBLE-FLOAT == LONG-FLOAT (IIUC), but I think that's >> implementation-dependent, so we can't do away with the intermediates in >> general, can we? >> >> Not sure how to muffle these warnings, or even if it's desirable, since >> the Clozure implementers might split apart single and short and double >> and long at some point, right? > > In principle, yes (although in practive such design choices tend to be > very stable, undergoing changes only when radically different hardware > architectures become available). If these warnings bother you so > much, you might just use #-CCL et al. to exclude the TYPECASE clauses > that cause them. I think in principle we should try to detect the relationship between the different float subtypes. Presumably we can do this using MOST-POSITIVE-SHORT-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, etc.., etc., etc., and that would be portable... If I get a chance, I will try to do that: looks like it will be a little cumbersome. best, r From boris.smilga at gmail.com Thu Jun 23 22:15:16 2011 From: boris.smilga at gmail.com (Boris Smilga) Date: Fri, 24 Jun 2011 02:15:16 +0400 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <4E03520D.5010209@sift.info> References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> <4E02910A.5060802@sift.info> <4E03520D.5010209@sift.info> Message-ID: On Thu, Jun 23, 2011 at 2:47 PM, Robert Goldman wrote: > On 6/23/11 Jun 23 -7:05 AM, Boris Smilga wrote: >> What about rationals? ?They too are a subtype of REAL, but your >> etypecase doesn't take them into account. > > Should we check for rationals before we check for reals (i.e., check for > integer, rational, real, and then have the error case)? ?And presumably > we should print rationals as if they are floats, correct? Certainly. Moreover, per CLHS sec. 22.3.3.1, to format a rational with ~F, it is coerced to be a single float. If *read-default-float-format* is bound to something else, we'll get an S marker: (let ((*read-default-float-format* 'double-float)) (format nil "~F" 2/3)) ? "0.6666667S0" ; Actually so in CCL. As we have no way to predict what *read-default-float-format* will be when the user calls encode-json, the invocation of format in the rational clause of typecase has to explicitly bind *read-default-float-format* to 'single-float: (defun write-json-number (nr stream) "Write the JSON representation of the number NR to STREAM." (typecase nr (integer (format stream "~d" nr)) (rational (let ((*read-default-float-format* 'single-float)) (format stream "~f" nr))) (real (let ((*read-default-float-format* (etypecase nr (short-float 'short-float) (single-float 'single-float) (double-float 'double-float) (long-float 'long-float)))) (format stream "~f" nr))) (t (unencodable-value-error nr 'write-json-number)))) Since rational is a subtype of real, we can factor the clause down into etypecase, to make the code more concise: (defun write-json-number (nr stream) "Write the JSON representation of the number NR to STREAM." (typecase nr (integer (format stream "~d" nr)) (real (let ((*read-default-float-format* (etypecase nr (short-float 'short-float) ((single-float rational) 'single-float) (double-float 'double-float) (long-float 'long-float)))) (format stream "~f" nr))) (t (unencodable-value-error nr 'write-json-number)))) This is largely the same thing which I had proposed three messages up the thread. The order of clauses doesn't matter much, because, per the definition of the system class float in CLHS sec. 12.2, ?any two of [the types short-float, single-float, double-float, and long-float] must be either disjoint types or the same type?. > I think in principle we should try to detect the relationship between > the different float subtypes. ?Presumably we can do this using > MOST-POSITIVE-SHORT-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, etc.., etc., > etc., and that would be portable... ?If I get a chance, I will try to do > that: looks like it will be a little cumbersome. Hmmm... I'm afraid I don't really get your idea. The relationship between different float types is laid down quite explicitly in the Standard (should it be called ?the Most Holy and Exalted Standard??). Checking the limits won't give us anything, as the format of the number is orthogonal to its magnitude: 3.0D0 is a double, not a single float (in implementations which have distinct double and single floats), even though its numeric value falls inside the interval between least-positive-single-float and most-positive-single-float, and can be represented by a single float (without loss of precision). Pray, what exactly are you trying to accomplish here? Yours, - B. Sm. From rpgoldman at sift.info Fri Jun 24 02:23:39 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Thu, 23 Jun 2011 21:23:39 -0500 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> <4E02910A.5060802@sift.info> <4E03520D.5010209@sift.info> Message-ID: <4E03F52B.5050101@sift.info> On 6/23/11 Jun 23 -5:15 PM, Boris Smilga wrote: > On Thu, Jun 23, 2011 at 2:47 PM, Robert Goldman wrote: >> On 6/23/11 Jun 23 -7:05 AM, Boris Smilga wrote: ..... > >> I think in principle we should try to detect the relationship between >> the different float subtypes. Presumably we can do this using >> MOST-POSITIVE-SHORT-FLOAT, MOST-POSITIVE-SINGLE-FLOAT, etc.., etc., >> etc., and that would be portable... If I get a chance, I will try to do >> that: looks like it will be a little cumbersome. > > Hmmm... I'm afraid I don't really get your idea. The relationship > between different float types is laid down quite explicitly in the > Standard (should it be called ?the Most Holy and Exalted Standard??). > Checking the limits won't give us anything, as the format of the > number is orthogonal to its magnitude: 3.0D0 is a double, not a single > float (in implementations which have distinct double and single > floats), even though its numeric value falls inside the interval > between least-positive-single-float and most-positive-single-float, > and can be represented by a single float (without loss of precision). > Pray, what exactly are you trying to accomplish here? I was going to compare, e.g., MOST-POSITIVE-SHORT-FLOAT, LEAST-NEGATIVE-SHORT-FLOAT and MOST-POSITIVE-SINGLE-FLOAT, LEAST-NEGATIVE-SINGLE-FLOAT (at compile time) to attempt to determine if SHORT-FLOAT and SINGLE-FLOAT are the same on the current implementation and possibly conditionally-compile away the SINGLE-FLOAT type, and similarly for DOUBLE- and LONG-.... I would not be checking the numeric values of the number at run-time, but the bounds on the types at compile time. Would that not work? Thanks for the help, r From ckonstanski at pippiandcarlos.com Fri Jun 24 03:55:05 2011 From: ckonstanski at pippiandcarlos.com (Carlos Konstanski) Date: Thu, 23 Jun 2011 21:55:05 -0600 Subject: [cl-json-devel] download URL 403 Message-ID: <4E040A99.2070402@pippiandcarlos.com> I cannot download cl-json because the URL is giving me a 403. Please help, I am desperate! Email me a tarball if it can't be fixed soon. Thanks, Carlos Konstanski From rpgoldman at sift.info Fri Jun 24 23:58:30 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Fri, 24 Jun 2011 18:58:30 -0500 Subject: [cl-json-devel] download URL 403 In-Reply-To: <4E040A99.2070402@pippiandcarlos.com> References: <4E040A99.2070402@pippiandcarlos.com> Message-ID: <4E0524A6.3080801@sift.info> On 6/23/11 Jun 23 -10:55 PM, Carlos Konstanski wrote: > I cannot download cl-json because the URL is giving me a 403. Please help, I > am desperate! Email me a tarball if it can't be fixed soon. > I see the same problem you see trying to download the tarball. I don't know if anyone is still maintaining this project. I would recommend pulling the darcs repository. Does anyone know if anyone still reading this list has write access to the darcs repo? cheers, r From ckonstanski at pippiandcarlos.com Sat Jun 25 00:02:21 2011 From: ckonstanski at pippiandcarlos.com (Carlos Konstanski) Date: Fri, 24 Jun 2011 18:02:21 -0600 Subject: [cl-json-devel] download URL 403 In-Reply-To: <4E0524A6.3080801@sift.info> References: <4E040A99.2070402@pippiandcarlos.com> <4E0524A6.3080801@sift.info> Message-ID: <4E05258D.2030601@pippiandcarlos.com> On 06/24/2011 05:58 PM, Robert Goldman wrote: > On 6/23/11 Jun 23 -10:55 PM, Carlos Konstanski wrote: >> I cannot download cl-json because the URL is giving me a 403. Please help, I >> am desperate! Email me a tarball if it can't be fixed soon. >> > > I see the same problem you see trying to download the tarball. I don't > know if anyone is still maintaining this project. I would recommend > pulling the darcs repository. > > Does anyone know if anyone still reading this list has write access to > the darcs repo? > > cheers, > r I went ahead and did just that. Be advised that the latest in darcs is utterly broken. Version 0.3.0 works, but you need to rename all references to the package js:: to parenscript::. There is only one such reference, and it is in encoder.lisp. Thanks! Carlos From rpgoldman at sift.info Sat Jun 25 03:20:14 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Fri, 24 Jun 2011 22:20:14 -0500 Subject: [cl-json-devel] download URL 403 In-Reply-To: <4E05258D.2030601@pippiandcarlos.com> References: <4E040A99.2070402@pippiandcarlos.com> <4E0524A6.3080801@sift.info> <4E05258D.2030601@pippiandcarlos.com> Message-ID: <4E0553EE.3010801@sift.info> On 6/24/11 Jun 24 -7:02 PM, Carlos Konstanski wrote: > On 06/24/2011 05:58 PM, Robert Goldman wrote: >> On 6/23/11 Jun 23 -10:55 PM, Carlos Konstanski wrote: >>> I cannot download cl-json because the URL is giving me a 403. Please help, I >>> am desperate! Email me a tarball if it can't be fixed soon. >>> >> >> I see the same problem you see trying to download the tarball. I don't >> know if anyone is still maintaining this project. I would recommend >> pulling the darcs repository. >> >> Does anyone know if anyone still reading this list has write access to >> the darcs repo? >> >> cheers, >> r > > I went ahead and did just that. Be advised that the latest in darcs is > utterly broken. Version 0.3.0 works, but you need to rename all references > to the package js:: to parenscript::. There is only one such reference, and > it is in encoder.lisp. I have a slightly modified version that I am calling 0.4.1 that is not very broken and definitely doesn't have package problems. If no one can do any better, I will push this to Cliki... When I run the tests, both Clozure and SBCL break on JSON-BIND-IN-BIND-BUG. Clozure also breaks on 5 other tests with problems with the binding of *JSON-TEST-FILES-PATH*. I will look into this. I have no idea why this doesn't work on Clozure, but works on SBCL.... From ckonstanski at pippiandcarlos.com Sat Jun 25 04:00:58 2011 From: ckonstanski at pippiandcarlos.com (Carlos Konstanski) Date: Fri, 24 Jun 2011 22:00:58 -0600 Subject: [cl-json-devel] download URL 403 In-Reply-To: <4E0553EE.3010801@sift.info> References: <4E040A99.2070402@pippiandcarlos.com> <4E0524A6.3080801@sift.info> <4E05258D.2030601@pippiandcarlos.com> <4E0553EE.3010801@sift.info> Message-ID: <4E055D7A.1020300@pippiandcarlos.com> On 06/24/2011 09:20 PM, Robert Goldman wrote: > On 6/24/11 Jun 24 -7:02 PM, Carlos Konstanski wrote: >> On 06/24/2011 05:58 PM, Robert Goldman wrote: >>> On 6/23/11 Jun 23 -10:55 PM, Carlos Konstanski wrote: >>>> I cannot download cl-json because the URL is giving me a 403. Please help, I >>>> am desperate! Email me a tarball if it can't be fixed soon. >>>> >>> >>> I see the same problem you see trying to download the tarball. I don't >>> know if anyone is still maintaining this project. I would recommend >>> pulling the darcs repository. >>> >>> Does anyone know if anyone still reading this list has write access to >>> the darcs repo? >>> >>> cheers, >>> r >> >> I went ahead and did just that. Be advised that the latest in darcs is >> utterly broken. Version 0.3.0 works, but you need to rename all references >> to the package js:: to parenscript::. There is only one such reference, and >> it is in encoder.lisp. > > I have a slightly modified version that I am calling 0.4.1 that is not > very broken and definitely doesn't have package problems. If no one can > do any better, I will push this to Cliki... > > When I run the tests, both Clozure and SBCL break on > JSON-BIND-IN-BIND-BUG. Clozure also breaks on 5 other tests with > problems with the binding of *JSON-TEST-FILES-PATH*. I will look into > this. I have no idea why this doesn't work on Clozure, but works on > SBCL.... Much appreciated! From boris.smilga at gmail.com Sat Jun 25 06:24:14 2011 From: boris.smilga at gmail.com (Boris Smilga) Date: Sat, 25 Jun 2011 10:24:14 +0400 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <4E03F52B.5050101@sift.info> References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> <4E02910A.5060802@sift.info> <4E03520D.5010209@sift.info> <4E03F52B.5050101@sift.info> Message-ID: On Fri, Jun 24, 2011 at 2:23 AM, Robert Goldman wrote: > I was going to compare, e.g., MOST-POSITIVE-SHORT-FLOAT, > LEAST-NEGATIVE-SHORT-FLOAT and MOST-POSITIVE-SINGLE-FLOAT, > LEAST-NEGATIVE-SINGLE-FLOAT (at compile time) to attempt to determine if > SHORT-FLOAT and SINGLE-FLOAT are the same on the current implementation > and possibly conditionally-compile away the SINGLE-FLOAT type, and > similarly for DOUBLE- and LONG-.... > > I would not be checking the numeric values of the number at run-time, > but the bounds on the types at compile time. ?Would that not work? Ah, yes, now I see. But then you might just write it straightforwardly as (subtypep 'short-float 'single-float), or vice versa. Since subtypes of float are either disjoint or synonymous, subtypep in this context effectively tests the types for equality. Still, I doubt the intended effect is worth the trouble. Having superfluous clauses in typecase is explicitly allowed: ?[...] is permissible for more than one clause to specify a matching type? (CLHS 5.3, definition of TYPECASE et al.) In fact, by trying to get rid of them beforehand we would be (re)doing the compiler's job. E. g., CCL eliminates them right there at macro expansion time: (macroexpand '(typecase foo (short-float #\S) (long-float #\L) (single-float #\F) (double-float #\D))) ? (LET ((#:G4 FOO)) (DECLARE (IGNORABLE #:G4)) (COND ((TYPEP #:G4 'SHORT-FLOAT) NIL #\S) ((TYPEP #:G4 'LONG-FLOAT) NIL #\L))) Are we going to such lengths just in order to get rid of annoying warnings in a single implementation? Yours, - B. Sm. From rpgoldman at sift.info Sat Jun 25 14:31:09 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 25 Jun 2011 09:31:09 -0500 Subject: [cl-json-devel] Who owns CL-JSON now? Message-ID: <4E05F12D.70707@sift.info> Does anyone on the list know who has commit rights on this project? thx, r From boris.smilga at gmail.com Sat Jun 25 14:41:42 2011 From: boris.smilga at gmail.com (Boris Smilga) Date: Sat, 25 Jun 2011 18:41:42 +0400 Subject: [cl-json-devel] Who owns CL-JSON now? In-Reply-To: <4E05F12D.70707@sift.info> References: <4E05F12D.70707@sift.info> Message-ID: <17FB7C90-5B15-4A4F-BC7D-B31891E9B957@gmail.com> On 25 Jun 2011, at 18:31, Robert Goldman wrote: > Does anyone on the list know who has commit rights on this project? Henrik Hjelte certainly does. I'm not aware of any other maintainers. - B. Sm. From rpgoldman at sift.info Sat Jun 25 15:01:05 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 25 Jun 2011 10:01:05 -0500 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> <4E02910A.5060802@sift.info> <4E03520D.5010209@sift.info> <4E03F52B.5050101@sift.info> Message-ID: <4E05F831.2000902@sift.info> On 6/25/11 Jun 25 -1:24 AM, Boris Smilga wrote: > On Fri, Jun 24, 2011 at 2:23 AM, Robert Goldman wrote: > >> I was going to compare, e.g., MOST-POSITIVE-SHORT-FLOAT, >> LEAST-NEGATIVE-SHORT-FLOAT and MOST-POSITIVE-SINGLE-FLOAT, >> LEAST-NEGATIVE-SINGLE-FLOAT (at compile time) to attempt to determine if >> SHORT-FLOAT and SINGLE-FLOAT are the same on the current implementation >> and possibly conditionally-compile away the SINGLE-FLOAT type, and >> similarly for DOUBLE- and LONG-.... >> >> I would not be checking the numeric values of the number at run-time, >> but the bounds on the types at compile time. Would that not work? > > Ah, yes, now I see. But then you might just write it > straightforwardly as (subtypep 'short-float 'single-float), or vice > versa. Since subtypes of float are either disjoint or synonymous, > subtypep in this context effectively tests the types for equality. > > Still, I doubt the intended effect is worth the trouble. Having > superfluous clauses in typecase is explicitly allowed: ?[...] is > permissible for more than one clause to specify a matching type? (CLHS > 5.3, definition of TYPECASE et al.) In fact, by trying to get rid of > them beforehand we would be (re)doing the compiler's job. E. g., CCL > eliminates them right there at macro expansion time: > > (macroexpand > '(typecase foo > (short-float #\S) (long-float #\L) (single-float #\F) (double-float #\D))) > ? (LET ((#:G4 FOO)) > (DECLARE (IGNORABLE #:G4)) > (COND ((TYPEP #:G4 'SHORT-FLOAT) NIL #\S) > ((TYPEP #:G4 'LONG-FLOAT) NIL #\L))) > > Are we going to such lengths just in order to get rid of annoying > warnings in a single implementation? Yes. If these were simply style warnings, then I would agree with you. However, they are not --- they are real, bona fide warnings, causing COMPILE-FILE failure: ;Compiler warnings for "home:lisp;cl-json;src;encoder.lisp.newest" : ; In WRITE-JSON-NUMBER: Clause (SINGLE-FLOAT 'SINGLE-FLOAT) ignored in ETYPECASE form - shadowed by (SHORT-FLOAT 'SHORT-FLOAT) . ; In WRITE-JSON-NUMBER: Clause (LONG-FLOAT 'LONG-FLOAT) ignored in ETYPECASE form - shadowed by (DOUBLE-FLOAT 'DOUBLE-FLOAT) . ; Warning: COMPILE-FILE warned while performing # on #. ; While executing: #, in process repl-thread(10). ; Warning: COMPILE-FILE failed while performing # on #. ; While executing: #, in process repl-thread(10). So I think these warnings must die. I am inclined to think that these should simply be STYLE-WARNINGs, but CCL does not agree with me. Best, r From rpgoldman at sift.info Sat Jun 25 16:14:18 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 25 Jun 2011 11:14:18 -0500 Subject: [cl-json-devel] download URL 403 In-Reply-To: <4E055D7A.1020300@pippiandcarlos.com> References: <4E040A99.2070402@pippiandcarlos.com> <4E0524A6.3080801@sift.info> <4E05258D.2030601@pippiandcarlos.com> <4E0553EE.3010801@sift.info> <4E055D7A.1020300@pippiandcarlos.com> Message-ID: <4E06095A.4050107@sift.info> For lack of anything better in the short term, I have applied Boris Smilga's fixes, with a tweak to kill the warnings on CCL, and published a new darcs repo at: darcs get http://rpgoldman.real-time.com/lisp/cl-json.darcs WARNING: I am nearly completely incompetent with darcs. Let me know if this works for you --- I just used darcs push and then dumped this onto my personal web site. The only testing done was to see if the above darcs get crashed. I hope this will be sufficient as a short term expedient for people to be able to fetch a version of CL-JSON with working numerical encoding until something can get straightened out with the common-lisp.net repo. I suppose we could update the cliki with a new release, too. Cheers, r From rpgoldman at sift.info Sat Jun 25 16:18:21 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 25 Jun 2011 11:18:21 -0500 Subject: [cl-json-devel] Who owns CL-JSON now? In-Reply-To: <17FB7C90-5B15-4A4F-BC7D-B31891E9B957@gmail.com> References: <4E05F12D.70707@sift.info> <17FB7C90-5B15-4A4F-BC7D-B31891E9B957@gmail.com> Message-ID: <4E060A4D.2050409@sift.info> On 6/25/11 Jun 25 -9:41 AM, Boris Smilga wrote: > On 25 Jun 2011, at 18:31, Robert Goldman wrote: > >> Does anyone on the list know who has commit rights on this project? > > Henrik Hjelte certainly does. > I'm not aware of any other maintainers. Wonder if it should become an organizing principle at c-l.net to never have a single-maintainer project. I.e., there should always be at least two, to ease recovery if one person is unavailable for a while.... cheers, r From hans.huebner at gmail.com Sat Jun 25 16:30:46 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sat, 25 Jun 2011 18:30:46 +0200 Subject: [cl-json-devel] Who owns CL-JSON now? In-Reply-To: <4E060A4D.2050409@sift.info> References: <4E05F12D.70707@sift.info> <17FB7C90-5B15-4A4F-BC7D-B31891E9B957@gmail.com> <4E060A4D.2050409@sift.info> Message-ID: On Sat, Jun 25, 2011 at 6:18 PM, Robert Goldman wrote: > Wonder if it should become an organizing principle at c-l.net to never > have a single-maintainer project. ?I.e., there should always be at least > two, to ease recovery if one person is unavailable for a while.... This won't fly, but if there is a project which is unmaintained and the former maintainer has been unresponsive for a while (say four to six weeks), send email to admin at common-lisp.net to request becoming a maintainer. -Hans From boris.smilga at gmail.com Sat Jun 25 16:41:05 2011 From: boris.smilga at gmail.com (Boris Smilga) Date: Sat, 25 Jun 2011 20:41:05 +0400 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <4E05F831.2000902@sift.info> References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> <4E02910A.5060802@sift.info> <4E03520D.5010209@sift.info> <4E03F52B.5050101@sift.info> <4E05F831.2000902@sift.info> Message-ID: <933504E4-3E1E-491D-B494-D3D5DF272764@gmail.com> On 25 Jun 2011, at 19:01, Robert Goldman wrote: > I am inclined to think that these should simply be STYLE-WARNINGs, but > CCL does not agree with me. CCL seems to be in breach of the standard in this case. I have opened a ticket on their Trac, see http://trac.clozure.com/ccl/ticket/ 872 . A compliant application, I believe, should expect a STYLE- WARNING here; a SIMPLE-WARNING should be considered an implementation quirk. Yours, - B. Sm. From ckonstanski at pippiandcarlos.com Sat Jun 25 18:36:20 2011 From: ckonstanski at pippiandcarlos.com (Carlos Konstanski) Date: Sat, 25 Jun 2011 12:36:20 -0600 Subject: [cl-json-devel] download URL 403 In-Reply-To: <4E06095A.4050107@sift.info> References: <4E040A99.2070402@pippiandcarlos.com> <4E0524A6.3080801@sift.info> <4E05258D.2030601@pippiandcarlos.com> <4E0553EE.3010801@sift.info> <4E055D7A.1020300@pippiandcarlos.com> <4E06095A.4050107@sift.info> Message-ID: <4E062AA4.6090108@pippiandcarlos.com> On 06/25/2011 10:14 AM, Robert Goldman wrote: > For lack of anything better in the short term, I have applied Boris > Smilga's fixes, with a tweak to kill the warnings on CCL, and published > a new darcs repo at: > > darcs get http://rpgoldman.real-time.com/lisp/cl-json.darcs > > WARNING: I am nearly completely incompetent with darcs. Let me know if > this works for you --- I just used darcs push and then dumped this onto > my personal web site. The only testing done was to see if the above > darcs get crashed. > > I hope this will be sufficient as a short term expedient for people to > be able to fetch a version of CL-JSON with working numerical encoding > until something can get straightened out with the common-lisp.net repo. > > I suppose we could update the cliki with a new release, too. > > Cheers, > r I am in your debt. Does this also work with modern parenscript? I mean encoder.lisp and its outdated use of the #:js package when it should use #:parenscript? That would be a nice touch. Thanks again, Carlos From ckonstanski at pippiandcarlos.com Sat Jun 25 18:41:29 2011 From: ckonstanski at pippiandcarlos.com (Carlos Konstanski) Date: Sat, 25 Jun 2011 12:41:29 -0600 Subject: [cl-json-devel] download URL 403 In-Reply-To: <4E06095A.4050107@sift.info> References: <4E040A99.2070402@pippiandcarlos.com> <4E0524A6.3080801@sift.info> <4E05258D.2030601@pippiandcarlos.com> <4E0553EE.3010801@sift.info> <4E055D7A.1020300@pippiandcarlos.com> <4E06095A.4050107@sift.info> Message-ID: <4E062BD9.9070709@pippiandcarlos.com> On 06/25/2011 10:14 AM, Robert Goldman wrote: > For lack of anything better in the short term, I have applied Boris > Smilga's fixes, with a tweak to kill the warnings on CCL, and published > a new darcs repo at: > > darcs get http://rpgoldman.real-time.com/lisp/cl-json.darcs > > WARNING: I am nearly completely incompetent with darcs. Let me know if > this works for you --- I just used darcs push and then dumped this onto > my personal web site. The only testing done was to see if the above > darcs get crashed. > > I hope this will be sufficient as a short term expedient for people to > be able to fetch a version of CL-JSON with working numerical encoding > until something can get straightened out with the common-lisp.net repo. > > I suppose we could update the cliki with a new release, too. > > Cheers, > r Never mind. I just checked out your repo, and I see no reference to parenscript whatsoever. Even better! Carlos From boris.smilga at gmail.com Sun Jun 26 21:10:33 2011 From: boris.smilga at gmail.com (Boris Smilga) Date: Mon, 27 Jun 2011 01:10:33 +0400 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <933504E4-3E1E-491D-B494-D3D5DF272764@gmail.com> References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> <4E02910A.5060802@sift.info> <4E03520D.5010209@sift.info> <4E03F52B.5050101@sift.info> <4E05F831.2000902@sift.info> <933504E4-3E1E-491D-B494-D3D5DF272764@gmail.com> Message-ID: <23722A59-D225-4266-BB8A-D95FA4182EBC@gmail.com> On 25 Jun 2011, at 20:41, Boris Smilga wrote: > CCL seems to be in breach of the standard in this case. I have > opened a ticket on their Trac, see http://trac.clozure.com/ccl/ > ticket/872 . A compliant application, I believe, should expect a > STYLE-WARNING here; a SIMPLE-WARNING should be considered an > implementation quirk. Just to keep you informed: our colleagues over at Clozure had the warning type fixed to some subtype of style-warning. So, we may count on correct behaviour in the repository version and future releases of CCL. Yours, - B. Sm. From henrik at evahjelte.com Mon Jun 27 08:21:04 2011 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 27 Jun 2011 10:21:04 +0200 Subject: [cl-json-devel] download URL 403 In-Reply-To: <4E05258D.2030601@pippiandcarlos.com> References: <4E040A99.2070402@pippiandcarlos.com> <4E0524A6.3080801@sift.info> <4E05258D.2030601@pippiandcarlos.com> Message-ID: On Sat, Jun 25, 2011 at 2:02 AM, Carlos Konstanski wrote: > On 06/24/2011 05:58 PM, Robert Goldman wrote: >> On 6/23/11 Jun 23 -10:55 PM, Carlos Konstanski wrote: >>> I cannot download cl-json because the URL is giving me a 403. Please help, I >>> am desperate! Email me a tarball if it can't be fixed soon. This was because the release version used to sit in the ftp directory of common-lisp.net, but now that directory seems gone. And since I haven't seen this before, this might have been the situation for a long time. The new version 0.4.1 is downloadable though if you really don't want to use darcs. > I went ahead and did just that. Be advised that the latest in darcs is > utterly broken. What is utterly broken? Some more details could help. I think the test code coverage is very high, and there is only one know failing test, so I have no idea what you mean with utterly broken. Also it would be good for the next time if you find any problems, that you mention them to the mailing list when you discover them. Version 0.3.0 works, but you need to rename all references > to the package js:: to parenscript::. There is only one such reference, and > it is in encoder.lisp. Works in what way that the latest in darcs does not? The dependency to parenscript was removed in december 2008, it is not something new. /Henrik From henrik at evahjelte.com Mon Jun 27 08:35:40 2011 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 27 Jun 2011 10:35:40 +0200 Subject: [cl-json-devel] download URL 403 In-Reply-To: <4E06095A.4050107@sift.info> References: <4E040A99.2070402@pippiandcarlos.com> <4E0524A6.3080801@sift.info> <4E05258D.2030601@pippiandcarlos.com> <4E0553EE.3010801@sift.info> <4E055D7A.1020300@pippiandcarlos.com> <4E06095A.4050107@sift.info> Message-ID: On Sat, Jun 25, 2011 at 6:14 PM, Robert Goldman wrote: > For lack of anything better in the short term, I have applied Boris > Smilga's fixes, with a tweak to kill the warnings on CCL, and published > a new darcs repo at: > > darcs get http://rpgoldman.real-time.com/lisp/cl-json.darcs > > WARNING: ?I am nearly completely incompetent with darcs. ?Let me know if > this works for you --- I just used darcs push and then dumped this onto > my personal web site. ?The only testing done was to see if the above > darcs get crashed. Worked perfectly, darcs is really that easy. I have taken your patches and applied them to the main repo. Also I have made a new downloadable tarball 0.4.1 and linked from cliki so it might even be asdf-installable if anyone still uses that. Also I have updated the html-page to mention the new release. If anyone wants commit rights, mail me your common-lisp.net usernames and I can request that you are added. Sorry for being absent from the discussions for a few days. I still think I am one of people that are maintaining this software, but I want to encourage people to report bugs and missing links and whatever to the mailing list. It makes it easier to fix problems if they are reported. Thanks Boris and Robert for sorting out the floating point encoding issues. /Henrik From daniel at dbrunner.de Mon Jun 27 08:48:35 2011 From: daniel at dbrunner.de (Daniel Brunner) Date: Mon, 27 Jun 2011 10:48:35 +0200 Subject: [cl-json-devel] download URL 403 In-Reply-To: References: <4E040A99.2070402@pippiandcarlos.com> <4E0524A6.3080801@sift.info> <4E05258D.2030601@pippiandcarlos.com> <4E0553EE.3010801@sift.info> <4E055D7A.1020300@pippiandcarlos.com> <4E06095A.4050107@sift.info> Message-ID: <4E0843E3.7060705@dbrunner.de> Yes. Thanks to all for the fast help with the floating point issue. You helped me a lot. Daniel > Worked perfectly, darcs is really that easy. I have taken your patches > and applied them to the main repo. Also I have made a new downloadable > tarball 0.4.1 and linked from cliki so it might even be > asdf-installable if anyone still uses that. Also I have updated the > html-page to mention the new release. > > If anyone wants commit rights, mail me your common-lisp.net usernames > and I can request that you are added. > > Sorry for being absent from the discussions for a few days. I still > think I am one of people that are maintaining this software, but I > want to encourage people to report bugs and missing links and whatever > to the mailing list. It makes it easier to fix problems if they are > reported. > > Thanks Boris and Robert for sorting out the floating point encoding issues. > > /Henrik From rpgoldman at sift.info Mon Jun 27 13:29:38 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Mon, 27 Jun 2011 08:29:38 -0500 Subject: [cl-json-devel] download URL 403 In-Reply-To: References: <4E040A99.2070402@pippiandcarlos.com> <4E0524A6.3080801@sift.info> <4E05258D.2030601@pippiandcarlos.com> <4E0553EE.3010801@sift.info> <4E055D7A.1020300@pippiandcarlos.com> <4E06095A.4050107@sift.info> Message-ID: <4E0885C2.6010602@sift.info> On 6/27/11 Jun 27 -3:35 AM, Henrik Hjelte wrote: > On Sat, Jun 25, 2011 at 6:14 PM, Robert Goldman wrote: >> For lack of anything better in the short term, I have applied Boris >> Smilga's fixes, with a tweak to kill the warnings on CCL, and published >> a new darcs repo at: >> >> darcs get http://rpgoldman.real-time.com/lisp/cl-json.darcs >> >> WARNING: I am nearly completely incompetent with darcs. Let me know if >> this works for you --- I just used darcs push and then dumped this onto >> my personal web site. The only testing done was to see if the above >> darcs get crashed. > > Worked perfectly, darcs is really that easy. I have taken your patches > and applied them to the main repo. Also I have made a new downloadable > tarball 0.4.1 and linked from cliki so it might even be > asdf-installable if anyone still uses that. Also I have updated the > html-page to mention the new release. > > If anyone wants commit rights, mail me your common-lisp.net usernames > and I can request that you are added. > > Sorry for being absent from the discussions for a few days. I still > think I am one of people that are maintaining this software, but I > want to encourage people to report bugs and missing links and whatever > to the mailing list. It makes it easier to fix problems if they are > reported. > > Thanks Boris and Robert for sorting out the floating point encoding issues. > Thanks to YOU, Henrik, for maintaining this very nice software! Glad to hear that you are monitoring the list... Best regards, R From rpgoldman at sift.info Mon Jun 27 15:16:07 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Mon, 27 Jun 2011 10:16:07 -0500 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <23722A59-D225-4266-BB8A-D95FA4182EBC@gmail.com> References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> <4E02910A.5060802@sift.info> <4E03520D.5010209@sift.info> <4E03F52B.5050101@sift.info> <4E05F831.2000902@sift.info> <933504E4-3E1E-491D-B494-D3D5DF272764@gmail.com> <23722A59-D225-4266-BB8A-D95FA4182EBC@gmail.com> Message-ID: <4E089EB7.3020702@sift.info> On 6/26/11 Jun 26 -4:10 PM, Boris Smilga wrote: > > On 25 Jun 2011, at 20:41, Boris Smilga wrote: > >> CCL seems to be in breach of the standard in this case. I have opened >> a ticket on their Trac, see http://trac.clozure.com/ccl/ticket/872 . >> A compliant application, I believe, should expect a STYLE-WARNING >> here; a SIMPLE-WARNING should be considered an implementation quirk. > > Just to keep you informed: our colleagues over at Clozure had the > warning type fixed to some subtype of style-warning. So, we may count > on correct behaviour in the repository version and future releases of CCL. I agree that fixing this will be A Good Thing, but even when it is fixed, I don't believe that a library should emit even a STYLE-WARNING, if at all possible. So I think it would be best for us either to keep the expedient I have put in (which I concede is not elegant), or to muffle any warnings about unnecessary typecase branches (since they are compiled away, anyhow). I am not a believer in leaving warnings around, because if one starts to leave benign ones around, one gets in the habit of ignoring them, and ends up missing warnings that indicate real problems.... best, r From boris.smilga at gmail.com Mon Jun 27 15:50:31 2011 From: boris.smilga at gmail.com (Boris Smilga) Date: Mon, 27 Jun 2011 15:50:31 +0000 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: <4E089EB7.3020702@sift.info> References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> <4E02910A.5060802@sift.info> <4E03520D.5010209@sift.info> <4E03F52B.5050101@sift.info> <4E05F831.2000902@sift.info> <933504E4-3E1E-491D-B494-D3D5DF272764@gmail.com> <23722A59-D225-4266-BB8A-D95FA4182EBC@gmail.com> <4E089EB7.3020702@sift.info> Message-ID: On Mon, Jun 27, 2011 at 3:16 PM, Robert Goldman wrote: > I am not a believer in leaving warnings around, because if one starts to > leave benign ones around, one gets in the habit of ignoring them, and > ends up missing warnings that indicate real problems.... Actually, that's what the *formal* distinction between style-warning and other kinds of warnings is all about. To quote the standard once again: ?In general, the question of whether code is faulty or substandard is a subjective decision to be made by the facility processing that code. The intent is that whenever such a facility wishes to complain about code on such subjective grounds, it should use this condition type so that any clients who wish to redirect or muffle superfluous warnings can do so without risking that they will be redirecting or muffling other, more serious warnings.? This is probably out of scope of this mailing list, though. Yours, - B. Sm. From rpgoldman at sift.info Mon Jun 27 16:05:53 2011 From: rpgoldman at sift.info (Robert Goldman) Date: Mon, 27 Jun 2011 11:05:53 -0500 Subject: [cl-json-devel] Encoding DOUBLE-FLOAT In-Reply-To: References: <4E01A694.4060303@dbrunner.de> <4E021F63.2020502@dbrunner.de> <4E025A54.5060006@sift.info> <94F9F92E-317C-4D0E-BD06-93E6C0B1F206@gmail.com> <4E02910A.5060802@sift.info> <4E03520D.5010209@sift.info> <4E03F52B.5050101@sift.info> <4E05F831.2000902@sift.info> <933504E4-3E1E-491D-B494-D3D5DF272764@gmail.com> <23722A59-D225-4266-BB8A-D95FA4182EBC@gmail.com> <4E089EB7.3020702@sift.info> Message-ID: <4E08AA61.7060208@sift.info> On 6/27/11 Jun 27 -10:50 AM, Boris Smilga wrote: > On Mon, Jun 27, 2011 at 3:16 PM, Robert Goldman wrote: >> I am not a believer in leaving warnings around, because if one starts to >> leave benign ones around, one gets in the habit of ignoring them, and >> ends up missing warnings that indicate real problems.... > > Actually, that's what the *formal* distinction between style-warning > and other kinds of warnings is all about. To quote the standard once > again: > > ?In general, the question of whether code is faulty or substandard > is a subjective decision to be made by the facility processing that > code. The intent is that whenever such a facility wishes to complain > about code on such subjective grounds, it should use this condition > type so that any clients who wish to redirect or muffle superfluous > warnings can do so without risking that they will be redirecting or > muffling other, more serious warnings.? > > This is probably out of scope of this mailing list, though. Right. That suggests that when the new CCL comes out, we could simply muffle the style warnings in encode-json-nr, and rip out my laborious typecase minimizing #+ and #-'s... Indeed, probably we could take what I've got now and wrap parts of it in #+(and CCL (not CCL-1.7)) then add some #+CCL-1.7 that would take care of muffling the style-warnings from compiling encode-json-nr Cheers, r