IRC channel logs

2013-04-01.log

back to list of logs

<cky>So, I've finished implementing SRFI 45 promises. Let's run the tests and ensure they still work. :-)
***zacts` is now known as zacts
<mark_weaver>cky: did it pass the tests?
***zacts` is now known as zacts
<ijp>morning
<ijp>taylanub: I have a tagged version of shift-reset that I use, similar to how racket has shift-of/reset-of
<ijp>the modification is trivial, but if we were to add every variant of delimited to (ice-9 control), well, look at http://docs.racket-lang.org/reference/cont.html?q=shift-of#%28mod-path._racket%2Fcontrol%29
<ijp>s/-of/-at/
<wigs>racket sure does like to enumerate, huh?
<ijp>smart folks, and thorough
<mark_weaver>hi wingo!
<ijp>shift-at/reset-at is IMO the "natural" way to do tagged shift-reset, but I've seen at least one other version
<wingo>morning :)
<mark_weaver>I liked your blog post on sexism.
<sneek>Welcome back wingo, you have 1 message.
<sneek>wingo, civodul says: Python uses futures for I/O: http://lwn.net/SubscriberLink/544522/d195cfa20c302914/
<wingo>mark_weaver: tx :)
<mark_weaver>I think the best way for things to improve on that front is for well-respected male hackers to stand up for women. Thanks for doing it :)
<ijp>mark_weaver: is stable-2.0 still supposed to run with gmp < 5, or are those patches on master only?
<mark_weaver>ijp: the fixes for gmp < 5 are in both stable-2.0 and master.
<mark_weaver>ijp: I tested stable-2.0 with GMP 4.2 just the other day, and it passed all tests.
<ijp>then I must be doing something wrong, because I am getting two undefined references
<ijp>one to mpz_clears and one to mpz_inits
<mark_weaver>nalaginrut: I fixed 'string-join'. I just sent a message about it to guile-devel.
<mark_weaver>ijp: which branch?
<ijp>stable-2.0
<mark_weaver>ijp: The fix is in 07b390d5827da2f46f57e4650167920fb792ebc9. Do you have it?
<nalaginrut>mark_weaver: thanks for that, is it as fast as string-concatinate or call-with-output-string now?
<mark_weaver>should be, yes.
<nalaginrut>though I won't choose string-join for my str*, but I'd like to see that optimization ;-)
<ijp>hmm, seems not
<mark_weaver>nalaginrut: on my system, (string-join (make-list 100000 "test") "-") is over 3000 times faster (28.5 milliseconds vs 98 seconds).
<ijp>I was sure I had updated it last night
<nalaginrut>mark_weaver: and how can I confirm the definition of a proc
<nalaginrut>mark_weaver: cool
<mark_weaver>with a million elements, it should be about 30,000 times faster.
<nalaginrut>mark_weaver: I mean the definition line
<mark_weaver>nalaginrut: I'd use 'source-properties' to find out the line/column of the lists and sublists that you get back from 'read', and compare those with the line/column returned by 'program-source'.
<mark_weaver>find the sublist that matches.
<ijp>okay, looks like this was an instance of PEBCAK
<ijp>er, PEBKAC
<ijp>whatever, and is commutative
<mark_weaver>hehe :)
<wingo>hehehe
<stis>:)
<nalaginrut>mark_weaver: alright, use regexp to parse the first line huh? then use read to confirm the last line?
<mark_weaver>nalaginrut: no
<mark_weaver>nalaginrut: 'read' top-level datums, starting from the beginning of the file.
<mark_weaver>nalaginrut: until you have gone past the line/column that you want.
<nalaginrut>mark_weaver: so don't use program-source?
<mark_weaver>nalaginrut: yes, use program-source.
<mark_weaver>nalaginrut: and compare the line/column that you got from 'program-source' with the line/column you get from 'source-properties'.
<mark_weaver>'source-properties' gives you the line/column of datums that you 'read' from the file.
<mark_weaver>find the sublist whose line/column matches the one you got from 'program-source'.
<nalaginrut>mark_weaver: sorry but I need to ask an off-topic question first: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body, what auto* packages I need to update?
<ijp>interesting, racket now has more uniform docs for r6rs/srfis
<mark_weaver>anyway, I have to sleep now. good luck!
*mark_weaver --> zzz
*nalaginrut still confused with 'read' utility here, parse each s-expr readout one by one?
<wigs>nalaginrut: to correctly locate the start+end of the procedures source code, it is required. the meaning of the source code changes depending on reader directives (e.g. curly-infix) earlier in the file, so you have to ‘read’ from the start to make sure those directives are handled properly
<nalaginrut>wigs: ah~thanks I meant to ask you
<nalaginrut>wigs: but I still don't get it, is there any peudo code?
<wigs>nalaginrut: maybe something like <http://paste.lisp.org/display/136436>, but that is *rough*
<wigs>I do not have much time to fill it out or verify that it would even be right
<nalaginrut>rough code is enough, I just don't get the point. My question is "does it match needle", how can I do that?
<wigs>does the line and column from EXP match the line and column you are looking for
<wigs>this sketch is not even correct, as mark_weaver noted you will have to inspect the sublists of the lists that ‘read’ gives you
<nalaginrut>wigs: yes ,I know to parse each item in sublist, but my question is I've no idea how to parse it to confirm the definition line of the proc
<nalaginrut>I think read could give me the last line
<nalaginrut>but how to get the first line?
<wigs>well
<wigs>if read gives you the last position, then the previous read gave you the first position!
<nalaginrut>I was told (program-sources read 0) is not true everytime
<wigs>:-)
<wigs>that is what last-pos in the example is for
<nalaginrut>wigs: ah yes, but I don't think it's the case
<wigs>perhaps move on to something else for now
<nalaginrut>I mean 'get the last line' is when I get the first line
<wigs>:-)
<nalaginrut>but I don't know how to get first line
<nalaginrut>it's my only question need to solve
<wigs>everytime you read you get an EXP, that has source-properties, which has a line and column
<wigs>program-source gives you the same info (at the REPL), so you are looking to match that with the source-properties from each read
<nalaginrut>well, (loop (parse (read port))) ? I saw it, but it seems not so elegant and I didn't find a nice way for that
<wigs>there is not really a nice way to extract chunks of source code like this
<nalaginrut>anyway, if that is the case you & mark gave, I get it
<cky>sneek: later tell mark_weaver Yes, the tests pass. Here is my diff: https://gist.github.com/cky/d649688f9a6900c26940
<sneek>Got it.
<cky>I will write a proper commit message, and perhaps re-apply your doc changes (for supporting multiple values), once I get home tonight.
***bitdiddl` is now known as bitdiddle
***brendyn is now known as donglord8000
<dsmith-work>Morning Greetings, Guilers
<ijp>happy easter part II
<mark_weaver>cky: hey, I like your patch! I haven't yet taken the time to understand it in full, so I can't verify its correctness, but from a glance it looks great :)
<sneek>Welcome back mark_weaver, you have 1 message.
<sneek>mark_weaver, cky says: Yes, the tests pass. Here is my diff: https://gist.github.com/cky/d649688f9a6900c26940
<mark_weaver>cky: just one thing: I don't think we can call this SRFI-45, because of 'eager' not being a procedure.
<mark_weaver>cky: so I think (srfi srfi-45) should change 'eager' back into a procedure, and you should remove the scm_add_feature ("srfi-45") in promises.c.
<mark_weaver>cky: along those lines, in (srfi srfi-45) you should use #:replace (eager), and put back the (cond-expand-provide (current-module) '(srfi-45))
<mark_weaver>cky: but other than that, it looks great!
<mark_weaver>cky: also, SRFI-41 should be changed to use these native promises. no doubt that will be faster.
<mark_weaver>oh, well, nevermind.. hmm
<mark_weaver>I guess maybe we should add something like 'make-promise-type' for these native promises.
<mark_weaver>I guess (srfi srfi-45) should just reexport 'make-eager-promise' as 'eager'.
<mark_weaver>wingo: sorry to bug you, but if you could take a quick look at my new "internal port structure" patches, that would be very helpful. I don't need a full review, just an idea of whether it's more-or-less acceptable to you before I build more on top of it.
<mark_weaver>wingo: in particular: http://lists.gnu.org/archive/html/guile-devel/2013-03/msg00221.html
<mark_weaver>(civodul has already reviewed it from the point-of-view of 2.0)
***zacts``` is now known as zacts
<mark_weaver>cky: I don't see why we need "indirect" promises. why not just copy the data and flags from 'promise' to 'new-promise'? it would be good to avoid that extra complexity if it's not needed.
<mark_weaver>the reference implementation of SRFI-45 doesn't have anything like indirect promises, and I don't see why we should need them.
<tupi>clojure/java/imagej/fiji is a nightmare: what a lack of luck that nobosy ever wrote a strong image processing library in guile
<mark_weaver>tupi: specifically, what image processing operations do you need?
<mark_weaver>(I've written image processing code in the past for the national cancer institute here in the US)
<mark_weaver>(so I have some knowledge in that area, though it was a very long time ago)
<tupi>mark_weaver: the lab i am [trying to :)] work for does advanced image processing , segmentation, for particle and/or material detection ...
<tupi>mark_weaver: wouah, this is nice
<tupi>it is that i hate java
<tupi>actually any non lisp/scheme gives me terrible headhakes, i just don't understand these languages and really would like to stay away
<mark_weaver>hmm. are there no good libraries for C?
<mark_weaver>or, failing that, C++?
<mark_weaver>tupi: I sympathize about the headaches of working with non-lisp/scheme. I've become terribly spoiled in the scheme world :)
<tupi>mark_weaver: i did ask myself that, sure there must be, probably too many, imagemagick, graphicsmagic, any so so many, which one to choose ... then i personnaly lack image processing knowledge [yet] and, the hundreds of plugins that are available in fiji really is impressive, hard to beat really, :(
<mark_weaver>*nod*
<tupi>yeah, guile, guile-gnome, guile-clutter, what a nice language and bindings
<tupi>i did ask a couple of days agao if people used 'closure', but i ment clojure thye language of course :) [nobody answered, not sure it was understood i ment clojure
<mark_weaver>I suspect people knew what you meant.
<mark_weaver>clojure has a lot of interesting ideas. I probably wouldn't want to use it myself, but I'd like to adapt some of its ideas to the Guile world.
<tupi>mark_weaver: the problem is that you need to learn java to really be able to use it: then the syntax becomes brain damaged, . .. .setThis BrainStorm.
<mark_weaver>*nod*
<tupi>mark_weaver: the code you wrote was in lisp or in scheme ?
<tupi>any bits available ?
<mark_weaver>what code?
<tupi>image processing
<mark_weaver>no, that was written in C on MacOS back in 1987. it was non-free software and is lost to me.
<tupi>ok
***ijp` is now known as ijp
<dsmith-work>mark_weaver: Heh. That #t in your gc_typed_malloc really threw me for a minute.
<mark_weaver>haha, I didn't even notice that :)
<mark_weaver>I should mention that Andy wrote that macro in email, and I pretty much just copied it.
<mark_weaver>(though I had to change ((t)*) to (t *) because gcc didn't like the former syntax)
<ijp>dsmith-work: same here
<dsmith-work>Two mild peeves I have with most C code. Automatic parens after return and sizeof. They are NOT functions.
<tupi>it is really interesting to see how 'open source' people are different from free software: they write wiki with links to oracle, and so far, they are always a little bit more agressive to new comers and [stupid] quiz on chat rooms
***adu_ is now known as adu