IRC channel logs

2019-11-04.log

back to list of logs

<spk121>finally got the new guile-gi 0.2.1 uploaded. phew
<daviid>spk121: congratulation!
<daviid>slightly ot, but not 'that much ot either': trying to compile guile-lib (from th source) on msys2, which has autoconf and automake, but raises two errors wrt our guile.m4 autoconf macros, here https://paste.debian.net/1113499/
<daviid>here is a copy of the latest guile.m4 macros http://git.savannah.nongnu.org/cgit/guile-lib.git/tree/m4/guile.m4
<daviid>so, the first error, PKG_PROG_PKG_CONFIG: command not found, is line 63 of our guile.m4 macros
<daviid>the second error correspond to the lines 81 and 82 of our guile.m4
<daviid>anyone familiar with win and/or msys2 could help? i did ask on msys2 (there on oftc.net, #msys2), there are very nice and usually help, but this question is a bit 'out of scope' for them ...
<daviid>now that i've asked, i may have to leave, the pace i'm working at will close soon ... if that happens, will read the log ...
<RhodiumToad>PKG_PROG_PKG_CONFIG is not from autoconf or automake, but from pkg-config, afaik
<RhodiumToad>not familiar with msys2 tho
<daviid>RhodiumToad: ah, will lokk ito this, not sure they have it on msys2, but will check, tx!
<daviid>not familiar either, jst started a few days ago ..
<daviid>RhodiumToad: i found the package, here (for info) https://packages.msys2.org/package/mingw-w64-x86_64-pkg-config?repo=mingw64
<daviid>RhodiumToad: tx! didn't thik about that by myself, I will try, but i have to leave now, bb tomorrow
<daviid>actually the package is this one: https://packages.msys2.org/package/pkg-config?repo=msys&variant=x86_64
<RhodiumToad>slow compiler is slow
<RhodiumToad>hm. but it shouldn't be _this_ slow I think.
<peanutbutterandc>Hello there, are there any guile-gnome hackers here (as suggested by https://www.gnu.org/software/guile-gnome/contact.html). I am a n00b with a few questions
<RhodiumToad>the guile-gnome guy is often around, but I don't know what times you're most likely to catch them
<RhodiumToad>however, ask anyway, I've been doing stuff using it recently
<peanutbutterandc>I see... That's great! First and foremost, what would you say will be the requirements for starting writing guile-gnome for UI and stuff for a beginner? I don't have any experience with gtk yet. Should I first learn gtk in C and then come back?
<RhodiumToad>do you have any experience with any other GUI toolkit?
<peanutbutterandc>No sir. Not yet.
<peanutbutterandc>Except pygame
<peanutbutterandc>if it counts
<RhodiumToad>and you're already familiar with guile?
<peanutbutterandc>RhodiumToad, I've been reading through a few books... and writing a bit of guix-package definitions for personal use
<peanutbutterandc>(and loving it!)
<RhodiumToad>my guess is that using gtk from guile will be a slightly easier introduction to it than using C.
<RhodiumToad>there are some examples in the guile-gnome source, they should be enough to get started
<peanutbutterandc>I see. That is such a relief. I don't have to learn C then. But I haven't managed to dig up a tutorial/manual thing for n00bs like me. Any ideas please? Could you please point me towards them?
<peanutbutterandc>Also, another question regarding guile/extensions in general. I want to extend gnucash so that day-to-day invoicing can be easier. And I want to integrate it seamlessly with the Gnucash UI so that anyone can use it without much trouble. While I am quite a long way off from that, I was wondering if what I am hoping to do can be done...
<RhodiumToad>I can't answer that one, sorry
<RhodiumToad>also I'm not much help when it comes to tutorials
<peanutbutterandc>I am under the impression that, if one knows how to do it, one can extend any program that has guile as an extension language to do anything at all.
<peanutbutterandc>I see...
<RhodiumToad>hmm. the compiler can't _possibly_ be this slow
<RhodiumToad>something must be wrong
<RhodiumToad>this code takes 2.5 seconds to compile on a fast intel cpu, but so far it's had an hour of cpu time on 32-bit arm and shows no sign of finishing
<RhodiumToad>ok, up to two hours of cpu time. this cannot possibly be working
<RhodiumToad>69 minutes in one thread, 15 minutes in each of three more, and a few minutes in another thread
<RhodiumToad>it's not even an especially huge or complex program...
<heisenberg-25>Anyone has experienced this issue?
<heisenberg-25>Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
<heisenberg-25>Aborted (core dumped)
<wingo>that's exciting :)
<wingo>never seen that
<heisenberg-25>I have set the GC_INITIAL_HEAP_SIZE=300G variable and running it on a server with > 300GB RAM, but it still fails :)
<wingo>in that case you may need to recompile libgc
<wingo>but, i have to say, stop-the-world collections on a heap that size will take a while!
<heisenberg-25>where can find the latest version?
<Harzilein>wingo: do you consider guildhall to be abandoned or are you still tangentially interested in occasional informal user reports?
<wingo>Harzilein: for me it's abandoned. i think some others may be using it tho, not sure. when i need a thing like that i just use guix
<spk121>After putting it off for three years, lets see if I can release guile-ncurses based on foreign objects instead of SMOBs
<wingo>nice!
<chrislck>a new guile-hall deserves the highest of fives o/
<chrislck>a new guile-ncurses* deserves the highest of fives o/
<Harzilein>wingo: perhaps guix could provide some guidance for people who only want it for the scheme side of things? i.e. they want it to be like virtualenv rather than pkgsrc
*chrislck is asked to rewrite a .scm function in C... oh so much pain:(
<wingo>chrislck: sympathies!
<wingo>is it for speed? how much faster does it need to be?
<wingo>or is it for another reason
<chrislck>they want to completely separate libgnucash (the engine, data, database) with gnucash (UI, reports). they wish to eradicate guile from libgnucash. that's it.
<chrislck>i've some heuristics in .scm to clean up old data and scm was shiny!
<chrislck>the idea is libgnucash can be portable to other OS eg iOS where interpreted languages may be difficult
*wingo nod
<wingo>yeah i guess i can see the reasoning :)
<chrislck> https://github.com/Gnucash/gnucash/pull/585/files#diff-bf2754900c3cc3b599e36a8f8df80194 is the super-easy-clean working scm which will expand to a mega-C multi-page headache :-/
<chrislck>night 'all
<RhodiumToad>hm. anyone want to guess why compiling a simple script doesn't seem to be completing, on armv7
<RhodiumToad>other stuff does compile, and there was no problem compiling the whole standard library
<RhodiumToad>hm. weird. putting an (eval-when (compile) (display ...)) form at the end of the file _does_ get run, after about the expected time
<wingo>strange
<RhodiumToad>but after that it just sits and east cpu
<RhodiumToad>*eats
<RhodiumToad>but other scripts work...?
<wingo>ah well actually that means it runs at expand-time
<wingo>so it's before compilation
<wingo>RhodiumToad: i assume you are on guile 2.2 ?
<RhodiumToad>2.2.6
*wingo nod
<RhodiumToad>running on an RPI 2B, originally using a cross-built copy of guile but a native-built one behaves exactly the same
*RhodiumToad tries deleting chunks out of the code
<RhodiumToad>ok, I think I've narrowed the issue down to one form
<RhodiumToad> https://dpaste.de/mK6R
<RhodiumToad>using for-cells just once, rather than nesting one inside another, doesn't trigger it - that compiles in under 0.1 second
<RhodiumToad>huh, there's a bug in that, but fixing it doesn't help
<RhodiumToad> https://dpaste.de/npBd
<RhodiumToad> https://dpaste.de/9gg6 <-- I think this is the smallest test case. Removing the reference to sym2, or using only one nested for-cells, allows it to compile quickly.
<RhodiumToad>in fact, just doing a (macroexpand ...) of the form can reproduce it
<RhodiumToad>no, scratch that, my mistake
<dsmith-work>Hey,
<dsmith-work>Morning Greetings, Guilers
<RhodiumToad>good evening
<roptat>hi, I'm using fibers for concurrency. on a fiber I want to use http-get (from (web client)), but it seems that it is using a blocking socket, and my program behaves strangely
<roptat>fibers manual says that I should use a non blocking socket instead, but I can't change the socket creation myself, so I tried to copy the source file for (web client) to my source code, and add the call to fcntl
<roptat>now, when connecting, gnutls-handshake return EAGAIN
<roptat>I don't know how to work around that, since the EAGAIN is documented in gnutls...
<roptat>ok, I did a loop over handshake, and it seems to work better, but now I get: Attempt to suspend fiber within continuation barrier