IRC channel logs


back to list of logs

<nalaginrut>morning guilers~
***_zxq9_ is now known as zxq9
<dsmith-work>Morning Greetings, Guilers
<wingo>guile-jpeg now encodes and decodes and has a not terrible api
<wingo>next step is lossless transformations like transpose, flip, etc
<davexunit>wingo: that (jpeg array) module, wow.
<davexunit>cool stuff.
<taylanub>can one really transpose/flip/etc. JPG without loss?
<taylanub>well that was google-able. TIL.
<ArneBab>wingo: nice!
<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
<wingo>guile-jpeg, i mean
<unknown_lamer>guile in gimp would be nice
<unknown_lamer>except script-fu's api is horrendous
<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
<unknown_lamer>better than bare C, but not by much ;)
<stis>hej guilers!
<dsmith-work>stis: Hej hej
<dsmith-work>unknown_lamer: Did you ever see Brief? (dos text editor)
<unknown_lamer>don't think so
<dsmith-work>It had a macro language that was "lisp"
<dsmith-work>Basicaly it was just paren syntax function calls.
<dsmith-work>The only funtions were the things normally bound to keystrokes.
<dsmith-work>Nothin low level.
<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!
<davexunit>ArneBab: congrats!
<ArneBab>davexunit: thanks!
<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 wonder what R6RS says about this, if anything.
*mark_weaver looks
<mark_weaver>I suppose that +inf.0 (or -inf.0) is the right thing to do.
<mark_weaver>s/that/that returning/
<taylanub>I have a trivial patch already; should I send it or will you do it together with a refactoring?
<mark_weaver>taylanub: what does your patch do?
<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>yeah, that's not really the right fix.
<mark_weaver>for one thing, if the number is prefixed by #e, it should actually try to create the exact number.
<mark_weaver>I'll incorporate a fix for this problem into the preliminary patch I have for
<mark_weaver>(which also includes some other refactoring)
<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 :)
<mark_weaver>okay, thanks for reporting the problem!