***_zxq9_ is now known as zxq9
<wingo>guile-jpeg now encodes and decodes and has a not terrible api <wingo>next step is lossless transformations like transpose, flip, etc <taylanub>can one really transpose/flip/etc. JPG without loss? <wingo>taylanub: so yes, as you found, but i think only libjpeg's jpegtran can do it <wingo>at least i don't know of others <wingo>i'd call it dog-slow but that would be offensive to dogs <unknown_lamer>you can really, really, *really* tell it was the work of C programmers who thought scheme was "cool" and did not get scheme at all <dsmith-work>unknown_lamer: Did you ever see Brief? (dos text editor) <dsmith-work>The only funtions were the things normally bound to keystrokes. <dsmith-work>And all the code use C-style closing braces for the closing parens. <dsmith-work>IT's scripting was about the same or less than emacs macro recording. ***fangism-at-llvm is now known as fangism
<ArneBab>wisp-scheme now passes the wisp testsuite! <ArneBab>this is quite a big step for me, because now wisp uses (read) for all non-specific syntax. <ArneBab>⇒ maintenance work should be much lower <ArneBab>and this should be fit for being included in an SRFI <ArneBab>(string-parsing was a hell - kudos to the folks who wrote that for guile! ☺) <taylanub>hm, anyone know if there's a good reason to error on a number with a too-high exponent, like say 3e12345, instead of returning infinite? most other Scheme systems seem to return infinite. <taylanub>at first I thought it's a bug but the code does it explicitly and there's even a test for it in the test-suite (to ensure it errors) <ijp>taylanub: because 3e12345 is not infinite? <ijp>it's not clear to me that either behaviour is really better <taylanub>numbers with exponents are inexact anyway, and isn't +inf.0 the "go to" value for "too big," or is it just for division by zero and such?.. not sure. in any case R7RS says that string->number should never raise an error due to the contents of its string argument, which also kind of makes sense... <taylanub>one could always wrap it in a handler each time it's given arbitrary input, but it already returns #f for bad input, so that would be weird <mark_weaver>taylanub: I agree that the current behavior isn't right, but I'm torn on what to do. <mark_weaver>returning #f has the problem that currently, anything that starts like a number and 'string->number' returns #f for is considered a valid symbol by 'read'. <mark_weaver>which frankly, I already don't like, but it's what we have. <mark_weaver>as for returning +inf.0, I don't really like that either, but it's made worse by the fact that 'string->number' always creates an exact number first, and only converts it to inexact as the last step, if appropriate. <mark_weaver>and if we don't have a limit on the exponent, then memory could be exhausted trying to represent the number exactly. <taylanub>FWIW Racket, Gambit, Gauche, and Chibi (all I tested) return +inf.0. Chicken does so when the "numbers egg" is loaded (and otherwise indeed considers it a symbol) <mark_weaver>+inf.0 may well be the appropriate result, but I'd like to mull it over some more. <mark_weaver>and it may call for some refactoring of the string->number code <mark_weaver>I suppose that +inf.0 (or -inf.0) is the right thing to do. <taylanub>I have a trivial patch already; should I send it or will you do it together with a refactoring? <taylanub>mark_weaver: in mem2decimal_from_point, at the if statement where it normally raises the error, it sets result to scm_inf() instead, putting the remaining lines into an else. <taylanub>oh, I should probably take the 'x = INEXACT;' out of that else... <mark_weaver>for one thing, if the number is prefixed by #e, it should actually try to create the exact number. <mark_weaver>I guess this will involve changing the interface to mem2decimal_from_point <mark_weaver>probably the exponent shouldn't be incorporated into the number until it's time to convert it to inexact, and at that point some special cases should check for a huge exponent if the number is to be made inexact. <taylanub>ah yes, after my patch it still errors on e.g. #e3e12345. will leave it to you then :)