<daviid>str1ngs: right, wrt msys2, i really have been impressed by it, the overall thig and packages, and the devs are very nice, always happy to help in a friendly way, on #msys2 (irc://irc.oftc.net:6667/msys2) <str1ngs>daviid: when I get closer to need a new alpha release for nomad. I'll submit a g-golf.scm package if someone else has not already. <str1ngs>daviid: I might need to do a new alpha release for nomad. since it's about 260 revisions from my last alpha :( <daviid>ok, absolutely as you wish - I am gona concentrate on upstream 'only' - but I thnk you should start to talk with mainainers/contributors to solve the dynamicl-link 'bug' on guix <str1ngs>daviid: I have a better understanding to that bug and how to avoid it. <str1ngs>addition paths in GI_TYPELIB_PATH can cause problems. <str1ngs>also I noticed to order issues importing. but it's still not 100% resolved so I agree with you theree. <str1ngs>I have used msys2 before. it's mainly I just don't use windows :P <daviid>str1ngs: you shouldn't wait to talk to maintainers and contribuors, on guix-devel, to grab help and info on how to best solve this very serious problem <daviid>anyway, as/when you wish ... back to hack <str1ngs>I have discussed the guix issues in #guix some maybe guix-devel might be a better approach. though it's really hard to replicate the problem without including g-golf into guix. and possible even replicating the situation that causes it. <daviid>can't guix-devel participant just grab the package def anywhere you left it and try? <str1ngs>yes, it's just less work for people I guess. <daviid>str1ngs: it surely must be possible to work 'to prepare things' for later 'official inclusion in guix ... don't know but sounds plausible <str1ngs>daviid: I have done that with the g-golf.scm in the nomad source tree. short of this odd guix related issue. though it seems pretty stable right now for me. <str1ngs>daviid: I'm currently testing g-golf nomad on debian bullseye as well. due to getting a new pinebook pro :) <str1ngs>daviid: I like buster more then bullseye is it worth using on a regular basis? <str1ngs>I meant I like bullseye better then buster. <daviid>str1ngs: imo yes, but i have no option, the libs i need, not only for g-golf, but guile-cv, octave ... are far too old on debia stable (in general) <str1ngs>daviid that's the same issue I'm having as well. thanks for your input <anadon>Hello all. I'm trying to change from a eBNF grammar to Guile since eBNF does not play well with representing dictionaries. Is there any particular reference I should read for doing this? <daviid>any skilled/expert automake guiler here? I just added the following to my Makefile.am https://paste.debian.net/1135672/ and when i call 'make uninstall' or 'mke install', i see it displays the code in ther terminal, but the files are still there ... I wonder how to acheive the removal of 'old' mod/go files? <bavier`>anadon: "parsing expression grammar" <str1ngs>daviid won't adding g-golf/gdk/event-structures.scm to SOURCES have the same effect? <anadon>Looking at it, I'm not sure how it'll cover recognizing dictionary entries properly yet. I have a finite set of keys which can appear in any order and may only exist 0 or 1 times. <str1ngs>daviid: a this is an upgrade path that makes more sense. <daviid>I asked for help on #autotools, but so far didn't receive the correct' tip/trick to acheive the ressult <str1ngs>daviid does $(moddir) expand correctly? <daviid>str1ngs: i hope it does, if not, nothing wold ever instll ... <daviid>but feel free to add those lines and help to debug ... tx! <daviid>if you do, you must rerun ./autogen.sh; ./configure ... <daviid>if you wan to confirm $moddir expands, you may even add a printf: target tht does that ... <str1ngs>I assume this g-golf's topelevel Makefile.am? <daviid>yes, once we fix this, we'll do this for its corresponding doc file <daviid>str1ngs: tx, but don't loose too much time ... <daviid>you should have this file instlled, so you may see if what you do works ... <daviid>listing the cntent of the installed dir, after make unstall <str1ngs>yep ~/local/share/g-golf/g-golf/gdk/event-structures.scm <daviid>it should only contain dirs, but here, it lists the files that were not adequately removed ... <str1ngs>after make uninstall it should be removed correct? <daviid>it should only lists dirs, after make uninstall, but it lsts the files tha i'mtrying to remove ... <daviid>as well as after make install, but to debug it's easier to tests with make uninstall, till the files are removd ... <str1ngs>try with this instead . make install DESTDIR="$PWD/test" find t3est <daviid>it won't work for those of us who use --with-guile-sute, exactçy why it mst work with moodor, godir <str1ngs>for me when I make uninstall it removes all files. no orphans are left <daviid>why would it wok for you and ot here? <str1ngs>could it be --with-guile-sute is an edge case? <str1ngs>I'm behind by 3 commits would that be a factor <daviid>anything could be the bug, i just don't know <str1ngs>one sec let me pull with prestine triee <daviid>i didn't push these changes, which is why sted <daviid>are these files there after make install? <daviid>./lib/guile/2.2/site-ccache/g-golf/gdk/event-structures.go <daviid>and ./share/guile/site/g-golf/gdk/event-structures.scm <str1ngs>I can't test with --with-guile-site=yes <daviid>moddir and godir is what is used ... no matter what <daviid>but you didn't answer my last question <str1ngs>but when I run make uninstall . no files are orphaned <daviid>are these files istalled in the first place? <daviid>i did alter the Mkefile.am here to delete the entry i SOURCES <daviid>then you'll be in the same situation <str1ngs>no changes to any sources. and using commit cb53df6692281d34da84753b912d162c4c71d915 <daviid>str1ngs: delete the line of the source file <str1ngs>gotcha, so you want to remove this if it exists so the file is not orphaned once it's been removed? <str1ngs>sorry what I mean. is you plan to remove this file eventually so you want some upgrade path <daviid>i removed the file in the SOURCES entry in the top level MAkefile.am <daviid>and added these lines i posted to remove those from the moddir/godir if there are there ... <daviid>this is to clean users installed dris from the file that no longer is distributed ... <str1ngs>right, I'm wondering how import it is to add this <daviid>i was hoping not to have to commit inermediate state <str1ngs>this only effects people that use make install. and really they should be handling prefix ya? <str1ngs>package managers should not suffer from this upgrade IMHO <daviid>lstenm, i want this to work, not matter what <daviid>i want to remove the files that are no longer distributed, using autotool <daviid>the rest does not interest me, to be honest <str1ngs>I get the reasoning. just normally when people use make install. they need to handle prefix <str1ngs>so make install. remove the file from SOURCE. than run make install again. it should remove the file. sound right to you? <daviid>i can't commit the preparation and it seems you don't understand, fair enaough <daviid>add the lines, i pasted long above, remove the file from the list of SOURCES, run ./autogen.sh; ./configure ...; and then make uninstall <str1ngs>I do understand. stop insulting my intelligence <str1ngs>test/home/mrosset/local/share/g-golf/g-golf/gdk/event-structures.scm gets orphaned <daviid>i wonder why, here it displayes the lines refering to the uninstall-local target, as expected, but does not remove the files ... <daviid>may be a stupid bug, but i couldn't find what i did wrong <daviid>it seems the uninstall-local target is run first, then the autotool uninstall 'default' target steps are run <str1ngs>daviid: $(SOURCESTOREREMOVE) expands to nothing <str1ngs>so when it loops in for it does nothing <str1ngs>fix is for f in $(SOURCESTOREMOVE) see typo <str1ngs>same with GOBJECTSTOREREMOVE is a typo <str1ngs>seems to work when I fix those typo's WDYT? <daviid>perfect! thanks what a stupid typo <daviid>i shall work a bit more on this, still need to clean and add the gdk-event doc that was in the gdk-event-structures, the i'll push <daviid>will let you know when it's ready <str1ngs>okay let me know if I need to test anything ***sneek_ is now known as sneek
<daviid>str1ngs: I just pushed a patch, wrt the GdkEvent implementtion simplification I was talking about a while ago, with a (hopefully) good explaination in the commit log <daviid>str1ngs: i had to sligthly change the Makefile.am changes, so it would not fail if these file do/did not exist ... <daviid>note that on wayland there is no more diff between coords and root-coords <daviid>let me know if there is any problem with this quite long (bug prone) patch ... <daviid>(but in the distro, not on line yet) <daviid>*in the source tree (not the distro) <nly>how do you work with functions that give huge outputs? '(call-with-input-file "example.torrent" bdecode) <nly>emacs-geiser pretty much hangs <lloda>what could cause srfi-64 to ignore my setting test-log-to-file to #f? <lloda>i've pk'ed inside test-on-group-begin-simple and it's still #f whether I set! it or not. It's an exported variable, I don't get it. <lloda>(@@ (srfi srfi-64) test-log-to-file) gives the value I set :-( <nly>fixed an issue with reading bencode. better handling of non utf8 values. <lloda>apparently I cannot access test-log-to-file from outside srfi-64. The exported test-log-to-file appears to be a different binding. I tested this by definiting a function give-test-log-to-file inside srfi-64 which returns the internal value. <lloda>this looks like a bug, can anyone confirm? <lloda>mwette: I've tried your test. It looks like a libltdl bug to me from reading their doc but your patch also lgtm <lloda>why do I get 'attempt to include relative file name but could not determine base dir' when I do (include "file-in-this-directory.scm") ?? <mwette>lloda: the libtool code says "if it already has extension, load that"; the problem here is that the extension is not what it's looking for. <mwette>I will send the patch to the guile-devel elist *spk121 isn't allowed to go to the office anymore <rlb>wingo, civodul: I *think* I ran in to a case where capturing (class-of record-instance) didn't work quite right as a goops method specializer, but it does work sometimes. My question is, would we be open to the idea of making that a requirement (if it's not already the intention), i.e. that record types can be used as goops method specialization types "somehow"? <rlb>I ask because syntax expansion can handle records, but not goops instances which is sometimes useful. <rlb>i.e. being able to define something that both goops methods and the syntax expander can recognize/match. <civodul>could you submit an example to bug-guile? <civodul>then we'll try to draw the attention of wingo or someone else knowledgeable about GOOPS :-) <rlb>Of the case where (I think) it didn't work? I can try, but it was a while ago, assuming I'm right, so I might not be able to reproduce it. Right now I'm mostly wondering what we might be willing to *promise*, regardless of what we actually do now, because that could affect the way I design some things. <rlb>i.e. would we be willing to say that's expected to work, or do we intend for it to be "undefined"? <civodul>but if you have an example with what you expected vs. what you got, that might give ideas ***drakonis1 is now known as drakonis
<str1ngs>daviid: okay will try this out. the main one for me is 'key-press-event