IRC channel logs


back to list of logs

<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://
<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.
<daviid>str1ngs: for info and, where you can see they have a GObject-Introspection package ...
<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 :)
<daviid>great, i'm on bullseye as well
<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?
<wleslie>representing dictionaries?
<bavier`>anadon: guile has a nice peg parser
<anadon>bavier`: peg parser?
<daviid>any skilled/expert automake guiler here? I just added the following to my 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"
<bavier`>see "PEG Parsing" in the manual
<str1ngs>daviid won't adding g-golf/gdk/event-structures.scm to SOURCES have the same effect?
<daviid>str1ngs: it's to be removed
<daviid>if it exists
<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
<daviid>hence i ak here as well ...
<str1ngs>daviid does $(moddir) expand correctly?
<str1ngs>iirc local is the way to do this
<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 ./; ./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
<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>I'm using with-guile-site=no
<daviid>then it should be in $prefix
<daviid>what i do here is
<str1ngs>after make uninstall it should be removed correct?
<daviid>cd /opt2; ls -lsa | grep g-golf
<daviid>it should only lists dirs, after make uninstall, but it lsts the files tha i'mtrying to remove ...
<daviid>yes, that's the objective
<str1ngs>seems to be working for me
<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>but i don't want to use DESTDIR
<str1ngs>it's useful for testing.
<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>that does'n make sense :):)
<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
<daviid>no, i just dded manually
<daviid>thos lnes
<str1ngs>one sec let me pull with prestine triee
<daviid>it won't change anything
<daviid>i didn't push these changes, which is why sted
<str1ngs>still no orphans
<daviid>doesn't make sens
<daviid>are these files there after make install?
<daviid>and ./share/guile/site/g-golf/gdk/event-structures.scm
<str1ngs>I can't test with --with-guile-site=yes
<daviid>it shouldn't make any dffernece
<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>do run make instll
<daviid>and check these file re there
<daviid>i have a little doubt
<daviid>but ... i could be wrong
<daviid> i know
<daviid>wait a minute
<str1ngs>prefix is ~/local . see log
<str1ngs>this is after make uninstall
<daviid>i did alter the here to delete the entry i SOURCES
<daviid>bah, sorry
<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
<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'm an upstream guy
<daviid>no packahge manager
<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
<daviid>forget about prefic
<daviid>it has to work nor matter what
<daviid>with or without 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>str1ngs: for get about this
<daviid>i got tired
<daviid>i can't commit the preparation and it seems you don't understand, fair enaough
<daviid>i need an autotool expert
<daviid>add the lines, i pasted long above, remove the file from the list of SOURCES, run ./; ./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>let me verfiy this more
<daviid>ok tx
<str1ngs>ok here
<str1ngs>fix is for f in $(SOURCESTOREMOVE) see typo
<str1ngs>I suggest to use SOURCES_TO_REMOVE
<str1ngs>verbose easier to read
<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>it workd here to
<str1ngs>nobody likes orphaned files :P
<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
<daviid>have to go, bbl, tx
<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 changes, so it would not fail if these file do/did not exist ...
<daviid>str1ngs: here an updatd example that illustrate thse changes -
<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>I updated the doc as well
<daviid>(but in the distro, not on line yet)
<daviid>*in the source tree (not the distro)
<nly>roptat: hi!
<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
<mwette>if I can get it cleaned up
<dsmith-work>Happy Friday, Guilers!!
<abcd>dsmith-work: Howdy!
<civodul>hey, Happy Friday!
*spk121 isn't allowed to go to the office anymore
<spk121>happy Friday
<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>rlb: no idea!
<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>i really don't know
<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
<dsmith-work>Hey Guilers, have a safe and clean weekend.
<jackhill>thanks dsmith-work!