IRC channel logs

<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.

<zacts>(kidding)

<davexunit>:P

<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.

<nalaginrut>heya

<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

<slucx>:)

<nalaginrut>;-)

<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>

<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

<mark_weaver>*nod*

<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>ok

<civodul>should class accessors be inlined?

<civodul>with define-inlinable

<wingo>perhaps!

<wingo>probably!

<civodul>:-)

<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

<civodul>ok

<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

<civodul>yeah

<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>sure

<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?

<wingo>yep

<civodul>so that sounds fine

<wingo>which is what everyone expects :P

<civodul>yes, clearly

IRC channel logs

2015-01-14.log