***scs is now known as Guest71617
***scs is now known as Guest51225
<artup>Hello all. I'm a Guile newb following a Scheme tutorial video on pairs and lists. I have (define mylist (cons 1 (cons 2 (cons 3 #nil)))), but why does (equal? (list 1 2 3) mylist) return #f? The only thing I'm doing differently is using #nil instead of null, which Guile doesn't seem to have. <artup>davexunit: Ah, gotcha. It returns #t now. Thanks! ***scs is now known as Guest64289
***scs is now known as Guest81458
<janneke>sneek_: later tell nly: the idea was to do that automagically to not build hello-emacsy when there is noo freeglut. let's find out what goes wrong there. --without-examples is an ok workaround, i hope we can remove that and else learn why we can't <str1ngs>janneke: we can have examples not build if PKG_CHECK_MODULES fails. but there are quite a few dependencies there <janneke>hi nly, just tried to say that configure.ac uses the HELLO_EMACSY conditional to not build hello-emacsy when there is no freeglut, possibly there's a bug there <janneke>str1ngs: yes, configure only checks for freeglut and gl -- but it was about missing freeglut right? <janneke>oh, have you talked to piere yet, he contacted me about `next' and nomad <str1ngs>janneke nope, I have not heard from piere ***scs is now known as Guest7032
<str1ngs>janneke: the issue was debian does not have freeglut 3.0. And the debian user didn't want to install the examples . So as long as we make it optional I think that works. however that maybe <str1ngs>janneke: I also added guile 3 support to configure.ac I did'nt see any issue with my limited testing under 2.9.3. But I had a small API breakage due to change-class. And I was wonder if we could make <text-buffer> a metaclass of <redefinable-class> . since it's really hard to deal with scratch and *Messages* otherwise <str1ngs>or maybe there is away I can modify <text-buffers> metaclass in which case we can leave it <nly>HELLO_EMACSY conditional is kind of 'automagic'. Someone else had problems with freeglut versions in debian. For now, a '--without-examples' configure flag will workaround that(on branch wip). And it builds apparently. <nly>emacsy/examples were using freeglut 3.0 but debian had an older version or something like that <nly>well, what str1ngs said now that i read it^. <str1ngs>only hello-emacsy uses freeglut the rest are more reliant on webkit <str1ngs>maybe we can just remove AC_ARG_WITH and AS_IF ? <str1ngs>though manual turning them off is a good thing too <nly>rant had the problem even with am conditional <nly>i didn't, because of guix maybe <janneke>ah, so configure's pkg_check_modules and am_conditional are not working as expected? it should check for freeglut >= 3.0 <str1ngs>nly: that reminds me I have an issue both with g-golf and nomad and dynamic-link not working <str1ngs>nly: nomad works at build time atleast but I use libtool that might we why it works <str1ngs>nly: but not g-golf won't build. does it build on guix system? <str1ngs>if you get a dynamic-link libgirepository file not found let me know <daviid>str1ngs: that is guix issue, not a g-golf issue <str1ngs>daviid: yes I just need to make sure it happens on guix system <daviid>guix does use libtool, so you ned a phse that change the dynamic-link args to their full pthname location on your guix <str1ngs>what I mean is I use libtool in pre-inst-env but I'm dynamic linking within my project <daviid>libtool does not work on guix, afaict <str1ngs>so yes, libgirepository need to be added maybe as a LD_LIBARY_PATH? <daviid>you need to talk to guix people janneke would know, to choose the best approach to build g-golf on guix <str1ngs>nly: we could substitute dynamic-link is only used in 4 places <str1ngs>nly: it would be more foolproof as well <str1ngs>daviid: yeah this is easy to resolve . I'm only using this internally for nomad for context <daviid>str1ngs: to build from the source tree, select the devel branch, and a phase to change the feww dynamic-link calls should be enough, on guix i mean - any othr distro that use libtool would just be fine running the autogen/configur/make/make check/makeinstall danse <str1ngs>daviid: sounds good, I'll just substitute those libs ttyl <nly>i get beyond libgi 1.0 after setting ld lib path <str1ngs>LD_LIBRARY_PATH is kinda not good of foriegn distro's <str1ngs>I don't know if it's encouraged even on guix <str1ngs>I think just substituting the lib paths in the dynamic-link call is much safer <str1ngs>also it based on inputs inputs so functional <str1ngs>and I think when the absolute path is used . you must have .so extension IIRC <str1ngs>libg-golf might need substituting at a different phase or check might fail <str1ngs>that might not work due to byte compilation. for now you can not substitute it . should still build <daviid>str1ngs: oh, could paste here a 'real' test call for webkit-network-proxy-settings-new - and the expected result to, if possble, so i can check and add a test to the test-suite ... whenever you can of course, now we have logs ... <str1ngs>daviid: yes, I'll put a test together. you want this in scheme or C? <daviid>here i did this, scheme@(guile-user)> (webkit-network-proxy-settings-new "altosw.be" '("example.com" ".example.com")) <daviid>the test does not fail, but it does ot seem to do anything , the result is an empty list, i'd expect 'something else, may my test is 'stupid' <daviid>yes, but i didn't push yet, hence i ask for a typicall call <str1ngs>ahh gotch will put something togeter <str1ngs>wont be till tomorrow morning though. it's late now <nly>currently that will return a pointer <str1ngs>nly: this is in g-golf so it will return a class <nly>it's return will be used by proxy-set or equivalent <str1ngs>right, like the C functions but just in scheme <daviid>nly, yes in C, in scheme the C struct is converted to a list of its element ... <str1ngs>also we can use this for proxy as well <str1ngs>nly: if you see the webview.scm you see it in herits <nomad-webview> which is a GObject class <str1ngs>nly: we we can treat a buffer as a <web-kit-web-view> directly <str1ngs>nly: so if you need to pass a view to a setting or vise versa. you just pass the buffer as is <nly>sounds like java lol <nly>jk, idk what i am talking about <nly>janneke: this freeglut thing was reported by rant on #nomad-browser, they can test it and give more info maybe <str1ngs>nly: actually it's almost identically to websettings.c but without C <str1ngs>nly: so in the future if we need additional webkit features. there available via g-golf <nly>how about bindings to other things? lol thinking about mpv for playing videos etc <str1ngs>and we can offload more things. but I'm just piece mealing for now <str1ngs>in terms of bindings I'm keeping NomadWebView which is a basically a GObject inherited from WebKitWebview <str1ngs>so we can still add things from C. and it will be seen by scheme. we just won't need to snarf anywmore <str1ngs>nly: the big things is when we add new protocol support like gnunet <lloda>in Guile apparently applicable structs are procedure? <lloda>wasn't sure but it makes sense <nly>str1ngs there is one more way to resolve dynamic-link issues <nly>maybe init.in file with @libgirepository@ and pkg-config? <nly>g-golf builds now with test off <nly>some error along the lines "clutter typelib not found" <daviid>nly: you need to install the gir file/package for clutter ***scs is now known as Guest74994
***scs is now known as Guest14482
***scs is now known as Guest47358
***scs is now known as Guest27383
<str1ngs>daviid. does (webkit-network-proxy-settings-new "127.0.0.1:80" '("*.gnu.org")) return a list for you? in terms of char** support? <str1ngs>eg. (class-of (webkit-network-proxy-settings-new "foo" #f)) for me returns a null list. I'm wondering if passing a lists of ignore_hosts returns the the ignore list hosts. in which case we can just assert-equal the returned list. <str1ngs>sneek_: later tell nly. substitution looks good. Ironically I had a commit almost identical to yours. ***scs is now known as Guest20492
<dsmith-work>str1ngs: Unfortunatly, when the bot appears as "sneek_" it seems to ignore commands. <dsmith-work>I think some response from freenode changed, becuse it used to attempt to change it's nick back. <str1ngs>sneek: later tell nly. substitution looks good. Ironically I had a commit almost identical to yours. ***jao is now known as Guest23817
***jao- is now known as jao
<daviid>str1ngs: scheme@(guile-user)> (webkit-network-proxy-settings-new "127.0.0.1:80" '("*.gnu.org")) <daviid>I've asked on#introspection to see if an empty boxed type is 'normal' <str1ngs>I'm still trying to find a better char** test. since proxy settings is hard to test without setting a context and a view. then doing a online test. g_application_run is another example but it blocks so not a good example either <daviid>i can push what i have, as a wip, would that help? <str1ngs>that would be great, I can atleast test with nomad, since i can't avoid online tests anyways <str1ngs>and I'll find a better char** test for g-golf that does not involve blocking or online testing <str1ngs>oh one issue I found. when using g-irepository-find-by-name if the calling module does not import g-golf then type int32 is not found <daviid>let me push first, but please paste an example here <str1ngs>this is not a big deal. but it could be a potential problem with g-golf <daviid>everything that is not 100% expected and realiable is a big deal, thanks to point and still point all these bugs here, it is of a tremendous help <str1ngs>I can distill this further if you need me to <str1ngs>also I think (g-irepository-require namespace) should only be called once per process? <str1ngs>the latter question if for my on understanding not a bug <daviid>str1ngs: the paste, but what is the namespace and the content of lst? <str1ngs>example call would be (gi-import-objects "Gtk" '("Widget")) <str1ngs>I guess the issue is I'm calling g-irepository-find-by-name from another module. so the current module may not have g-golf imported. maybe I should not get fancy and just use g-irepository-find-by-name from the calling module <daviid>you should put the use-module outside your define, as a top-level expression f the module, then you should check that info is not #f before you call gi-import-object <str1ngs>daviid: ahh that's the thing g-golf is used at the top of this util module. <str1ngs>when you call gi-import-objects from another module? <daviid>you mport your module, (gtk) which you could rename of course ... <str1ngs>okay, it must be related to my imports then <str1ngs>okay I'll figure out why my imports are not working right <str1ngs>well use-modules . forget I'm not writing golang :( <daviid>it still imports to much, I need to fix that, but it shouldn't affect you <str1ngs>g-irepository-find-by-name works well but Gtk functions I have not figured out how to selectively import <str1ngs>when using g-import-funcion it's not much faster then (gi-import "Gtk") is what I mean <daviid>when you selectively import GtkWidget, it imports all it needs to work <str1ngs>I don't use many gtk functions so I can work around that. g-irepository-find-by-name and import Widget is the main one <str1ngs>the only gtk function I use is gtk-init and even then it's for tests <str1ngs>I just stubbed it out in my typelib so it's no bigg <daviid>str1ngs: I won't change the way selective import works, it would be a terrible mistake not to import what an imported GObject subclass need to work, perfectly work and as expected .. <daviid>wrt guix, tx, i wish a separate package, but i'll look at you def, tx <daviid>as it isthough, it would need a rebuild every day or so ... so those who wnt to participate/use may as well just clone the repo,checkout the devel branch and make sure guix sees it ... <str1ngs>if you want to snarf guile-g-golf I'll switch to using your upstream version for less redundancy <str1ngs>also the recursive copy needs for the orgin to be deleted. I think that's mainly for the inclusion in the proile <str1ngs>also guile invocation is LD_LIBRARY_PATH=/gnu/store/jc8911bn7zys2kimp4bh0s2ibv8bksia-guile-g-golf-1-1.722b6d6/lib guile <str1ngs>until I figure out a better way to handle libg-golf's dynamic-link the inputs are good now though <daviid>str1ngs: yeah, in the long run, i want a separate (gnu packages g-golf) <daviid>but, i still don't have guix here <str1ngs>yes, this was not intended for inclusion into guix, since you are the maintainer. was just for local builds only <daviid>i have far to much to do already <daviid>you should name it g-golf, not guile-g-golf <daviid>anyway, one day i'll use it, thanks <daviid>str1ngs: why this? (setenv "GUILE_AUTO_COMPILE" "0") <rekado_>all Guile packages in Guix have the “guile-” prefix <daviid>you should respect the original name , those which have guile- have that guile- intheir ame, i think <str1ngs>daviid: when compiling it guix it will try to auto compile for some reason <daviid>guile is already in the name ... ***scs is now known as Guest17205
<str1ngs>daviid: normally for this I set GUILE_AUTO_COMPILE in pre-inst-env.in . <str1ngs>or maybe guile.mk for g-golf I was'nt 100% if this was guix specific issue only <rekado_>daviid: it’s just convention. We do the same for all Python packages. <daviid>rekado_: i don't even understand why you do this, but fine <daviid>str1ngs: i won't change any ofthe g-golf upstream file, except those 'linked to' the 'no libtool on guix' <daviid>*I wuoldn't any of the g-golf upstream file, except ... <daviid>that would be the root for heisenbugs <str1ngs>no worries that's why I used GUILE_AUTO_COMPILE. though I'll look into it more see if something else is the cause <daviid>you should not set GUILE_AUTO_COMPILE to 0 either, this does not make sence at all <str1ngs>as far as I can see it's warning. it can't actaully write to HOME anyways <str1ngs>I mean I can not set it. but then it warns about not being able to auto compile <daviid>you should not set it and have zero warning of those <daviid>though using autotool, the danse compiles everything in order, so auto compile is ot triggered anyway <str1ngs>ah this is guix specific WARNING: compilation of /gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guild failed: maybe <str1ngs>$HOME is not writable when building some it can not compile guild <daviid>ok, i'll leave that to you , rekado_ and guixers <str1ngs>I think because guild is a script it will try to compile it. but this is outside the scope of g-golf's autotools. so should be okay to set it for that i think? <daviid>I beleive rekado_ knows what he's talking about :), but keep it setting in the guix pakg def, notin any g-golf upstream fileforget <daviid>and let's forget about my quiz, and hack <str1ngs>no worries, that's why I didnt mention it I figured it was specific to guix. since when building locally I don't run into that issue. I mainly work locally myself. but I maintain guix files for nly mostly <str1ngs>an maybe one day for inclusion to guix when I'm closer to an alpha release <daviid>ok, I should soon merge the g-golf devel branch in master <daviid>that would be a good time to add a guix.scm file in g-golf itself <str1ngs>the guix package is self contained the s-expression can be snarfed as is. it needs some tweak still to removed orphaned files ***scs is now known as Guest96681