<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
***zacts` is now known as zacts
<ijp>taylanub: I have a tagged version of shift-reset that I use, similar to how racket has shift-of/reset-of <wigs>racket sure does like to enumerate, huh? <ijp>smart folks, and thorough <ijp>shift-at/reset-at is IMO the "natural" way to do tagged shift-reset, but I've seen at least one other version <sneek>Welcome back wingo, you have 1 message. <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: 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? <nalaginrut>though I won't choose string-join for my str*, but I'd like to see that optimization ;-) <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 <mark_weaver>with a million elements, it should be about 30,000 times faster. <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'. <ijp>okay, looks like this was an instance of PEBCAK <ijp>whatever, and is commutative <nalaginrut>mark_weaver: alright, use regexp to parse the first line huh? then use read to confirm the last line? <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. <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 *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: but I still don't get it, is there any peudo code? <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 <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>that is what last-pos in the example is for <wigs>perhaps move on to something else for now <nalaginrut>I mean 'get the last line' is when I get the first line <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>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
<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. <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: also, SRFI-41 should be changed to use these native promises. no doubt that will be faster. <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>(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>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>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, :( <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>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. <tupi>mark_weaver: the code you wrote was in lisp or in scheme ? <mark_weaver>no, that was written in C on MacOS back in 1987. it was non-free software and is lost to me. ***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>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