IRC channel logs


back to list of logs

<zacts>hi guilers
<slucx>hi zacts
<zacts>guile sounds like a slimey word. It reminds me of the ooze from tenage mutant ninja turtles.
<davexunit>so today at work, a sysadmin was trying to find a frontend to the 'crypt' function in libc to create a password hash, and before he could apt-get install one I had already used Guile's FFI to do it.
<davexunit>+1 for guile
<zacts>hey davexunit
<paroneayea>davexunit: :D
<davexunit>does anyone know to add a docstring to non-procedure objects?
<davexunit>such that they are displayed when using the 'describe' metacommand at the REPL?
<nalaginrut>morning guilers~
<davexunit>hey nalaginrut
<zacts>davexunit: I only have one problem with SICP.
<zacts>It requires me to actually think about things.. I'm too lazy for that.
<davexunit>(delay (read-sicp))
<zacts>it'll be a lazy-eval sicp
<zacts>hey davexunit which gnu/linux distro are you currently running, at least until guix is more v1.0 ready
<davexunit>debian testing
<zacts>oh cool
<zacts>I wish I was running a fully free distro. I'm waiting for (guix). I'm currently on arch linux now.
<zacts>hi nalaginrut
*slucx a,b,c,d are digits. (if (eq? (* abcd 9) bcda) '(what a b c d are?))
<nalaginrut>slucx: don't use eq? to compare digits
<nalaginrut>slucx: use eqv? or =
<slucx>nalaginrut: ok ;)
<nalaginrut>(* 8999 a) should be less than 999, seems impossible assume 'a' is integer, IMO
<nalaginrut>did I miss something?
<slucx>nalaginrut: ?
<nalaginrut>slucx: what's the answer? ;-)
<slucx>nalaginrut: you can write a code to eval it
<slucx>and what's your algorithm?
<slucx>the answer is 1089
<nalaginrut>hah, interesting
<nalaginrut>should be (= (* 9 abcd) dcba), or it's impossible ;-)
<slucx>your target is to find the number abcd nalaginrut
<nalaginrut>slucx: your original equation is wrong, it's impossible with that condition
<nalaginrut>slucx: (* 1089 9) == 9801, it's dcba
<nalaginrut>not bcda
<slucx>hahaha nalaginrut It's my fault
<nalaginrut>I found stable2.0 rdelim.c use scm_getc instead of scm_getc_unlocked drags some performance, dunno why
<nalaginrut>I modified it in master then try, %read-line became slower
<civodul>Hello Guilers!
<artyom-poptsov1>Hi civodul
<nalaginrut>well, seems scm_getc will lock occasionally, so there's performance penalty
<nobody111>if i am "converting" from a bytevector to uniform numeric vector using one of the any->... functions from (srfi srfi-4 gnu) i am not allocating any memory, just changing the interpretation of the original bytevector, right?
<nobody111>of course, it is said in the documentation that the numeric vectors are implemented as bytevectors, so this is what i am basing my reasoning on
<lloda>those functions do allocate. see
<lloda>scheme@(guile-user)> (define a #f64(1 2 3 4))
<lloda>scheme@(guile-user)> (define b (any->c64vector a))
<lloda>scheme@(guile-user)> (array-set! a 9 1)
<lloda>scheme@(guile-user)> b
<lloda>$4 = #c64(1.0+0.0i 2.0+0.0i 3.0+0.0i 4.0+0.0i)
<lloda>scheme@(guile-user)> a
<lloda>$5 = #f64(1.0 9.0 3.0 4.0)
<lloda>it would make more sense if they didn't, imo
<lloda>but then they would need to fail in some cases
<dsmith-work>Wednesday Greetings, Guilers
<pchrist>guys, when I'm building libunistring 0.9.4 in gentoo, the test-thread_create
<pchrist>test fails
<pchrist>does anyone know if this is an issue later on guile?
<pchrist>can be*
<wingo>civodul: did you have a chance to look at the goops patches?
<mark_weaver>wingo: fwiw, I browsed your goops patches. looks like a great initiative! there was one commit, however, that I had mixed feelings about: bdc791868
<mark_weaver>changing all of those slot-ref/slot-set!s to struct-ref and struct-set! seemed like a step in the wrong direction in terms of code clarity.
<nobody111>lloda, wow, thos any->... functions do not reinterpret at all, they just take old values, promote them into a new type, and place the in the corresponding slot of newly allocated, returned array
<mark_weaver>also, mixing the whitespace cleanup and the slot->struct accessor change into the same commit seems suboptimal.
<nobody111>lloda, now that i think about it, that does make sense, as there is no '!' for setter. One can still use bytevector-type-...set! , luckily
<mark_weaver>wingo: what was the rationale behind changing slot-{ref,set!} to struct-{ref,set!} in that code?
<lloda>nobody111: right, pretty useless if you ask me, might as well use make-typed-array / array-copy! :p
<nobody111>lloda, sure, but bytevector is a standard Scheme library :)
<lloda>nobody111: reinterpreting wouldn't need !, since it would return a new view, the original is not modified. E.g. make-shared-array has no ! .
<nobody111>lloda, yeah , of course you're right :)
<nobody111>lloda, so , maybe any->blah interface is misleading
<lloda>i'd say so, but the doc does say
<lloda>'Return a (maybe newly allocated) uniform numeric ...'
<lloda>no online doc though
<lloda>and there's no way to do what you thought at first, I mean from Scheme, and that would be useful
<lloda>so any->typevector converts from list/vector/othertypevector, which IS useful.
<civodul>wingo: goops, not yet!
<wingo>mark_weaver: those changes were for <class> instances
<wingo>and all <class> instances must have those slots at those offsets
<wingo>this is as the C code was, mostly...
<wingo>mark_weaver: some of those changes were needed in order to be able to implement slot-ref in scheme
<mark_weaver>wingo: ah, okay. that makes sense.
<mark_weaver>have you done any benchmarks to see how these changes affect performance? (not that I want to put too much weight on that, just curious)
<wingo>nope :)
<wingo>i have some expectations but have not benchmarked
<wingo>still, there are a number of ways things can be dramatically sped up
<wingo>now that the protocol is in scheme
<wingo>some examples would be caches in slot-ref; hashing in slot-ref; computing specialized allocator/initializer routines...
<wingo>effective slot definition classes instead of parsing slot definition initargs each time
<wingo>and of course call-site caches instead of callee caches...
<wingo>dunno how that would work
<mark_weaver>wingo: I agree that there's a lot we'll be able to do, especially when we have native compilation. Moving more of goops to scheme should facilitate that, even if it means a slowdown in the short term.
<wingo>i kinda think that it won't be a slowdown, actually
<wingo>but we need to measure
<lloda>re: any->typevector, guile-ploy has (as-array ...) which also works for arrays of rank > 1 (nested lists/vectors/etc).
<civodul>wingo: re "Deprecate C exports of GOOPS classes.", could bindings like guile-gnome rely on it?
<wingo>civodul: i grepped and didn't find anything
<wingo>i don't think so, and anyway they should access from Scheme
<wingo>will check again tho
<civodul>should class accessors be inlined?
<civodul>with define-inlinable
<civodul>ok, i just browsed the whole branch, that's a lot of reading! ;-)
<civodul>the whole thing looks very nice
<civodul>i mean, all those hairy bits suddently replaced by more pleasant Scheme code
<wingo>still hairy :)
<civodul>would be good to benchmark a bit
<wingo>i am working on commenting it
<wingo>so it reads better
<civodul>yeah that would be nice
<civodul>and docstrings and all
<civodul>so my concerns would be mostly testing and performance
<civodul>the good thing is that individual bits should be easily testable
<civodul>for instance, there are comments giving examples of compute-cpl
<civodul>these could be translated to tests
<wingo>yes, i have some local commits to put those in tests
<wingo>didn't want to push to confuse the review
<wingo>but yes you are right :)
<civodul>re performance, initialize-object/allocate-object in scheme might be a hit
<wingo>might be, or might not
<civodul>well, intuition is not worth much
<wingo>because with init-thunks it should be faster in scheme
<civodul>re compatibility, i would think that guile-gnome & co. are the biggest potential users of GOOPS tricks in C
<civodul>so if they're not impacted, that's a good sign
<wingo>i have mostly been grepping, i haven't compiled yet
<wingo>but the plan is to avoid making changes that would cause guile-gnome to change
<wingo>unless there's a really good reason
<civodul>guile-gnome is going to be a good compatibility benchmark anyway
<civodul>perhaps we could also poll guile-user for people using the GOOPS API in C
<civodul>just to get an idea
<wingo>there are few compatibility issues on the c side
<wingo>deprecation is still compatible
<wingo>and some things are much better (e.g. scm_make)
<civodul>regarding scm_make, the incompatibility is mostly that the new one does more things than the old one, no?
<civodul>the new scm_make is exactly like Scheme 'make', right?
<civodul>so that sounds fine
<wingo>which is what everyone expects :P
<civodul>yes, clearly