***scs is now known as Guest20797
<gabbiel>should I install guile 2.2.6 or guile 2.9 ? <lispmacs>Hi, I'm using Guile on a Debian 9 system. What procedures are of interest if you want to make something happen at a certain time of day? <schaeffer>it looks like i'm getting the same error as described in the bug report when using the #:class allocator, but for #:each-subclass as well ***scs is now known as Guest26796
<lispmacs>does Guile has something like Racket's void? <lispmacs>i.e., void data type, or a nil or something <str1ngs>lispmacs: (null? '()) evaluates to #t so sound right ***scs is now known as Guest84414
<str1ngs>daviid: maybe stepping away from the proxy settings for now. is that functions like this don't work. (unspecified? (gtk-window-new 'toplevel)) $1=#t <daviid>str1ngs: wrt proxy settings, i god an answer on #introspection, these boxed type are opaque, which i (naively) thought didn't 'exist' when dealing with GI <str1ngs>daviid: oh that's good news. so there is still potential then? <daviid>i thought if it existed, i would receive the info is-opaque from either the callable info, ot ars, but what happens is when a boxed type returns its size as 0 (zero), thn it is opaque <str1ngs>okay that might explain the size-of error then <daviid>now i know what to 'look for', give me some time to solve this problem <str1ngs>no rush, the unspecified return values are probably a bigger issue <daviid>remeber me this (gtk-window-new 'toplevel)) later ok? one thing at a time ... :) <daviid>yes there is hope, I will fix this asap and will let you know <str1ngs>okay sounds good, (webkit-web-context-get-default) might be a better candidate since it ties in with the proxy settings <daviid>that is another problem, because webkit-web-context-get-default returns a GObject ubclass instance, not a C struct pointer ... will solve this to <daviid>I'll work on opaque boxed type first <daviid>I should have known that, I'm sorry I didn't <str1ngs>you know just when I think I understand GObject classes. I realize I don't lol. I'm guessing you are farther down the rabbit hole then me in that regards. <daviid>for a scheme user, everything should just work <daviid>I thk you again to point me to these corner cases and for your patience <str1ngs>no worries, I'm just glad to have found the issue. <str1ngs>I guess for me I now how it translates or works on the C side. so it's easy for me to guess how it should probably look in scheme. <daviid>i'll work on it and get back asap <str1ngs>btw gtk-window-new cane be worked around with (make <gtk-window>) so that is not as pressing <str1ngs>thanks for getting back to me on that. and no rush <daviid>it is of a tremendous help that you are using g-golf while it is still in development <str1ngs>I'm hoping it will be a good candidate for nomad. so far it's been very useful particularly the webkit classes ***scs is now known as Guest97805
***scs is now known as Guest30145
***scs is now known as Guest87698
***scs is now known as Guest18605
<str1ngs>nly: can you test with version 0.3. I'm wondering if this is related to the scratch gaurd <nly>do you want me to checkout specific commit? <str1ngs>if you check version-0.3 should put you on that version <str1ngs>okay so this has not been introduced. seems to be an issue with mru? <nly>note: since next-buffer is interactive i had to use mru-next copied from next-buffer <str1ngs>trying to think if that would have an impact <str1ngs>I mean you can maybe write this test interactively with hooks and high level functions. though I suspect the result would be the same. <str1ngs>I think kill-buffer will call remove-buffer! eventually. and that looks like the issue here <str1ngs>nly: maybe a good start is to write a proper test that catch's this error <nly>that link's now offline, sorry <nly>surprisingly calling buffer-previous and then remove-buffer works <str1ngs>yes, it's definitely order dependent which is not surprising due to mru <nly>i have a half assed immutable queues module for guile, srfi-124 and 131 <nly>maybe use that instead of qs? <str1ngs>but that something for janneke decide on. first we should address what's causing this bug. <str1ngs>I think a test to replicate it is a good start. then we can go from there <manumanumanu>wingo: great! I am trying to understand _when_ define becomes letrec and when it becomes as fast as let*, but sometimes getting a feeling for when optimizations get done is harder than I'd like to admit. With macros I can at least do ,opt :D <manumanumanu>wingo: just read the commit message. I didn't realise it got _that_ good. Fantastic <manumanumanu>wingo: btw, allowing defines in arbitrary places is harder than I thought. It can't only be done on a syntax level, since that will make (if something #f (define b "hej") (display "what the fudge")) valid. My usual macro approach is useless :D <jcowan>manumanumanu: If you really want that, use a (let () ...) wrapper. <manumanumanu>jcowan: I don't really want that, that's the thing :D I just wrote a macro that allowed for defines in expression context by wrapping every subsequent expression in either letrec, let or let*, but it has the shitty side-effect in the example <manumanumanu>Which means a syntax->syntax transformation isn't good enough without hard-coding all the exceptions. <manumanumanu>I don't know how the schemes that allow arbitrary placement of define do it, but I suspect that's not the way :D <jcowan>I don't know of any that allow truly arbitrary placement. <jcowan>Some allow expressions and definitions to be intermingled with in lambda or let blocks, but that's not *arbitrary* <jcowan>(+ 2 (define x 3) x), I don't think that works anywhere. <manumanumanu>jcowan: Thanks. I didn't think about doing it that way. That is of course the simple solution! I could just re-bind begin,let,let*,letrec,letrec* and lambda to use my own syntax-rewriting macros. <manumanumanu>Whether it is a good idea, that doesn't matter to me. It is just fun to do :D <manumanumanu>It is a much better idea than what I am currently doing :D ***jao is now known as Guest13728