***wxie1 is now known as wxie
***wxie1 is now known as wxie
***wxie1 is now known as wxie
<luxurymode>Does DrRacket support it? Can't seem to find any info online. <daviid>luxurymode: i kow nothng about mac, but if available, mos of us use emacs+geiser - drracket is 'stricktly' for racket, afaict <daviid>guilers, is there an easy way to ask for backtrace not to truncate? i kind of remember someone asked, and iirc there was a possibilty using an env variable? <spk121>daviid: the backtrace command has two options. #:width <a number>, and #:full? <a boolean> <daviid>what about when we run a script in a terminal? thugh i can load the script and call main .. <spk121>in that case, set the environment variable COLUMNS <daviid>since i improved <closure> and <signal>, which manipulates GValue(s), I now have a wierd bug wrt <function>, which manpulate GIArghuments, how is that? :):) <spk121>It is weird that there is GIArgument and GValue. They should choose one or the other <daviid>spk121: i had a long converation with the team a while back about exactly this, for us it's twice the wrk, ful of potential bugs, but ... so they say giargumenta are 'more powerfull', gvalues couldnt ... so i answered why didn't you extend/improve gvalue ... i still beleive that's the way they should have done things <daviid>anyway, it was more a 'cusiosity of mine' chat then a wish to change, it would be next to impossible to change 'now' ... to much has been done, to many years, to many depenencies ... <daviid>ah, there is 'a link', what fails is g-closure-new-simple, i guess somethng is wrong with my <closure> enhancement, i'll find out <daviid>spk121: are you using python, or just C and scheme? <str1ngs>daviid: do you know if gir files are used by GI. or are they only source reference and the typelib is used. I would imagine it's the later? <str1ngs>for context when resolving shared libs <daviid>str1ngs: i thnk they are used to compile tose into typelibs <daviid>str1ngs: there is a document somewhere which describe the prcess of how to builda typelib <daviid>str1ngs: now we, gi api users, do not use gir file, afaict <str1ngs>right, I just trying to figure out tybelib issue and if GIR_PATH I think thats the name would effect it <daviid>str1ngs: i don't much about the 'intern cooking' of those i'm afraid, better ask on #introspection <str1ngs>generally gi-scanner scans headers creates a gir file and that used to generate the typelib <daviid>i do visit gi files from time t time, to double check enum and flags values mostly <str1ngs>I think the gir files are installed for reference <str1ngs>nomad generates a typelib but it use m4 marcros so it's kinda abstracted. I should probably pay better attention to this. <daviid>i think they are complete, not just headers <daviid>ok, just wanted to (try to) be 'correct', just in case ... <str1ngs>the nice thing about use a typelib with g-golf. is I get one to one functions/methods without having to use SCM_DEFINE. it's kinda nice <daviid>yep, but about all this, you'd better talk to them, on #introspection, i'm really not knowledgeable enough to help <str1ngs>when talked to #introspection about this guix issue. they seemed to think that multiple store path of a library are being loaded which is kinda the impression I'm getting as well. but I have yet figure out away to test that theory. <str1ngs>#guix is saying it could be GI_TYPELIB_PATH order, which could make sense. but that seems pretty brittle to me. <daviid>str1ngs: are you refering to this g-golf test failure on #guix? because if, there is only one path for all typelbs right? the same for all, afaict <str1ngs>daviid: guix has a patch that hard codes the shlib path when generating a typelib <daviid>str1ngs: i m a bit to busy now, with this closure/signal enhancement <daviid>and then, know next to nothing about guix (internals) <str1ngs>if I disable that patch we don't get class already define etc. and tests won't fail. but it's not ideal to remove that patch for guix. <daviid>i remember the #intrspection firends mentionning that it was the symptom of multiple typelib <daviid>i hope some guix super pro come t help you there ... <str1ngs>I think if I'll play with ordering and maybe I can find a culprit and hopefully fixing that will resolve it. <daviid>but why would guix have two version of the same typelib? <daviid>iiuc that that is the problem ... <str1ngs>it's probably that there are two paths for a shared library. one typelib load one and another loads the other <str1ngs>they are not different version even just not the same path <str1ngs>because the shard libary paths are hardcoded to ensure functional inputs <daviid>you can ask the typelib path using g-golf, if that hepls <str1ngs>I have been using that . depaste is not working for me so I can paste my test script <str1ngs>there is not obvious multi paths. but I think it might require recursive depends to catch this issue <daviid>str1ngs: maybe post a message on guix-devel, asking for help ... don't know <str1ngs>i've been holding off until nomad and g-golf closer to a release. then it will be more important to fix <str1ngs>not a rush, just nomad and g-golf are still moving targets which is okay. <daviid>i understand, but it is not a g-golf problem, and won't go away 'alone', might take some time to fix, and it would be nice to have a 'good/strong' guix package soon, so imo, the sooner the better <str1ngs>right, I've been picking away at it myself. it's just that I use g-golf mostly and I have not submitted a patch to guix yet for that. mainly because I'm busy working on nomad. <str1ngs>it's just a matter of priorities. I wish I had more details on the issue to send an email as well. <str1ngs>right now my test script that was failing is not failing now lol <daviid>maybe you can suggest nly to resend his bug-report to guix, syaing that upstream make check pass <str1ngs>that's a good idea. I'm not effected by this like him because though I use guix I develop nomad mostly locally <daviid>str1ngs: i have a working solution to the signal callback args that hold a pointer to an array of utf8, filename and ... interface :) <str1ngs>I'm still waiting on the first example haha <daviid>now, these warnings are new, anda bit scary: (g-golf hl-api function) doe not define nor re-export the (g-golf gobject) module, nor any of the g-closure-new-simple, g-closure-ref and g-closure-sink - i have no idea, except that it is a module related problem of course ... we'll see <daviid>ok, i didn't push yet, i need to clean, i'll do this tomorow or the day after ... <str1ngs>no worrie, and no rush. I just can't look at the example here <str1ngs>daviid: might be a routing issue. I just used a browser via X11 forwarding from another geo location. this examples looks about right to me. <spk121>daviid: it is all C and Scheme. Some of the original C came straight out of the PyGObject, but, it is mostly unrecognizeable as pygobject now <killmeplease>you may need the -C in there if the connection isn't really fast. It's also quite latency bound so it could be that <efraim>I'm trying to use scandir to get return a list of .scm files in a directory but i'm getting caught up on the select? part of the function. I'm not sure how to reference each file for the test <RhodiumToad>the select? function, if you provide one, must be a predicate, meaning it's called with one arg <efraim>I was trying to do it without defining it outside the function, once I defined the function I could pass that for select? and it all worked <RhodiumToad>e.g. (scandir "." (lambda (fn) (not (string-any #\. fn 0 1)))) <RhodiumToad>(scandir "." (lambda (fn) (not (char=? #\. (string-ref fn 0))))) <roptat>also the example uses file which is undefined <chrislck>iirc you need add-to-load-path current .scm <roptat>that doesn't really seem to help <chrislck>are you calling lcov via something like "../lcov/bin/genhtml /tmp/lcov.info --output-directory html" <roptat>yeah, it says coverage is 0% (0/some number), functions are 0/0 covered <schaeffer>for anyone using 8sync; what's the most appropriate way to handle mutex logic? i'd like an actor to only process one message at a time for a resource it owns (a counter in this case) but from what i can tell actors will potentially handle many messages at a time, not just one <spk121>roptat: I'd like to figure that out too. I've got lcov working for the C side of a C+Guile library but not on the Scheme side. <chrislck>odd. lcov never gave me trouble as above. <roptat>not sure what it means, but the lcov.info file I get is full of these lines: DA:536,0 <roptat>always 0 at the end, so it looks a bit suspicious <apapsch>schaeffer: usually in an actor system each actor has their own private message queue, thus processing one message at a time, but I don't know about 8sync <apapsch>how do you tell it processes messages in parallel? <mwette>I have a syntax-rules with (pat exp ...) transforming to (begin exp ...). If the source is (my-pat) I get an error from ice-9/psyntax-pp.scm that says "syntax error: sequence of zero expressions in form (begin)". Why is this a syntax error? <mwette>got it: begin requires at least one expression <mwette>I changed to expand exp ... as (begin (if #f #f) exp ...) <killmeplease>It could be that I don't use Google actually - hopefully not <nly>is this a good idea? <nly>(set! %load-should-auto-compile #f) in "~/.guile" <nly>it speeds up using guix-modules(compiled) in local checkout, which doesn't make any sense to me. but i'll take it. <Marnen>Hey there! I'm having what looks like a Guile segfault issue, and I can't figure out how to troubleshoot or fix it. I've been packaging 64-bit Mac builds of LilyPond, which includes libguile 1.8. The builds work well for myself and for nearly everyone else, but one user (on Mojave, as am I) consistently reports a segfault right around the time <Marnen>I just really don't know where to start in figuring out why Guile is segfaulting on one particular build on one particular computer. <mwette>Marnen: try searching trac.macports.org; IIRC, macports has lilypond