IRC channel logs


back to list of logs

***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.
<davexunit>artup: the empty list is '() not #nil
<davexunit>(cons 1 (cons 2 (cons 3 '())))
<artup>davexunit: Ah, gotcha. It returns #t now. Thanks!
<davexunit>artup: yw!
***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 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 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>and gtk of course
<str1ngs>maybe we can just remove AC_ARG_WITH and AS_IF ?
<str1ngs>the AM_CONDITIONAL work okay right?
<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>nly: okay good to know
*nly guix build g-golf
<str1ngs>if you get a dynamic-link libgirepository file not found let me know
<nly>yeah that's it
<daviid>str1ngs: that is guix issue, not a g-golf issue
<nly>libgi 1.0
<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
<daviid>*guix does not use libtool
<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
<daviid>have to go, bb tomorow
<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>nly for libg-golf output can be used
<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
<daviid>yes, jsut befone install
<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 "" '("" ""))
<daviid>$3 = ()
<daviid>in scheme
<str1ngs>oh you added char** support/
<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
<daviid>no problem
<daviid>it's ver very late here to ..
<nly>currently that will return a pointer
<str1ngs>nly: this is in g-golf so it will return a class
<str1ngs>yes, we wont need websettings.c :P
<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
<str1ngs>nly: no boxed pointers anymore
<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>that's my rough plan anways
<str1ngs>nly: the big things is when we add new protocol support like gnunet
<str1ngs>or dat etc
<nly>exciting :)
<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 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
<nly>do we need it?
<daviid>for the tests only
<nly>ok thanks
***scs is now known as Guest74994
***scs is now known as Guest14482
***scs is now known as Guest47358
<dsmith-work>Morning Greetings, Guilers
<dsmith-work>sneek_: botsnack
***scs is now known as Guest27383
<str1ngs>daviid. does (webkit-network-proxy-settings-new "" '("*")) 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 "
<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>ah good to know thanks
<str1ngs>sneek: later tell nly. substitution looks good. Ironically I had a commit almost identical to yours.
***jao is now known as Guest23817
<daviid>str1ngs: it returns an empty list. but i now see that its C struct def is empty, so no matter what, the result will always be an empty list
***jao- is now known as jao
<daviid>str1ngs: scheme@(guile-user)> (webkit-network-proxy-settings-new "" '("*"))
<daviid>$4 = ()
<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
<str1ngs>well int32 is ubunbound I mean
<daviid>let me push first, but please paste an example here
<str1ngs>here is my use case now.
<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
<daviid>let me look at itfrst
<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
<daviid>but let me try here
<str1ngs>daviid: ahh that's the thing g-golf is used at the top of this util module.
<daviid>str1ngs: this works fie here
<str1ngs>when you call gi-import-objects from another module?
<daviid>you mport your module, (gtk) which you could rename of course ...
<daviid>that's what i ddid in the repl
<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>that's fine
<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
<daviid>that's what I want
<str1ngs>yeah that works great
<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
<str1ngs>daviid: also g-golf package for guix if you need it
<str1ngs>it needs a bit more tweeking.
<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>err profile
<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
<str1ngs>just a FYI
<daviid>str1ngs: yeah, in the long run, i want a separate (gnu packages g-golf)
<daviid>but, i still don't have guix here
<daviid>so i'll let that to guixers ...
<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
<str1ngs>no worries
<daviid>you should name it g-golf, not guile-g-golf
<daviid>anyway, one day i'll use it, thanks
<str1ngs>will change the name :)
<daviid>str1ngs: why this? (setenv "GUILE_AUTO_COMPILE" "0")
<daviid>are you not compiling g-golf?
<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 .
<str1ngs>or maybe 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>that makes zero ence to me to
<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
<str1ngs>so it*
<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