IRC channel logs

2019-12-30.log

back to list of logs

<mwette>janneke: lalr.scm does use syntax-case, which is critical to parsing the grammars: I use a fender to distinguish terminals from non-temrinals
<mwette>janneke: however, if you got cppmach to work that should not be the issue
<ng0>mwette: does tat mean janneke's variant of your(?) upstream is no longer necessary? (sorry if you are not the maintainer of the original one, sometimes it's good to not remember all the things I've looked at)
<mwette>ng0: janneke is working to that end; I think he is there or at least close
<ng0>ah, good :) I'd rather merge the one source than both of them as packages
<daviid>mwette: totally out of curiosity, why is the releae 1.00.1 and not 1.0.1?
<daviid>lispmacs: how simple is that gui you would like to have? just a few lables, a few buttons ... ? or is there other more complex widget involved?
<mwette>daviid: I like to keep two minor digits, makes it clearer when you get a list of all the releases (e.g., 1.10 is next to 1.09 and not next to 1.1)
<daviid>mwette: ok
<daviid>RhodiumToad: i never faced that frustration you are talking about, I've used and still usse guile-gnome for almost 2 decades now, and it is just next to perfect - i use glade 3.8.5 to design and maintai the interface, then load the xml file, use get widget to the widget instances 'in hand', add signals (callbacks) and that's it, real real piece of cake :)
<RhodiumToad>until it crashes :-)
<daviid>and that is the right path, imo, use glade, don't even think programming the iterface 'design', that is a nightmare, but using glade, get-widget and callback is so easy and so productive ...
<daviid>RhodiumToad: what crashes, i've had 3 pro apps, used in industry, never, ever had a crash
<RhodiumToad>once I started making significant use of idle and timeout handlers, it started crashing all over the place
<daviid>RhodiumToad: without using timeouts, but a normal app doesn't need that
<RhodiumToad>uh
<RhodiumToad>we may have different concepts of "normal"
<daviid>RhodiumToad: i'm talking about gimp, gnucash ... that sort of app, buttons, labels, ... but ok, granted timeout do not owrk in guile-gnome, they do perfectly work in g-golf though :)
<RhodiumToad>I don't think I'm actually using timeout handlers, only idle ones
<daviid>RhodiumToad: idles and timeouts are not working, in guile-gnome
<RhodiumToad>yes, that's what I discovered :-)
<daviid>RhodiumToad: what is the app you are working on?
<daviid>the knd of app
<RhodiumToad>as a learning exercise, I ported a little sudoku thing I wrote ages ago in tcl to it
<daviid>the only app that uses idle/timeout that i'm aware of is guile-async and guile-async2, and that is about coroutines, not gui - the author already has switched to use g-golf ...
<RhodiumToad>(I'm not working on any app in guile right at this moment)
<daviid>RhodiumToad: ok, for that i'd use clutter, which you can use right now with g-golf, if you are interested ...
<daviid>RhodiumToad: i'd use clutter, like in not gtk ...
<daviid>RhodiumToad: or guile-clutter, but unfortunately, no guixers ever made a guix package and guile-clutter is very difficult to install ...
<daviid>RhodiumToad: here are some examples using guile-clutter https://www.nongnu.org/grip/learn.html
<daviid>out of those, the only one that needs timeout is the clock - i bet it's possible to develop a sudoku game using gule-clutter without timeout
<RhodiumToad>the timeouts are to show steps in analysis
<daviid>ah ok
***catonano_ is now known as catonano
<RhodiumToad>as for the frustration with using things that aren't tk, that's at least partly the fact that I don't _want_ to use some UI designer, and in tk I have no need for one
<daviid>RhodiumToad: you can program directly in gtk/clutter, though i perso would never recommend this
<hugo>What makes the (system vm coverage) module work? I'm trying to run it along with sandboxed environments (inside or outside doesn't really matter). But I always get 0% coverage
<RhodiumToad>daviid: I know you can, I have done gtk ports of some of my old tcl apps in Lua (using a gobject-introspection binding lib for lua)
<daviid>RhodiumToad: ok, fwiw, even a tiny app, few labels few buttons, i'd use glade
<RhodiumToad>other examples of why tk is easier: it has a better model of event handling, since events are bound to tags, not to objects
<mwette>btw, I ran the nyacc ffi-helper on tk.h and it came up with a number of function typedefs that it could not handle; maybe to be fixed at some point but does not look promising now
<daviid>RhodiumToad: i guess this is all relative, because afaic, nothing is easier then glade, then get-widget and callbacks in scheme ...
<RhodiumToad>have you ever written anything in tcl+tk?
<daviid>RhodiumToad: a tiny attempt, a long long time ago, but i was terribly desapointed iirc
<daviid>anyway, let's hack, gui, design ... is like religion, not to talk about :)
<str1ngs>daviid: hello, I having working with g-golf and signal so far no blaring issues. great work. couple of notes seems class inheritance is looking quite nicely. ie (define-class <my-application> (<gtk-application>)) this pattern could avoid the need to ever register classes dynamically, nice work there. one small issue and I'm going to assume that this is due to signals being early days. the argument passed to the signal closures tend to
<str1ngs>be pointers. eg. (connect button 'clicked (lambda (x) (dmifi x))) . I hope it would be possible to have goop classes for those at one point?
<daviid>str1ngs: good point, let me fix this
<str1ngs>daviid: I hope this is not to much of a technical challenge. It's not a rush I have structured my code to work around it.
<daviid>str1ngs: but it's somehow a bug, have to fix it, thanks for the catch
<str1ngs>daviid a good to pass this on then. now I just need to fix my other guix related issue :)
<str1ngs>mean time I have fix or I can use debian
<str1ngs>daviid: I think g-golf will rival glade eventually
<str1ngs>maybe glade is faster for a quick prototype though
<daviid>str1ngs: there are two totally different things
<spk121>mwette: pity about tk. The only other C API GUI toolkit I know is IUP, but, I haven't used it lately.
<str1ngs>daviid: no complete different. defining classes in xml vs guile
<str1ngs>what about WX
<spk121>str1ngs: wx is C++
<str1ngs>oh and you still write win32 programs in C :P
<daviid>no one on earth wants to design the app by 'programming'm this is total heresy, imo
*RhodiumToad refutes that argument by existing as a counterexample
<str1ngs>maybe no good UX elements ever came from a programmer :) which might explain why we have glade, qml etc
<str1ngs>qml is quite nice though :)
<spk121>For money, I've done a fair bit of Qt C++, which is nice. Also C# UWP and C++ UWP which are acceptable. In free software, I've stuck with Gtk w/ various language bindings, but, Qt suits me better.
<str1ngs>hugo: one sec, I did some coverage on a project recently. let me re visit it
<RhodiumToad>what I _want_, ideally, is something that's easy to use in the same way that Tk is, but which doesn't require bringing in Tcl along with it
<str1ngs>hugo: http://paste.debian.net/1123116 maybe this will help
<str1ngs>hugo: the run code here denotes the code that should be covered
<str1ngs>hugo: I snarfed this from http://git.savannah.nongnu.org/cgit/gash.git/tree/tools/coverage.in . and adapted for guile-lib unit-tests
<daviid>str1ngs: i fixed that bug, please pull and try, tx for the catch
<str1ngs>sneek later tell daviid no problem. will test this out.
<sneek>Got it.
<lispmacs> /quit
***ng0_ is now known as ng0
***Server sets mode: +nt
***Server sets mode: +nt