***pc is now known as Guest73963
***catonano_ is now known as catonano
<ZombieChicken>so you're sure you have the dev headers installed and in the correct path? <anon987321>what i have noticed is that it tries to call stuff like it's in /usr/include/libguile.h and /usr/include/libguile/* <anon987321>i say /usr, but i'm using guix, so it's ~/.guix-profile/include <anon987321>...include/guile/2.2/libguile/__scm.h:54:10: fatal error: libguile/scmconfig.h: No such file or directory <ZombieChicken>Just asking the obvious question; you might try #guix and ask there as well <anon987321>don't think it's guix specific, as the /usr/include path for guile is the same <anon987321>so both guix and the ones from ubuntu follow */include/guile/2.2 <anon987321>while it seems like guile expects */include/libguile <anon987321>managed to get libguile working. found the pkg-config command required for it to work on the manual. kind of hard to find tho ***pc is now known as Guest42919
<RhodiumToad>(unless (let ((a (make-array #f 1))) (reset (array-index-map! a (lambda _ (suspendable-continuation? (default-prompt-tag))))) (array-ref a 0)) (display "I haz a sad\n")) <RhodiumToad>I know why, but has anyone thought about doing resumable C functions? <amz3>I find a way to workaround the slow query times in my search engine. <amz3>Actually, I did not a find a better way than using map-reduce kind of algorithm. <amz3>and a appropriate cachine of most common query results. <amz3>I will work on that this week-end, along updating wiredtiger bindings to SRFI-167 and SRFI-168 (that were finalized today) <sneek>Welcome back nly, you have 2 messages. <sneek>nly, str1ngs says: have you use secret sensitive system configuration? <sneek>nly, str1ngs says: I meant have you used secret for sensitive system configuration? <str1ngs>nly: ^ guix system configuration for context <nly>str1ngs, no i havent <nly>sounds cool, why did i not know of this *RhodiumToad discovers that guile-gnome somehow finds it impossible to destroy a gtk object which is not a widget <str1ngs>nly: it was a use case for secret that I thought of <str1ngs>nly: nice blog by the way. I like the nomad screen shot :) <nly>btw which branch should i be using? <str1ngs>I still think the stable release until g-golf branch is more stable <str1ngs>g-golf should be use able but it's going to be fundamentally different then the stable branch moving forward. <nly>str1ngs by secren do you mean shroud? <str1ngs>ahh sorry shroud, which uses secret correct? <nly>you can use it with an (use-modules (nomad shroud)) or just shroud in guix config <nly>shroud doesn't use any program by the name of secret, it uses gnupg <str1ngs>will try this out when I have time. btw maybe we can even better svg support down the road using cairo <nly>str1ngs that blog misses out on animations <str1ngs>by using a cairo bufffer, we could have better svg programmable support. <str1ngs>also a VTE buffer support for an embedded REPL <str1ngs>right now there is not much to do. there are some technical blockers that are almost done. once those are done. I'll be back working on nomad proper full time. <str1ngs>mean time I've been experimenting with qt support <str1ngs>nly: once I'm back working on nomad. I might need help with making the scheme code as generic as possible. my scheme fu is still pretty weak in that regrades. <nly>ok, i'll see what i can do tomorrow <nly>i recall that last time we were talking about documentation as well <str1ngs>yes, documentation is dependent on the generic API as well <str1ngs>nly: maybe it's as simple as having a <gtk-webview-buffer> and <qt-webview-buffer> that inherit <emacsy-buffer> <nly>str1ngs how would that work? <nly>you'll still need to (make <gtk-buffer>) or qt equiv <str1ngs>that's the trick part construction. but once we have the constructed type, the generic methods should just work. <str1ngs>something like (define-class (gtk-webview-buffer (<text-buffer> <gtk-web-view>)) (define-class (qt-webview-buffer (<text-buffer> <qt-web-view>)) <str1ngs>theoretically yes, it's what I'm using <webview-buffer> currently. but when adding more platforms it needs to be generic as possible. <str1ngs>I guess this could be a tested with dumby classes. I'll think more on it <str1ngs>nly: either way it's much better then the two code bases I originally had. so this has come a long way. there is light at the end of the tunnel now. <str1ngs>nly: not only that but it's runtime capable and eventually requires no C <spk121>str1ngs: I do have a vte repl running <str1ngs>spk121: I too had one with nomad, but due to factoring I removed it. <spk121>cool. If you do end up trying to use ncurses for something, feel free to reach out. I'm the maintainer of one of the ncurses bindings <str1ngs>in terms of ncurses I do plan to support that at one point. the tricky part is making the UI code generic enough to support ncurses as well. as you can see with QT I use GI for that. but for ncurses that might not make sense. <str1ngs>any input on that would be great. my scheme skills are not that great yet <spk121>ncurses is difficult to abstract in a way that is similar to Qt or Gtk. It is an ancient API <str1ngs>that was my thinking as well. I did a quick overview of it, more in the context of console html libraries though. <rlb>When a thread inherits a fluid from a parent, are they then referring directly to the same fluid, so that changes on either side directly affect the other? <rlb>(Wondering about what the promised semantics are.) <spk121>rlb: fairly sure that if a thread inherits a fluid, any modification to the fluid in that thread are specific to that thread, but, that thread does inherit the initial value of the fluid from the parent <rlb>Hmm, so maybe one way to think of it is that given a globally defined fluid x, any given thread makes a copy of the fluid when appropriate (say the first time the thread attempts to change it), and then relies on that copy -- and a child thread receives copies of its parent's "active" fluids (ones the parent has actually changed), when created? <rlb>I suppose that would mean that a global fluid would never itself change values (which is a perfectly good model). <spk121>rlb: I don't know about the "truth" but that's how think of it. <amz3>I was going to say, "read the code" but seems like it fluids are defined in the compiler /cps/ language. <rlb>OK, thanks -- I haven't yet worked with fluids in depth, but I've come to a point where I need to understand them in detail. <rlb>amz3: yeah, that and/or experimentation was an obvious next stop, but figured I'd check to see if the precise semantics were already well defined/known somewhere. <amz3>I used to work with fluids, but at the end of the day a fluid is a global and it was messing with the rest of my code. <amz3>Now I prefer to pass arguments :) <amz3>like the database connection was a fluid, but then it would make working with multiple database impossible. <amz3>there is surely cases where it is useful. It has added to Python under the name 'contextvars' for use with the asynchronous framework (similar to guile-fibers) where you need to configure e.g. decimal precision. <amz3>configure decimal precision per fiber. <amz3>decimal precision used to be global to the processus. <rlb>(FWIW, In this case, I'm trying to figure out how clojure's dynamic variables (and binding) might best map to Guile's facilities -- there bindings are not inherited by sub-threads, but can be "conveyed" to annother thread when it has been asked to take an action indirectly on behalf of the original thread via various forms (relating to agents, futures, etc.).) <civodul>i'm sure a Guile REPL could put it to good use! <civodul>like you click on an object to inspect it, things like that <civodul>(so the REPL would typically need to run an HTTP server to receive "clicks") <spk121>civodul: you kids and your hyperlinks. Back in my day, we had ECMA-48 escape codes and we were happy. ;-) <amz3>manumanumanu: btw are you aware that hg will be gone from bitbucket in a few months (hint: https://hg.sr.ht/) <civodul>i found it so revolutionary that i used them for "guix search" & co. :-) <civodul>what's ironic is that i use M-x shell and sometimes xterm, none of which supports these escape sequences (yet) <civodul>but i tried in those newfangled terminals and it's just wonderful ;-) <rlb>...interesting -- sounds like tmux might eventually support it. I've recently been trying out using tmux everywhere, i.e. locally it just runs a new-session in each stterm . Though not quite sure what I think about that arrangement yet (first time I've used tmux much either). <rlb>(and perhaps an odd way to use tmux, but stterm needed something to handle history, etc...) <rlb>I was trying to create a custom repl the other day, and unless I missed it, it looked like the current functions don't directly support providing a custom printer. For now I just adapted the existing code, but I'll try to propose a patch to allow that when I get some time. <rlb>i.e. if you want to use the current repl infrastructure, but for a language that has a different printed output. <amz3>the thing with custom printers, usually, REPL output can be read using `read` procedure. So you would have to also customize the reader. <amz3>or forget about what i said :) <rlb>Yeah, had to have that too, but there was a mechanism for that iirc. <rlb>Another thing that I think I might want, though I'm not sure would/wouldn't be appropriate is the ability to specify a module that ",language" should switch to for a given language. i.e. one that has the right environment for the language, say foo-user as compared to guile-user. <rlb>Right now you just have to ,module alongside ,language. <rlb>Doesn't matter I think for languages like elisp that (I think) just compile all top-level references to a specific global namespace module, but may apply for languages that have separate namespaces like guile and want to use guile modules to provide the encapsulation. <rlb>Anyway, assuming I don't think of something else, I'll probably bring it up on guile-devel at some point. <daviid>spk121: hello! does guile-gi has glib main-loop idle/timeout functions? <daviid>spk121: asking because g-golf has those, and they work fine, by that i mean they do not crash/segfault (guile-gnome had that problem ...) even if you let those run indefinitely, so that is very good news <spk121>daviid: when GLib is loaded, the C function g_idle_add_full gets bound in Guile as idle-add. Similarly for timeout_add <daviid>however, they leak, a tiny bit of mem, but steadily, and if you have those as well, maybe you could help me to see what's wrong i my implementation <daviid>spk121: g-golf, like guile-gnome, implement those 'manually', following the steps as described in the glib manual, but i don't see how both gclosure and source are freed, and suspect that that is the cause of the leak ... <spk121>daviid: ok. are you using the (GDestroyNotify) notify function of g_idle_add_full to call a free function? <daviid>spk121: if you have a bit of free time, i could point you to where the code is (very short, reading is a matter of minutes ...), maybe you could spot the problem .. <daviid>spk121: no, just the invalidade function <daviid>let me tell you where the ocde is <daviid>spk121: actually wrt closures, one more thing: the line 91, you see i add invalidate-notifier that is %g-closure-free, defined further below (the % is a convention(for me), it is a pointer to a scheme function, which will 'just' remove the <closure> instance from the g-golf cache (which is needed so the marshaller can find the function when given a gclosure ...) <daviid>now, if you could pull and build g-golf (i thik you already have it so it should be easy and fast), then here is an example that shows the leak, i'll paste in a sec ... <daviid>now, what i thought was that since the idle is not kept (in that example), glib would call the invaldate-notifier and run my %g-closure-free, but that does nover happen <daviid>also, %g-closure-free uncache the closure instance, but i don't call g-closure-unref (because i thought this would be done by glib when/if it was calling the invalidate-notifier ... <daviid>%g-closure-free is a pointer to a proc define line 247 - 248 <daviid>i did read about GDestroyNotify, but didn't implement it (yet): guile-gnome doesn't have one either, nor cl-gobject-bindings, nor sbank, afaaaict at least ... which doesn't mean i shouldn't of course, and surely something is missing in g-golf to free gclosures and sources ... <spk121>daviid: valgrind suggests that the output of g_idle_source_new is not being freed <daviid>spk121: i read in the glib manual, Memory management of sources, in the main-loop section, but i still do not understand fully, nor do i know which solution would be best ... <daviid>spk121: that's what i thought, and i also think the <closure> instance is never relese either, but let's focus on the surce first <spk121>so, you need to hook a call to g_source_free someplace <daviid>how should i be notified and how (where in the code i mean), to free it? <daviid>ok, but when, where, do you happen to knw? <daviid>you don't seem to call it in guile-gi? <daviid>i can't find any such call in guile-gnome either ***jao is now known as Guest56162
<spk121>True. guile-gi probably leaks that, too. Pragmatically, I'm unconcerend because g_idle_add_full it called at the beginning of programs and never freed. But. In C, the way you'd free that is to probably pass a UUID-like number to the paramater of g_idle_add_full(), add a callback procedure as the NOTIFY parameter of g_idle_add_full, and in that call back procedure call g_idle_remove_by_data on the UUID-like number you passed <daviid>spk121: so far i did implement g_idle_add, g_timeout_add and g_timeout_add_seconds 'manually', and i fail to understand how i can pass/attach a but even vand not the *-full GDestroyNotify <daviid> spk121: so far i did implement g_idle_add, g_timeout_add and g_timeout_add_seconds 'manually', and i fail to understand how i can pass/attach a GDestroyNotify proc <daviid>even for the *-full version of those, the glib manual says: "This internally creates a main loop source using g_timeout_source_new() and attaches it to the global GMainContext using g_source_attach(), so the callback will be invoked in whichever thread is running that main context. You can do these steps manually if you need greater control or to use a custom main context." <daviid>that sentence does not ell me how to pass/attach a GDestroyNotify in the 'steps manually' <spk121>OK. I see. It is a pretty different approach them, so I probably can't be of much use. But, lemme teach you how do to valgrind, if you don't know that already <daviid>spk121: yes, it is a diff approach and tx, i don't kow how to valgrind <daviid>spk121: tx, i'll kep that - i managed to loose the tips you gave me a while ago on how to gdb ... <spk121>that makes a vgrind.out file, and the stuff in that file is ordered from least important to most important. So the end of the file is the most important <daviid>spk121: ok, but i hope i can call for help :):), and right now, i'll keep a copy, but i 'm more concern on how to solve the problem ... if you come to have an idea, please ping me <daviid>spk121: tx for your help so far by the way ... very nice of you ... <spk121>daviid: well, in your g-idle-add, you've used GOOPS make to make a <closure>, and either you are holding a ref to that <closure> so it doesn't GC, or you need to add a destructor to your <closure> class that calls the C g_source_unref. <daviid>spk121: ok, let me explain a bit more about this: yes i do hold a ref to <closure> instances, i need to so the marshaller can find the scheme proc when it's called, that ref is being hold in a cache, see line 87 of the closure.scm code <daviid>spk121: then, i thought when a diel/timeout is _not_ kept in the main loop context, that the invalidate-notifier wold be called, and that is where i remove the <closure> instance from the cache, but I can trck that my invalidate-notifier proc is never called <daviid>unless i miss underatood, but added loclly, a peek to see if it was called, and it's never called, i wonder why actually, something i missunderstood i guess <daviid>spk121: i jus asked the exact same quiz on #introspection, but they did not aswer (yet, they are very nice and helpfull, but soetimes it takes time so someone answers) <daviid>spk121: maybe i shoud hold the source ID in the <cloure> instnce as well, then add an unref/free in my %g-closure-free procedure, though tilli find the answer to the previus question, i don't know how to make itso that it is called .. <spk121>daviid: yeah. Well I'm giving up for today. Good luck.