IRC channel logs


back to list of logs

***ijp` is now known as ijp
<int3__>hmm the makefile doesn't seem to be detecting my changes to the library functions
<int3__>I've modified module/ice-9/arrays.scm, but `make` just says 'nothing to be done'
<ijp>well, it isn't in the ice-9, apparently
<ijp>which probably isn't surprising, since basically all the arrays code is in C
<int3__>ijp: I'm confused as to how the array-shape definition finds its way into the runtime, then. it appears to be defined in the arrays.scm file, so there's either a duplicate definition, or the build system is picking it up indirectly...
<ijp>I haven't looked into it, but I'd presume the former
<ijp>because I know for a fact that it isn't getting installed
<int3__>ah, it looks like it gets defined in boot-9.scm
<int3__>are all the globally-available functions defined in boot-9?
<ijp>well, no.
<ijp>The module is (guile), the file is boot-9
<ijp>C code, and probably a few other files add to (guile) directly
<int3__>okay. so I'd like to add some functions to (guile), but I'd like to leverage some of the existing srfi library functions too
<ijp>I would dearly love it if (guile) was not becoming ever larger
<int3__>well array-map! is currently in (guile)
<int3__>and I've implemented array-fold and array-fold-all
<int3__>which should probably be in the same module...
<ijp>yes, and it's a horrible procedure anyway
<ijp>actually the whole arrays code is
<ijp>every time I go to use it, I regret it, and go back to nested vectors
<int3__>do you know how I might add a patch that adds array-fold to (guile), when srfi-26 is being used in the definition of array-fold?
<int3__>or should I just write my partial applications as explicit lambdas and not require anyway
<ijp>well, in this case, I would say just write the lambda
<ijp>to hack around this in other cases, you can use @
<ijp>of course, in modules other than boot-9 this is not even an issue
<int3__>ah I didn't know about the @ syntax
<ijp>but please be careful with boot-9. it's the longest recompile, and it affects every other file
<int3__>how do I run individual tests?
<ijp>./check-guile foo.test bar.test quux.test
<int3__>ah ok thanks
<nalaginrut>what's this? #[object 'orientation]
<nalaginrut>I saw it in slayer
<ijp>a custom reader extension
<nalaginrut>is it portable?
<nalaginrut>I never saw it
<ijp>portable how?
<nalaginrut>to other scheme implementation
<ijp>it won't run on other scheme implementations
<ijp>and it won't play well with my .guile either
<nalaginrut>I wonder if it's in slayer or in Guile?
<ijp>it's not in guile
<ijp>I am strongly opposed to adding more shit to the reader
<nalaginrut>well, I don't know if it's better than just slot-ref
<ijp>is that all it does?
<ijp>please tell me it at least defines an accessor rather than just a getter
<nalaginrut>I don't know, just guess
<nalaginrut>#[this 'id] hmm...I think it's something like getter
<nalaginrut>but accessor does this
<Chaos`Eternal>hi guilers
<Chaos`Eternal>anybody know about pkg-list.scm file
<Chaos`Eternal>when i want to announce a package to guild-hall
<Chaos`Eternal>I want to state that the package is depending on guile-2.x
<Chaos`Eternal>how to write such a statement in pkg-list.scm
<nalaginrut>I don't think there's such a thing, patch needed
<Chaos`Eternal>okey, i got it
<Chaos`Eternal>another question
<Chaos`Eternal>how to determine where is guile's site package dir?
<Chaos`Eternal>on ubuntu , default is /usr/lib/guile/site/2.0
***Gues_____ is now known as Guest79130
<shanecelis>hey everybody
<shanecelis>I'm wondering, what is a good way to substitute/override procedures?
<shanecelis>I know, you can just redefine them, but that seems really hacky, and what if you want to "go back".
<shanecelis>Maybe what I kind of want is defadvice.
<davexunit>shanecelis: I have a snippet that allows me to stub a procedure. is that kind of what you want to do?
<davexunit>basically, resolve the module, grab the variable that holds the procedure, and then give it a new value.
<shanecelis>Maybe. Can you revert it back?
<shanecelis>Oh, I see.
<shanecelis>That's cool.
<shanecelis>Thanks. This definitely helps.
<davexunit>shanecelis: no problem. :)
<davexunit>you've reminded me that I should consider revamping this code. now that I've learned how to unit test emacs lisp I feel like I have a better idea of what to do.
<shanecelis>How do you unit test elisp?
<davexunit>shanecelis: ert
<davexunit>it's a built-in package
<davexunit>shanecelis: really simple example:
<shanecelis>cool. I've been using check.scm for Guile, but it only has asserts. It doesn't really define tests.
<davexunit>I need to better investigate the SRFI that provides a unit testing framework for scheme.
<davexunit>I'd like to expand my stubbing code to behave more like mocker.el
<davexunit>since it provides the nice features of being able to expect calls with certain arguments and stuff.
<shanecelis>[nods] I haven't used mocker but I used to mock stuff. At least we don't need to go through the god awful contortions that the JVM folks have to when mocking things.
<davexunit>ew. that sounds like it must be quite the shoehorn.
<davexunit>I haven't written java since I've been out of college.
<davexunit>we didn't discuss test-driven software development there so I never experienced the horror.
***ijp is now known as Fuco1
***Fuco1 is now known as ijp
<ijp>Chaos`Eternal: there is no such thing, because guildhall won't run on guile 1.x in the first place
<davexunit>is there a FAQ that explains why one would want to use Guile instead of, say, Racket?
<mark_weaver>I don't think it's written up anywhere, but one reason is that Racket is a much more "static" system. Module bindings are immutable by design. A related fact is that they use a more traditional OO system with single-dispatch.
<mark_weaver>Also related is that they do not have extensible primitives. e.g. guile's numeric procedures can be easily extended to new types, but they don't allow that in Racket.
<mark_weaver>From their perspective, this is a feature, because it allows you to write modules based on other modules without the possibility that your code will be broken by incompatible extensions to the primitives, or by changing module bindings later.
<mark_weaver>Guile's philosophy is much closer to Emacs, where everything can be changed at any time. It is a fully dynamic system.
<davexunit>thanks mark_weaver. that helped a lot.
<davexunit>I like the idea of a fully dynamic system.
<mark_weaver>Glad to help. I also prefer dynamic systems, but I can see why a more static system would be preferable for some applications.
<davexunit>I suppose a static system is easier to use for something that could be labeled "high performance"?
<mark_weaver>It's easier to optimize a static system, because you can more freely inline things without having to worry about what happens if those things are rebound later (because that's simply not allowed).
<mark_weaver>however, it is possible to have the best of both worlds. it's possible to inline bindings, and then rig things up so that if the binding changes, all compiled code that inlined it becomes invalidated.
<mark_weaver>it's very tricky, but it can be done. and I'd like to do that in Guile at some point.
<mark_weaver>the more compelling advantage to static systems is that it's easier to prove things about static systems.
<mark_weaver>I like what Alan J. Perlis wrote in the forward to SICP: "Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place."
<davexunit>that's a very cool quote.
<davexunit>I bought SICP at the MIT bookstore on Saturday. :)
<mark_weaver>Excellent! SICP made a deep impression on me. It radically changed my view of how programs should be written.
<davexunit>I saw the little schemer there too but didn't get it.
<davexunit>I wish I had read SICP years ago.
<davexunit>I need to work through the exercises.
<mark_weaver>yeah, that's very important.
<mark_weaver>passive learning (i.e. simply reading or listening) doesn't work well.
<davexunit>I just moved into the city so my commute has gone from 2 hours to 30 minutes. now I'll have the free time to work through the exercises.
<mark_weaver>where do you live now?
<mark_weaver>cool :)
<davexunit>I think you mentioned that you are in Somerville before?
<davexunit>I've been up there a bunch lately.
<davexunit>winter hill and davis square mostly.
<mark_weaver>I live close to davis
<davexunit>it's a very nice area.
<add^_>Hello all.
<add^_>davexunit: SICP is awesome :-D I would want to have that book in dead-tree form :-)
<davexunit>add^_: it took me awhile to realize that I can just stop by MIT and grab a copy. I've read some of the online version here and there.
<add^_>Yeah, I wonder how long time it'd take for it to ship over to Sweden though, and what it'd cost.. :-/
<davexunit>I've borrowed some code from it. there's a bit where they implement a scheduler for a circuit simulation. I used that as a base to create a coroutine scheduler. :)
<davexunit>add^_: yeah, it's $49 before shipping.
<davexunit>expensive read.
<mgsk>Can I compile my Guile code to a binary?
<ijp>or at least, not yet
<davexunit>mark_weaver: saw your post about scsh. maybe local guilers will have to march down to Northeastern and do some convincing. :P
<mark_weaver>mgsk: virtual machines are likely to be a win for most code, because VM code can be more compact, and thus more of it can fit in the cache.
<mark_weaver>even when we have native compilation, I suspect it will make sense to only compile hot spots to native code.
<int3__>ha. shivers sounds like quite the charmer indeed
<davexunit>I know nothing about him. I just know that he's my friend's prof.
<int3__>davexunit: well, I'm sure that you know he Did It All By Himself :P
<int3__>(I don't know him personally either)
<davexunit>I don't, actually
<mark_weaver>have you seen the acknowledgements section of the scsh reference manual? I assume he's mostly joking, but it's still quite an amusing read:
<int3__>mark_weaver beat me to it
<mark_weaver>hehe, by a fraction of a second :)
<ijp>as he says on his page "A lot of people have been kinda worried about me ever since I published the scsh manual back in 1993, but I'm feeling a lot better, really."
<davexunit>oh wow
<davexunit>that was an entertaining read
<mark_weaver>rarely does one see such honesty
<ijp>huh, that shift/reset issue is werid
<ijp>(let ((k (reset (shift k k) (values 3.1 2 3)))) (k)) ; -> one value
<ijp>(let-values (((k) (reset (shift k k) (values 3.1 2 3)))) (k)) ; -> three values
<ijp>looks like an optimizer issue
<mark_weaver>I wonder if it's related to
<ijp>I believe so
<ijp>You can see in the ,optimize'd code that the (values 3.1 2 3) gets turned into a 3.1
<ijp>I'd need to have a look over the patch in that report, and see if it fixes things
<mark_weaver>I have a vague recollection of wingo saying that he thought that patch wasn't the right fix, but maybe I'm misremembering.
<ijp>While I have this issue paged in, I might whip up a patch for shift-at reset-at, and post it to guile-devel
<ijp>but for now I need to go build stable
<thorwil>hi! what's the likely cause if (use-modules (gnome gobject) kills guile [used via geiser]?
<mark_weaver>do you see any messages at all?
<thorwil>briefly, about things being compiled. gone too fast to read
<ijp>I don't know if it is related but, but I recall (use-modules (gnome-2)) being necessary
<mark_weaver>Those messages can be logged in any number of ways. I'd like to see them.
<mark_weaver>have you successfully used guile-gnome before?
<thorwil>there's guile 1.8 and 2.0 here, the guile-gnome* packages don't seem to refer strictly to either(?)
<ijp>that sounds problematic too
<thorwil>i never used anything guile before :)
<mark_weaver>how did you install guile and guile-gnome?
<mark_weaver>if guile-gnome is compiled for guile 1.8, then it won't work with 2.0.
<thorwil>all via synaptic, ubuntu 12.04
<mark_weaver>ah. the debian/ubuntu guile-gnome packages are compiled for 1.8. they won't work with guile 2.0.
<thorwil>good to know. wish that was made obvious somehow
<mark_weaver>yeah, sorry for the lack of a nice error message. i'll look into it.
<mark_weaver>we could walk you through the process of compiling a guile-gnome for guile 2.0 if you like.
<thorwil>hmm, if i try (use-modules (gnome gobject)) in a guile started on terminal, it says While compiling expression: ERROR: no code for module (gnome gobject)
<thorwil>so geiser rather gets in the way of that message being delivered(?)
<taylanub>thorwil: C-h v geiser-guile- TAB
<tupi>thorwil, what does 'which guile' answer ih a terminal?
<ijp>did you (use-modules (gnome-2))
<thorwil>mark_weaver: ty, first, i will see how far i get
<mark_weaver>if you want to use guile-gnome, then the only alternative is to use guile-1.8... but guile-1.8 is not supported anymore and is far inferior to guile-2.0.
<ijp>this is pretty mcuh the first thing it says to do in the manual
<taylanub>(Oh wait, nevermind me, although you might want to check those variables anyhow if you didn't already.)
<thorwil>tupi: /usr/bin/guile. guile -v tells me: 2.0.5-deb+1-1
<mark_weaver>I really need to produce some debian packages for guile and guile-gnome.
<tupi>then it won't work with synaptic packages
<tupi>do you have guile-1.8 ? try guile-1.8 in a terminal
<thorwil>yes, (gnome gobject) works for 1.8
<tupi>ok, so for your first steps, that's what you need to do, amnually start guile-1.8 and ...
<thorwil>anything in the diff between 1.8 and 2.0 a noob might notice (in 2 weeks or so)?
<tupi>then you can try [it's not difficult] to compile guile-gnome, i can help too
<mark_weaver>thorwil: what do you mean by "in 2 weeks or so"?
<thorwil>mark_weaver: 2 weeks of use
<mark_weaver>guile-1.8 will be fine to start out with.
<mark_weaver>I was just wondering where "2 weeks" came from. Do you anticipate only using this for 2 weeks?
<thorwil>mark_weaver: no. just as a measure for things to stumble over early. as opposed to arcane details you have to grow a beard for, first, to notice
<mark_weaver>ah, okay. well, apart from the fact that guile 2 is much faster, it has many nice additions that people here on channel and on the mailing lists might recommend that you use.
<mark_weaver>but this reminds me that I should really create some debian packages for recent guile and guile-gnome packages, and maybe a PPA for ubuntu.
<mark_weaver>in the meantime, I'm sure guile-1.8 will be fine for your initial investigations :)
<mark_weaver>also, the 2.0 manual is much improved. for example, the 2.0 manual will recommend that you use SRFI-9 records instead of the legacy low-level guile record system. if you use records, make sure to use SRFI-9 records.
<thorwil>ok, thanks! playtime over for now, good night!
<stis>evening guilers!
<stis>hey ijp: did you see my mail aginst bug #14347?
<stis>anyway have fun, i'm off to zzzzz!