<dsmith>Odd. Was able to stop the "overrides core binding" warning at work. Can't seem to stop it now. <dsmith>rm'ed the ccache and all is better ***sneek_ is now known as sneek
<dsmith>Anyone know if it's possible to add a docstring to a define-syntax ? <str1ngs>hmm good question I'm a assuming the docstring is for the actually macro. not something expanded? <dsmith>Yes! needs to be in the syntax-rules form, not define-syntax <str1ngs>nice, I happened across this the other day too. <sneek>Welcome back daviid, you have 1 message! <dsmith>Just might work for guile 2. Someone running guile 2 could test?.. <daviid>dsmith: nice, did you compare the module related code in (ice-9 boot-9)? <daviid>dsmith: ok, to answer your last quiz first, wrt cond-expand and guile-2, the guile-2 code should still use module-use!, imo <daviid>dsmith: for 3.0, i still need to look into the (ice-9 boot-9) changes myself, but it sounds strange 'as a first impression', that a lambda user would have to know and use the module internal structure, to pragmatically acheive what they can, in a module def, using #:export, #:re-export, #:replace and #:re-export-and-replace - in other word, it doesn't soud 'correct' to have to call (hashq-set! (module-replacements iface) sym #t) <daviid>if we need to keep that dcode, you might want top 'cache' (module-replacements iface) in the upper let i guess <daviid>but i think we might try to see if the binding exists, and use module-replace!? <dsmith>Most of the interfaces in boot-9 have a list of symbols as arguments. <dsmith>module-export! and module-replace! for example. <dsmith>But the interfaces are inconvinient. <dsmith>But probably the more correct thing to do is use #:re-{whatever} in the use-modules form. But again, that wants individual symbols, not whole module publics. <daviid>dsmith: well, the all point is not to have to write ansd use #:[re-]export* <dsmith>daviid: Yeah, that's the whole point of re-export-public-interface right? Passing in whole modules names instead of lists of symbols. <daviid>dsmith: right, and to comment your last comment, these module keywords are just the user interface, and call and run code ... that is the code we need ... so it is not anymore or less correct, imo - guile should have and maintain a re-export-public-interface, but it's fine to do it ourselves, it forces us to look and understand that part of guile better ... <mwette>Aurora_v_kosmose: agree. And I've hunted for help docs/code and not finding much. I want to write a tech note on how to use, but that'll take some work. <Aurora_v_kosmose>It says it's a translation of XPath, but a number of features either don't work or are hard-enough to guess I can't get them to work. <daviid>dsmith: we (or I at least) also need to exhaustively test absolutely all possible cases ... - the best is to list those possibilities on a paper :), imo, then write the tests - ok, I have to jump on something else, by all mean, but tx for your participation and code ... should be back later <dsmith>Sure would be nice to have a macroexpand-1 ... <daviid>dsmith: I still think module-use! should be patched in 3.0 though, let's see what our maintainers think about that, ifthey maniftes - iwhen they have some time ... and worth noting it is actually used several places in (ice-9 boot-9), including as a top level form in that file ... <dsmith>Does it the old way for non-guile-3 <daviid>dsmith: let me try, not sure if (cond-expand (guile-3 works in guile-2, let's see <dsmith>Should pick up the else for guile-2 <dsmith>That inner (define) might be an issue. Is that available in guile 2? <daviid>dsmith: all fine using it in guile-2 <daviid>i prefer let-rec, but that really is taste , not important at all <dsmith>That simple example seems to work for guile-3 <dsmith>$1 = #<procedure map (f l) | (f l1 l2) | (f l1 . rest)> <dsmith>Well, I learned a bit more of modules. <daviid>dsmith: there is one other case that is related but not covered by this syntax you did work on (with leoprikler indeed and str1ngs as well, tx all ...) <dsmith>daviid: One thing that is missing from the original, it does not check that the passed in module names are lists. <daviid>maybe we can add that check as well? doesn't cost much ... <dsmith>I think that would require using syntax-case. <mwette>Aurora_v_kosmose: yes. I think maybe '(// a (@ (name "example"))) might be woth a try <Aurora_v_kosmose>mwette: I actually tried that one. It doesn't, for some reason it can only understand having a field named (name) but the second you add the string it refuses the input. <Aurora_v_kosmose>mwette: In any case, it can't be helped. If I want to do it in guile, I'll just have to do it the longer way. <daviid>g-golf compiles fine using 3.0.4 now, but fails its checks, it actually can't run 'anyting' :) <daviid>but in a repl, connect correctly returns the generic function, and map the srfi-1 map ... so good progress, still work to be done <dsmith>daviid: Ah. Very cool. Progress! <daviid>probably due to declarative/none-declarative module change introduced in 3.0, it can't find anything it imports <daviid>it does successfully import, but the name isn't properly bound/exported from its imported module i guess <daviid>of course none of the check passes ... for the same reason <daviid>hum, not sure this is the cause - but this is very easy to reproduce outrside g-golf anyway <dsmith>I'm guessing g-object-import-with-supers might need to be tuned up. Just guessing. <daviid>dsmith: drop this somewhre, fire a repl, add-to-load-path, ,use (gobject), then (make-and-export-class '<gtk-window>) ... and try <gtk-window> <daviid>but in g-golf, there are several level of 'indirection, s to speak <daviid>several modules indirection i mean, which i am trying to reproduce outside g-golf as well <wingo>omg i just had the weirdest debugging morning <wingo>made some incremental compiler improvements. ran benchmarks to see how we did. ~everything was slower <wingo>but especially some benchmarks that were essentially allocation benchmarks <wingo>looked at the compiled object code -- no significant difference <wingo>wondered about jit tiering, if things weren't working <wingo>wondered about icache in the interpreter <wingo>wondered about differing optimizations in libguile <wingo>strange things. guile 3.0.2 was running ~40% faster <wingo>turns out the issue was that i had inadvertently improved memory usage, by a very small amount <wingo>enough so that for guile in git, the heap didn't expand as large as it did on 3.0.2 <wingo>and so with similar allocation rates, guile in git was having to collect up to 40% more often, for some benchmarks <wingo>because the working set size never exceeded the threshold needed to bump to a larger heap <wingo>these are small heaps, btw: just 3 or 4 MB <wingo>problem was exacerbated by parallel marking, which given the small heap size, wasn't able to effectively take work off the main thread's plate <wingo>solution is to bump the initial heap size. in the meantime we had slightly outgrown the initial heap size configured in guile; bumping from 2 MB to 3 MB not only speeds up startup by eliminating a useless gc, but also puts us at a different point on the curve, "fixing" this particular weirdness <wingo>need to re-run old benchmarks though <wingo>with the new heap conditions <mwette>So, is there an advantage to using a different allocation scheme for cons cells, assuming the bulk of scheme memory allocs are for cells? <wingo>mwette: not sure that is a good assumption fwiw. anyway in guile since we use the bdw-gc allocator there isn't really a concept of "cells" as exposed to the user <wingo>with bdw-gc you allocate any size data. it uses segmented free lists and allocation areas to allocate e.g. all 2-word objects in a contiguous block <wingo>and guile has a tagging hack to allow pairs to be represented in two words. so in practice guile does all that you would want to do; only the tagging hack is specific to pairs <civodul>i had also observed that sort of phenomenon in Guix, where using slightly less heap would mean taking up slightly more time <civodul>which is counter-intuitive and frustrating <wingo>i don't even know what the ideal solution is. i suspect that even the heap sizes i chose are too small for good performance <wingo>but i don't want to bloat the initial guile footprint too much <wingo> /opt/guile/bin/guile -c '(pk (gc-stats))' <wingo>;;; (((gc-time-taken . 0) (heap-size . 2097152) (heap-free-size . 622592) (heap-total-allocated . 1434032) (heap-allocated-since-gc . 1434032) (protected-objects . 0) (gc-times . 1))) ***terpri__ is now known as terrpi
***jonsger1 is now known as jonsger
<rlb>civodul, wingo (and everyone): I'm not sure it'd even be feasible (just now managed to remove 2.0 from debian), but I'm wondering if there are any strong arguments for/against keeping 2.2 in the next stable release, i.e. bullseye, likely releasing in about a year (freezing much sooner). <rlb>(Suppose the 2.2 -> 3.0 transition might be easier, given the work to move packages off of 2.0, but I won't hold my breath.) <dsmith-work>rlb: Well, there have been some modules changes between 2.2 and 3.0 that are causing issues for g-golf <civodul>rlb: i suppose there are packages stuck on 2.0 (that's the case for GDB until the upcoming release), but there are probably few packages that run on 2.2 and don't run on 3.0 <civodul>so presumably, there's little value in keeping 2.2 if you add 3.0 <rlb>OK, so that'd go in the "might want 2.2 so that people using g-golf will have it" category I suppose (since g-golf itself isn't in debian atm). Though if we think g-golf's likely to have things sorted out by next August, then might not be as important? <rlb>civodul: ok, thanks. <rlb>If I get my act together, the best thing would probably be for me to start filing the "please upgrade" bugs now. i.e. more likely to leave our options open. <civodul>ah, i'd expect g-golf to easily migrate to 3.0 <str1ngs>rlb: Hello, I would like to create a debian package for g-golf. Unfortunately my experience with packaging for debian is nil. Any suggesting how to best get started would be useful. is a PPA a good place to start for this? <leoprikler>whether you're packaging for a ppa or debian itself, I think you have to familiarize yourself with its funny makefile-esque packaging rules <rlb>Hmm, if you want package for debian proper, then not sure about ppas - never used them, and not sure if debian supports them directly. <rlb>I'd say, first off, *strongly* recommend debhelper. <rlb>Though I'm not sure, haven't read it carefully yet. <str1ngs>currently I'm maintaining the guix package. but since g-golf is a GNU project it would be nice to work towards a debian package. <rlb>In the end, with debhelper, if your needs are straightforward, you may only need a very simple debian/rules file, and then list what you want installed where in the relevant debian/*.install files, etc. <rlb>Also, while testing/debugging, fakeroot can be very handy. <rlb>i.e. you can run the whole package build without having to be root. <rlb>but for *real* builds, I wish I'd learned sbuild sooner. <rlb>Though if you intend it to enter debian proper eventually, source-only uploads are finally ready, so you can just let the buildds handle everything. *rlb thanks all those who made that possible. <str1ngs>source-only is a offload mechanism? also thanks for the advise I stick to upstream debian and avoid and ubuntu variation like PPA <rlb>Also potentially interesting git-buildpackage, git-dpm, and dgit. I use git-dpm, but I think git-buildpackage may be more common. Haven't tried dgit yet. <str1ngs>I might need git-buildpackage for now until later down the road. technically there is no g-golf release yet. <rlb>source-only is potentially better from a reproducibility perspective, from a "did the maintainer actually build the packages in a sufficiently isolated way" (e.g. sbuild) perspective, and possibly from a security perspective, though it does "centralize" things more, which has its own weaknesses on that front. <str1ngs>or I can give davidd a heart attack and tell him g-golf is now in debian lol <str1ngs>rlb: source-only does sound useful, takes some responsibility off me. <rlb>Previously, one set of debs (for the maintainer's host arch) would have been built on their own machine. <rlb>all the other archs were built by the buildd, so in practice amd64 was typically "not built by the builds". <rlb>given likely dev hardware :) <rlb>For guile module debs, we don't really have much/any policies atm, but in many cases, I assume that dropping the .scm and .go files into the proper dirs may be sufficient, unless you want to support multiple guile versions. <rlb>i.e. we don't have anything like debian-emacs-policy. <rlb>(Of course that's not nearly as notable as it used to be, now that we've "unversioned" the emacs packages.) <str1ngs>rlb: probably I will just target 2.2.7 for now least guile 3 is still WIP as this writting. <str1ngs>rlb: is guile-3.0 in buster it's in focal 20.04 so I assume so. <rlb>OK, and of course happy to have everything to move to 3 as soon as possible, then we'll have more flexibility wrt 2.2 come debian release time. <str1ngs>sorry I meant bulleys. got my toys mixed lol <str1ngs>I don't know why I use ubuntu. just seems easier to support end users for me. <rlb>Well, all part of the family, broadly speaking? <rlb>Oh, and if you end up finding that we need some debian-guile-polcy, just shout :) <str1ngs>I'm not so versed in policy, from what I have seen of guile packages re debian systems it's top notch. <str1ngs>even more so with the guix dependencies like guile-ssh guile-git. forget whole packaged those. but it's been really helpful. <rlb>(for emacs, we didn't ship the .elc files, so had to compile them per-installed-flavor at install/upgrade time, in proper dependency order, clean up, etc.) <dsmith-work>syntax-rules question: How match against lists. So to ensure that in (foo l1 l2 ...), the l1 and so on look like lists. (really: look like module names) <leoprikler>dsmith-work: you should really use syntax-case for that, but (foo (e1 e2 ...) ...) should *mostly* work