<guiliug>Hi, I'm new to Guile (just started reading the manual). Is there any coding style guide for Guile? <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 <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
<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. <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>(so it's just 'some 24 tests' that are unexpectedly failing :) <wingo>DimStar: the 24 is for expected failures <wingo>the problem are the 47 failures <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 <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>it can be implemented in Scheme, using array-index-map! :p <wingo>sometimes i think we should import libgc <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? <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... <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 v.xxx <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>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>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 <wingo>but the threadiness is a good point that i didn't think of <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 <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>the section "integrating llvm with garbage collection" <mark_weaver>we are locking ourselves into a commitment to stick with conservative collection forever <wingo>hoo, i'm very happy about people not writing mark functions... <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! ***dje is now known as xdje
<wingo>that the cpu affinity of memory was being trashed by the marker ***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 <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>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) <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>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 <daviid>i did see kailthea, but it is the s/w, no hosting facility unlesss mistaken <daviid>ah. looking i didn't know that one <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>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 nongnu.org 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>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... <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 <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 <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 ... <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 :) <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 :) <davexunit>the GC can turn my silly little video games into poorly animated messes :) <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'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>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>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>but you're still filling up some buffer to send to the GPU every frame <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 <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>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. <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 <sirgazil>I'm getting started with Guile and was wondering why readline is not activated by default... <sirgazil>davexunit: where can I find your games written in Guile Scheme?