IRC channel logs


back to list of logs

<guiliug>Hi, I'm new to Guile (just started reading the manual). Is there any coding style guide for Guile?
<guiliug>Maybe something like Pythons PEP8?
<wleslie>it's covered in the GNU style guide
<wleslie>but it's pretty simple
<nalaginrut>morning guilers~
<nalaginrut>sneek: later tell davexunit yeah, I saw Carmack said so last night. Years ago I saw he tweet "Scheme has the challenge of getting your program to work." ;-P
<sneek>Got it.
<please_help>Any idea how to work a array-rest that gives the complimentary array to array-first, itself working along a specific dimension?
***michel_mno_afk is now known as michel_mno
<civodul>Hello Guilers!
<lloda>please_help: I remember posting array-first and array-rest in this channel in reply to one of your questions. It's trivial to modify array-first to skip k > 1 dimensions. I've also posted a patch series to the git repo to add an equivalent operation to Guile itself.
<lloda>please_help: The complementary array-rest only exists for k=1, b/c otherwise [A - array-first(k, A)] is not an array. Let me know if you want me to post those array-first & array-rest n or if you have more specific questions.
<wingo>morning all
<atheia>Morning wingo!
<please_help>lloda, I need the array-rest for k > 1, otherwise there's no point. As you said, array-first and array-rest for k = 1, and array-first for k > 1, are trivial. Thanks all the same.
<DimStar>Hi all; is guile 1.8 branch still maintained? I'm having trouble building it on
<DimStar>'modern' technologies (well, building works, but make check fails'
<wingo>it's not really maintained, no, but build fixes are welcome
<DimStar>A build log:
<DimStar>(so it's just 'some 24 tests' that are unexpectedly failing :)
*wingo checks locally
<wingo>DimStar: the 24 is for expected failures
<wingo>the problem are the 47 failures
<wingo>xfails are not bad
<wingo>DimStar: can you try from git to see if that works for you? for me git passes all tests
<wingo>i mean, there are some xfails, but that's not a problem
<DimStar>wingo: sure.. I think I got almost all commits from the 1.8 branch on it anyway (the makeinfo seemed most appealing)
<DimStar>wingo: are you running makeinfo 5.1+ (I'm runing 5.2 here)
<lloda>please_help: but array-rest for k>1 is not an array. You can get the array-rest as a reshaped array by flattening the first k dimensions. Does that work for you?
<DimStar>wingo: tested a build with git master of the 1.8 branch; still getting 204s] failures: 47
<wingo>DimStar: I have 5.2 but maybe with a clean build i would see different errors
<dsmith-work>Morning Greetings, Guilers
<please_help>lloda: the problem I need to solve is how to efficiently iterate over an array across a given dimension. I tried to write an increment function such that (increment idx=(0 0 2) bounds=(2 2 3)) ;=> (0 1 0): that was much too slow. Other suggestions include using array-index-map!, or array-first/array-rest
<please_help>array-index-map! generates a write everytime, which is annoying, though.
<please_help>Array-rest need to be something that can be array-first'd.
<DimStar>wingo: maybe that's important: if I don't do makeinfo --force, then build does not work at all (so there is still something wrong in the docs)
<DimStar>guile-tut.texi:449: raising the section level of @subsection which is too low
<lloda>please_help: I still don't understand why the write of array-index-map! matters, but never mind. What about flattening the first k dimensions of the array?
<lloda>I also have this function (array-for-each-cell) in private code:, I'll push it once I get a review for my lloda-array-support branch
<lloda>it can be implemented in Scheme, using array-index-map! :p
<wingo>sometimes i think we should import libgc
<lloda>why don't we?
<wingo>well, it's fairly well-maintained right now, not perfect but ok
<wingo>and it gives us the ability to punt freebsd et al concerns somewhere else
<wingo>separating has disadvantages too but i'm just listing the positive things
<wingo>also if we import it, do we patch our import? would we want to completely fork it, or just maintain a patch tree on top of what they have?
*wingo dunno
<lloda>to compile your own Guile it's certainly more convenient to have it imported, there seem to be frequent incompatiblities between versions
<lloda>I'd do it just for that, even without our own Guile-specific patches
<davexunit>I'm typically anti-bundling, but maybe good in this case...
<lloda>to keep a matched version
<wingo>probably at some point we should fork bdw-gc and hack on it
<wingo>when we have resources for that
<wingo>but i don't have that right now
<wingo>maybe we should do that for 2.2
<lloda>it may also happen that they break something, so you need versions older than
<wingo>we need help from the gc to be able to munmap files, or in general to free compiled code
<mark_weaver>wingo: I've also often thought about bring libgc into guile and forking it.
<mark_weaver>although I suppose it would be best to try to get the changes we want upstream first.
<mark_weaver>and if we start to encounter resistance and can't get what we need that way, then we could fork it and take it in.
<dsmith-work>mark_weaver: Lack of a reasonably current libgc has slowed some distros packaging newish guile releases. (like how long it took for Debian to get any 2.0 package)
<mark_weaver>wingo: you wrote "Interesting, this isn't the objection I thought you might have :)". What objection did you think I might have?
<mark_weaver>dsmith-work: good point!
<mark_weaver>wingo: the reason I ask is that your comment makes me wonder if I miscommunicated somehow, or if you read more into what I wrote than I intended.
<wingo>mark_weaver: i thought you would be concerned about evenness/oddness
<wingo>with the streams
<wingo>like, would an ice-9 streams on top of srfi-41 streams be more or less eager?
<wingo>(i don't know the answer fwiw)
<mark_weaver>ah yes. I guess that the eagerness of SRFI-41 streams would be <= than ice-9 streams
<mark_weaver>but I haven't looked carefully
<wingo>but the threadiness is a good point that i didn't think of
<mark_weaver>both the cars and cdrs of SRFI-41 streams are lazy
<mark_weaver>so it's actually possible to determine the length of a finite SRFI-41 stream without evaluating any of the actual values.
<unknown_lamer>mark_weaver: if you're thinking about dragging libgc into guile, resurrect the precise collector from 1.8 instead ;)
<wingo>1.8's collector was terrible
<wingo>much worse than libgc
<mark_weaver>I sympathize with the desire for a precise collection, at least as an option.
<unknown_lamer>actually, my only nit with libgc is that I spent a few weeks trying to get it to pause for < 5ms and failed utterly
<mark_weaver>I'm not happy that we've basically been encouraging folks to not bother writing mark functions anymore, for example.
<wingo>mark_weaver: did you see
<wingo>the section "integrating llvm with garbage collection"
<mark_weaver>we are locking ourselves into a commitment to stick with conservative collection forever
<mark_weaver>wingo: not yet, will look, thanks!
<wingo>hoo, i'm very happy about people not writing mark functions...
<wingo> is the paper link too
<wingo>but the article puts it into contect
<wingo>i think a bartlett collector would be almost ideal for us
<wingo>especially as we move to native compilation
<wingo>mark_weaver: fwiw i'm not worried about lock-in. we'd have to support other interfaces to allow moving collectors anyway, so we'll have to figure out some migration strategy
<wingo>also on the gc gossip side, oilpan is a conservative stack / precise heap gc for blink, and they moved away from parallel marking because it was actually slowing things down for them!
<wingo>an interesting result
***dje is now known as xdje
<wingo>that the cpu affinity of memory was being trashed by the marker
<mark_weaver>I have to go afk. ttyl!
***michel_mno is now known as michel_mno_afk
<guiliug>How can I get guile to display non-ascii characters when running the programs non-interactively? For example, running
<guiliug>(display "Hello, 世界")
<guiliug>-| Hello, ??
<mark_weaver>guiliug: put (setlocale LC_ALL "") at the beginning of your program
<mark_weaver>that's done automatically by the Guile REPL, but in your own Guile programs you have to do it yourself
<guiliug>Ah, it works, thanks mark_weaver :)
<guiliug>Guile manual says something about putting a comment with coding: utf-8, but it didn't work for me.
<mark_weaver>guiliug: that's a different issue. that ensures that Guile reads the file as UTF-8 (which it does by default anyway)
<guiliug>I see, thanks.
<mark_weaver>the problem is that when you print text to a file or stdout, it uses the locale encoding. if you don't set the locale, then it assumes the C locale, which means ASCII-only.
<daviid>hello guilers
<daviid>davexunit: i looked carefully at alternatives to gitorious and indeede could not find any. if you have any news wrt this, please let me know
<davexunit>there's Gogs, written in GO.
<davexunit>Kallithea, written in Python
<daviid>i did see kailthea, but it is the s/w, no hosting facility unlesss mistaken
<davexunit>you'd have to host it yourself
<davexunit>a public Gogs instance
<daviid>ah. looking i didn't know that one
<davexunit>I'm hesitant to move my stuff there
<daviid>ok, why ?
<davexunit>it's yet another site that could shut down at any moment
<daviid>hum right. my problem with my own settting, or a setting we would set-up for us, guilers and other fsf/gpl 'activists' is that we would have to rent the server, ence another company ...
<davexunit>I'd trust a server that was transparently maintained and funded by the community
<mark_weaver>what about ?
<mark_weaver>it could surely use improvement, but maybe that's something we should work on together.
<daviid>mark_weaver: 1 of the problem i see is that you need to register a project, even nongnu. somethimes you want a git server for other things then fullprojects...
<davexunit>mark_weaver: my issue with is that it's not a general purpose code hosting site. I'm okay with the requirement that everything hosted there be free software, of course, but I have repos for all sorts of silly things like my emacs config, misc dotfiles, resume, etc.
<alezost>mark_weaver: wow, thanks for the "setlocale" tip!
<daviid>yeh, that's what i ment :)
<daviid>we need a gitorious like set-up. we could even fork gitorious, the problem, afaic is ther server, where how much ... can we trust the company beind...
<daviid>davexunit: the fsf itself does not rent space/server till now right?
<davexunit>daviid: we use our own hardware, hosted in colocation spaces.
<daviid>colocation you mean fsf rents servers?
<daviid>ah you rent space butn the servers are fsf i guess
<daviid>anyway, could be an idea to make money, rent space/server(s) to us, that would be awesomew
<daviid>i mean the fsf would setup a service, payable, that we could use...
<daviid>i'd rent a server now!
<mark_weaver>daviid: that idea has major problems
<daviid>mark_weaver: too bad
<mark_weaver>first of all, last I knew (admittedly long ago), the colo space used by the FSF was gifted to the FSF.
<daviid>i'd love to rent a server with the fsf
<davexunit>yes, the space is a donation
<davexunit>both at Markley and MIT
<mark_weaver>it would also get awkward when people renting those server starting using them to host non-free software, or to promote ideas that are harmful to free software.
<davexunit>and we just don't have the resources to provide such a service
<davexunit>that would be spreading ourselves way too thin
<davexunit>our 2 sysadmins have more than enough work to do
<daviid>i understand, was dreaming...
<davexunit>if we had the means, I think the FSF would host a git server for the community
*wingo does the first guile compiler hacking he's done in a whiiiiile
<wingo>still have no real idea why compiles take so much memory
<wingo>i have a theory but it might not be right
<wingo>compiles only take so much memory in the interpreter btw, but it's a definite bootstrap issue
<daviid>wingo: hello! any news wrt merge-generics setting @ expand time using master? i'd like to go further with my tests with g-gnome, g-clutter and kisê using master ...
<wingo>nope haven't looked at it
<wingo>is there a bug/
<daviid>i think so, did you not try the short example i posted here a while ago? let me find it again
<dsmith-work>wingo: Cool! Glad you are thinking about bootstrapping issues.
<wingo>daviid: i remember the example more or less but wanted to make sure it was recorded in a bug :)
<daviid>oh, i wanted youto try, it will take sconds only, before to report it as a bug :)
<daviid>let me paste again
<wingo>best to report as a bug directly :)
<wingo>closing an invalid bug is cheap
<wingo>but remembering where you were in the conversation without records is hard :)
<wingo>lloda: another thing we could do if we imported libgc would be better memory tools
<wingo>like a memory profiler using dominator trees
<daviid>ah ok, will report now then, i thought you had an infinite memory :)
<wingo>lol no :)
<davexunit>+1 for anything that improves the GC
<davexunit>the GC can turn my silly little video games into poorly animated messes :)
<davexunit>I try to allocate less but it's hard
<wingo>yeah i know what you mean. hard problem.
<davexunit>I bring it upon myself because I choose to model game state with persistent data structures.
<wingo>lots of short-lived allocations, or a mix?
<davexunit>I think mostly short-lived allocations
<davexunit>I still do too much floating point math
<davexunit>I've reduced it a lot by using CBLAS functions for matrix multiplication
<wingo>we can help floating-point math with the compiler
<wingo>getting a pauseless gc is hard tho
<wingo>azul's c4 does it, it seems
<davexunit>I want to tackle particle systems soon
<wingo>not sure if enough to not perturb 60fps, but certainly for 30fps
<davexunit>but updating an OpenGL mesh each frame with thousands of particles will be rough
<wingo>sure you want to do it on the cpu side? :)
<davexunit>in my case, yes.
<davexunit>for regular particles, no, but I want to write one of those "bullet hell" games
<wingo>in guile we should be able to use types to mostly not allocate flonums
<wingo>and at that point you're halfway there
<wingo>still need to keep control on maximum pause time tho
<davexunit>so there will be thousands of moving objects on screen that have hitboxes and such that need to be processed on the cpu
<davexunit>they aren't just visual effects
<please_help>why don't you use instancing?
<davexunit>please_help: that will help
<davexunit>but you're still filling up some buffer to send to the GPU every frame
<please_help>only once per bullet type
<davexunit>each bullet has a different position
<please_help>instancing takes care of that
<davexunit>if the buffer stores positions as f32s
<please_help>or rather, the GPU does, and you tell it to take care of that by setting the mode correctly
<davexunit>there will be a lot of heap allocation to stuff things into the bytevector
<please_help>ah, I see
<davexunit>wingo: that would be a welcomed improvement.
<davexunit>I've been saying this awhile, but I'm approaching a 0.1 release of my game engine that I've been tinkering with for too long.
<wingo>davexunit: the (language cps types) module can infer most things locally
<wingo>so we just need to propagate that down to either native code or to the vm
<davexunit>so the programs built with it may prove to be useful for finding bottlenecks and such
<davexunit>wingo: interesting.
<davexunit>I haven't been brave enough to explore that :)
<davexunit>I've gotta run now. thanks for sharing your thoughts, wingo.
<davexunit>I'm confident that in the future guile will be able to do everything I would like. :)
<please_help>lloda: I flattened the array as you suggested. This gave me a massive performance boost (I'm approximately 3.33x faster now). Still a ways to go, but thanks. I was still erroneously thinking that make-shared-array kept the lambda for index conversion so I didn't think to try this.
<please_help>Very simple function (a logistic sigmoid):
<please_help>Anything I can do to speed it up?
<mark_weaver>please_help: unfortunately, at present all floating point numbers in Guile need to be allocated on the heap.
<mark_weaver>I don't remember the details of your array-ec and :array things, but that's the cost I know about.
<please_help>Array-ec and :array can be assumed to be Good Enough (tm) for now. I see, that's unfortunate
<please_help>Calls to array-ec and :array are actually not too long anymore, but a lot of the runtime is spent in the sigmoid. This and make-shared-array seem to be the bottlenecks
<please_help>Array-ec, :array and increment:
<please_help>Increment is slow, and I'm trying to phase it out.
<sirgazil>Hi :)
<sirgazil>I'm getting started with Guile and was wondering why readline is not activated by default...
<davexunit>sirgazil: licensing
<davexunit>readline is GPL, guile is LGPL
<sirgazil>I see, thanks, davexunit.
<sirgazil>davexunit: where can I find your games written in Guile Scheme?