IRC channel logs


back to list of logs

<daviid>lloda: fwiw, i was browsing guix package page to check something, and see guix also has guile-cairo-1.10.0 still
<sneek>daviid, you have 2 messages!
<sneek>daviid, str1ngs says: can just check this snippet And make sure I'm getting the 'ok enum right for gtk-response-type. you can import it with (gi-import-by-name "Gtk" "ResponseType").
<sneek>daviid, str1ngs says: I can help think there is a better way to do this.
<daviid>str1ngs: will check asap
<wklew>Hi guile, does anyone know if spawn-fiber is a continuation barrier?
<wklew>i.e. whether I can abort to the context of the call to spawn-fiber from within it
<wklew>i guess thats a very easy thing to test now that i write it out
<daviid>str1ngs: you might wna use enum->value instead of assoc-ref ...
<daviid>str1ngs: is this code working? didn't test it ...
<daviid>str1ngs: in the doc, III. G-Golf Core Reference, Support, Enum
<str1ngs>daviid: this code works yes. but I'll will read about enum->value
<str1ngs>I guess I'm use to user enums in constructors which is simple. since you just use the symbol
<daviid>I meant to type enum->symbol
<str1ngs>okay will try that. thanks
<daviid>str1ngs: worth a quick lok to the enum/gi-enum doc
<daviid>*look :)
<str1ngs>will do, thanks for the clarification
<daviid>str1ngs: I am going to patch g-golf so that within the context of signals, you'll never have to call change-class again - working on it, will ping you ...
<daviid>str1ngs: pushed. you should now be able to remove the change-class calls, as in here -
***apteryx is now known as Guest8137
***apteryx_ is now known as apteryx
<str1ngs>daviid: great, will test it out first thing in the morning.
<daviid>sure, no hurry
<lloda>daviid: i saw your msgs about guile-cairo, but I don't know the processes those distros follow. They know where to find the newer version so I feel it's up to them...
<daviid>lloda: ok, i was just thinking to ping them maybe but i don't know either :)
<dsmith-work>Thursday Greetings, Guilers
<mwette>hi there
<kahiru>anyone doing anything cool?
<ecraven>getting disillusioned with ansible ;) I wish I could get people to use guix instead
<str1ngs>sneek later tell daviid: both <webkit-navigation-policy-decision> and <webkit-response-policy-decision> work now. without using change-class. I only test 'decide-policy signal since that's the only signal I know of right now that does this.
<kahiru>ecraven: I feel you
<ecraven>kahiru: it feels like they started a really nice project, and then stacked so many crates, that now everything is kind of brittle and almost ready to fall over
<ArneBab>ecraven: maybe you could write a tutorial "moving from ansible to Guix"
<ecraven>hehe, for that, I have to actually *move* to guix
<kahiru>to me it felt rather brittle since day 1
<ecraven>I always preferred ansible over puppet, but now, I dislike both :P
<ArneBab>I moved to Guix 18 months ago. It was a rough journey, since I had to get proprietary stuff working there.
<ecraven>should try chef, just to make it three I don't like :D
<ArneBab>(for work)
<kahiru>I was always more of a salt guy
<ecraven>never tried that
<kahiru>you haven't really missed anything
*kahiru ducks in case there are some salt people around
<str1ngs>I use salt. :)
<dsmith-work>I generally don't use much salt, except on eggs..
<ecraven>salt and butter on potatoes!
*str1ngs stomach growls
<dsmith-work>So, what is this "salt" thingy?
<topoi>What are the problems that made you desillusioned with ansible and puppet, ecraven?
<str1ngs>dsmith-work: it's for infrastructure automation like ansible
<ecraven>topoi: for ansible, it just seems like it has a nice core of features, and then they found things missing, and just piled them on willy-nilly
<str1ngs>dsmith-work: aka saltstack
<ecraven>for puppet, I like some of the things they did recently (types for parameters), but it just feels much "heavier" to use than ansible (and I much prefer a serverless solution, without a puppet master)
<topoi>ecraven: I already imagined the argument contra puppet. Regarding ansible: this phenomenon seems rather common. =)
<ecraven>I understand it, but it's not something I'd *want* in a tool such as this
<topoi>ecraven: Maybe there is some yet undiscovered rule of software bloat? =) But there must be _some_ userbase for those features?
<ecraven>it's not about the features, it's about *how* they are integrated
<topoi>In some inconsistend way?
<ecraven>to me, very much so ;)
<ArneBab>topoi: do you mean that whenever you don’t use emacs your tool grows until it has at least the features of Emacs and double the bloat? :-)
<topoi>=D ..that rule reminds me of Greenspun's tenth rule and seems surprisingly entangled.
<topoi>Citing the first sentence in the introduction of r6rs: "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear nec-essary."
<stis>hi guilers!
<dsmith-work>topoi: Yes indeed.