IRC channel logs
2014-09-25.log
back to list of logs
<janneke>is srfi-45 the way to do memoization? <janneke>and how does that work together with goops? <civodul>promises are one way to do memoization, but at the call site (which may or may not be what you want) <janneke>the simple case, as described on the srfi-45 page says: <janneke>and then the gain is in the subsequent calls of (force s) <janneke>how do i replace the 32 by a parameter? -- why "memoize" a constant expression? <janneke>when i do: (define (s x) (delay (fib x))) <janneke>then all calls to (force (s 32)) are expensive/unmemoized so it seems? <janneke>pure-funcq seems to be what i want...but that's been removed from the reference manual? <mark_weaver>wingo: when linking a C++ program with libguile, can you think of any situations where the old garbage collector in 1.8 would have successfully marked a pointer from the C++ world, but Boehm GC fails to? <wingo>doesn't mean it's impossible but it doesn't seem likely to me <mark_weaver>the reason I ask is that I'm trying help David Kastrup with Lilypond, and he's seeing crashes that he suspects are guile objects being reclaimed prematurely. <wingo>i guess the possible difference would be objects referenced only from c++ unmanaged dynamically allocated memory <wingo>but that wouldn't work in 1.8 either without scm_gc_protect_object etc <wingo>which works in the same way in 2.0 <mark_weaver>well, right, that's exactly the case I was asking about. <wingo>i am pretty sure that the set of things marked by a program linked to 2.0 is a superset of those marked by the same program compiled/linked to 1.8 <wingo>can't be positive, but pretty sure <mark_weaver>wingo: are there any guile objects that are reclaimable in 2.0 but not reclaimable in 1.8? <wingo>mark_weaver: i don't think so, no <mark_weaver>wingo: any suggestions for how best to debug cases where a guile object is reclaimed while still being referenced from C++? <wingo>mark_weaver: GC_base() can tell whether a pointer is still referenced... <wingo>it sounds to me like it's a problem that an object isn't getting a scm_gc_protect when it needs one <wingo>could it be related to the SIGSTOP cross-thread pausing? <mark_weaver>I don't think so. I think Lilypond is single threaded, and actually the existence of parallel marking was causing problems for them. (I suggested setting GC_MARKERS=1) <wingo>so it could be smob marking functions <wingo>i suggest getting rid of smob mark functions to the extent that it's possible <mark_weaver>regarding GC_base(), does that search for pointers where marking wouldn't normally be done, e.g. in C++ unmanaged dynamically allocated memory? <mark_weaver>okay, my guess is that the SMOB mark functions are the likely problem, so we'll focus on that for now. thanks again. <wingo>np, it's a nasty issue that's poorly understood :/ <lloda>before define-values was included in Guile, I used this version <lloda>so here's the weirdness. In 2.0.9, that works fine either loading it from a file or in the REPL. <lloda>but on master, loading it from a file fails: <lloda>> In procedure vector-ref: Wrong type argument in position 1 (expecting vector): (#(9 9 9)) <lloda>while in the REPL, it works fine. <taylanub>lloda: you `define' the same variable twice. that's not allowed in files AFAIK <taylanub>making the second `define' a `set!' should probably do it? <lloda>oh... but I do that all the time. Or I used to. <lloda>I actually don't care to fix this define-values, since Guile has one now. I was going to ask for a way to conditionally define it. <lloda>like (if (defined? 'define-values) (do nothing) (define-syntax ...)) <taylanub>(FWIW, it's explicitly allowed in the REPL even by the RnRS because it allows you to copy-paste the new contents of a file and have all the top-level `define' forms redefine all the bindings, but it's not supposed to work in a plain Scheme program/library because it's essentially ill semantics. so it's just a convenience feature for REPLs) <paroneayea>is there something like (map) that removes all #<unspecified> elements? <lloda>I have no issue with the rationale, if it was consistent. But it should give a warning then, should it not? <taylanub>paroneayea: don't think so but there is `unspecified?' which you can use to `filter' the result <paroneayea>it's hard for me to figure out how to work with #<unspecified> since #<unspecified> seems to error out <lloda>(filter (lambda (a) (not unspecified?)) thelist) <lloda>(filter (lambda (a) (not (unspecified? a))) thelist) <lloda>taylanub: do you know how to do this (if (defined? 'define-values) (do nothing) (define-syntax ...)) <davexunit>section 6.10.6 Higher-Order Functions of the Guile manual has more <taylanub>lloda: on top-levels, that should work as you typed it; doesn't it? that being said, I would personally recommend against that form of reflection in the general case. when mucking with some dynamic run-time system then OK but stand-alone libraries can benefit a great deal from being as "static" and "declarative" as possible... <lloda>taylanub: I agree 100%; it's only to tide me over until I can move to master for good <taylanub>oh, I just remembered that something like (unless (defined? ...) (define ...)) will of course not work, since definitions aren't expressions and all <taylanub>lloda: you could use `module-add!' with `current-module' and such I suppose <davexunit>you can use syntax-case to conditionally expand depending upon whether or not the identifier is defined. <lloda>taylanub: define it anyway, but export only if defined? ? hmm... <taylanub>lloda: there should be something akin to `module-add!' which doesn't export. non-exported top-levels are still stored in modules <taylanub>(at least I thought so, looking into it now...) <lloda>if it isn't seen outside, it won't do harm. <wingo>you can certainly define the same variable twice <lloda>davexunit: I think I see how that'd work, but doing anything with syntax-case takes me a loong time <wingo>anyway, no neurons left today <lloda>wingo: I thought it was fine, too. any comment on the load/repl thing? <wingo>so few of them i can call them by name <taylanub>lloda: `module-define!' and `module-add!' don't export the binding; they essentially do the same thing a top-level `define' does I think <wingo>there are some differences in master related to top-level definitions though, perhaps this one is an incompatible difference :( <taylanub>I'd say such a thing shouldn't be explicitly supported anyway... <paroneayea>there must be a way to expand a list in a macro like this: <paroneayea>the difference being that what I get is (list ((+1 2 3) (+ 4 5 6))) type thing <taylanub>paroneayea: use (run-tasks task ...) instead of (run-task . tasks) ? <taylanub>paroneayea: I guess (list . tasks) would have worked otherwise <ft>#guile is awesome \\o/ <taylanub>I only wish we had somewhat more people :) <lloda>taylanub: it doesn't seem like I can use module-define! etc. with syntax. It takes a value. <lloda>wingo: I'll send it to bug-guile, then. <taylanub>lloda: hm, doesn't it work when replacing the (define var (car var)) with (module-define! (current-module) 'var (car var)) ? <davexunit>paroneayea: may I ask why this is a macro and not a regular procedure? <davexunit>I could be missing something, but it looks to me like it could be a procedure definition instead. <taylanub>lloda: (don't have master built so can't test right now) <paroneayea>and you're right, a lot of this could be procedures right now <paroneayea>partly I'm trying to learn how guile macros work... I understand the procedures <lloda>taylanub: it actually does! I was trying something else... but this helps. Thanks. <paroneayea>davexunit: okay... I guess I could have just used a procedure ;) <paroneayea>the only advantage is I get to avoid an extra (list) :) <davexunit>paroneayea: yeah, (define (run-tasks . tasks) ... ) :) <davexunit>paroneayea: you can shorten the map to (map exec-task (filter ...)) <lloda>(filter-map (compose exec-task (negate unspecified?)) task-list) or something like that <lloda>avoids building an intermediate list <davexunit>the filtering needs to happen before task execution <civodul>(filter (negate pred) lst) == (remove pred lst) <davexunit>I'm used to Ruby calling it 'reject' that I forget that it exists as 'remove' <davexunit>with our powers combined, paroneayea's code got a lot shorter <davexunit>paroneayea: oh yeah, (use-modules (srfi srfi-1)) <paroneayea>well, time to move aside my old hy repo for userops and start this guile version instead :) <paroneayea>who knows if anything will happen with it or not I guess... I'm currently working on building an ansible deployment for mediagoblin, and when I get annoyed, I'm working on this :) <davexunit>paroneayea: how do you like ansible? I haven't used it. <paroneayea>davexunit: seems like there are a lot of useful packages there, seems like the best of existing devops tools, and yet <paroneayea>it's YAML files because they don't want it to become a complex format with conditionals and etc, just simple config <davexunit>I want to focus a lot on writing/improving dev ops tools for guix. <davexunit>why didn't they learn from all the other projects in the past? <paroneayea>every time I get annoyed with it I write a few lines and plot a few more things in the userops orgmode file <davexunit>use a general-purpose programming language with an appropriate DSL <paroneayea>then a web UI on top of it that has some recipes for those who don't want to do that by hand, that just build a tree of tasks based on the web config <paroneayea>so you can either do it yourself via writing scripts, or you can use the higher level recipe system if you're not a programmer and use a simple web ui <paroneayea>I'm also somewhat inspired by Joey Hess's propellor <paroneayea>which works a lot like what I want, minus the web UI <paroneayea>davexunit: I might have something working not far from now. I'll let you know. <paroneayea>would be nice to have good guix integration too (though I think guix probably isn't a full deployment system on its own) <paroneayea>and if enough is written in guile, having tasks that generate a guix config can't possibly be hard <davexunit>paroneayea: I think guix has all the low-level tools needed. Nix has nix-ops for this stuff <paroneayea>though, I think I also want to be able to deploy to non (gui|n)ix systems <paroneayea>I almost said *ix, then I remembered that captured something else OS-wise <davexunit>right now I'm focused on using guix for software development to replace tools like virtualenv and pip <davexunit>I've hit a dead-end temporarily, but I'm optimistic that the issue will be resolved. <paroneayea>I think I'll be exploring guix, and I'm interested in guix ops type stuff, maybe it can be a basis of some of this, but I think I definitely want a way to deploy to non-guix stuff easily <paroneayea>I don't think *any* of the existing "devops" solutions solve the problem I want to solve <davexunit>yeah, the average person won't be running guix. <paroneayea>it means usually some big company is deploying things <paroneayea>I want somethign to make deploying free network services easy for everyone <paroneayea>none of this stuff does that, because they're aimed at the big corporate players *taylanub realizes that `values' is a generalized version of `identity', working on an arbitrary number of values :P <davexunit>I hope to some-day be able to show you a Guix OS config for a mediagoblin server. <paroneayea>I also need to learn autoconf finally... both because of this stuff, and also because we have autoconf stuff thanks to brandon invergo for mediagoblin kinda, but it's not really working right :\\ <paroneayea>users kept being confused so I had to rename the bootstrap script to experimental-bootstrap.sh for now until I get it working again <paroneayea>(and brandon did great work, I'm greatful for that help!) <mark_weaver>lloda: guile 2.0.11 has define-values, so you don't have to wait until master for it <mark_weaver>guile top-level allows repeated defines, but according to both R6RS and R7RS, it's an error to define the same identifier twice from a module top-level. <lloda-2>mark_waver: I know define-values is in 2.0.11, but I can't use that because it's missing the array patches that I wrote on top of 2.0.9 and that went into master. <lloda-2>with taylanub's fix it's enough for me until I can leave 2.0 for good. <lloda-2>so the repl doesn't count as a module top-level? is the different behavior btw repl & load ok? even if 'it's an error' means 'you're on your own', would it be unreasonable to expect at least a warning? <daviid>hello. here is a guile-gnome compilation bug [will paste below] that is totally unexpected: I haven't changed anything in the g-wrap source code and I did not changed anything in guile-gnome either [since my last patches - pushed after compilation - make checks - and personal use long before pushing]. this leaves me with the assumption that it could be caused by some recent changes in guile [stable] itself. Indeed I recently pulled <daviid>the latest, GNU Guile 2.0.11.61-c6a7-dirty, and since it does not compile anymore. I also tried on another computer with a slightly earlier version then mine, but it fails as well [actually that's how I discovered, then tried my computer and surprise... here the paste: http://paste.lisp.org/display/143843 <daviid>this file it refers to is unchanged /usr/local/src/guile-gnome/git-clone/defs/gnome/defs/glib.defs, as well as the overrides file it includes. the g_main_loop_new api has not changed either <mark_weaver>sorry, I'm not able to tell from that what's going on. if you think it was caused by a change in stable-2.0, can you try to git bisect it? <mark_weaver>start by finding an earlier version of stable-2.0 that works. <daviid>mark_weaver: I am not sure, but from the analysis of the situation it sounds like it