<zacts>will you provide a systemd compat layer? <zacts>I know OpenBSD has plans to do this, so that programs that rely on the systemd API will still run on it. I was just curious about dmd + guix. <mark_weaver>we've vaguely talked about various options from compatibility layers to patching software the depends on systemd features, but no one has looked closely enough at the details to know which approach makes the most sense. <dsmith-work>I haven't looked into close enough yet, but systemd sounds like it's complex and heavy. <dsmith-work>Had an issue with the 32bit laptop. Probably need to clean first though. <linas>it simply sets a symbol-value in the current environment. <linas>I'm pretty sure its almost surely not thread-safe, and will race <linas>by contrast, (use-modules (ice-9 local-eval)) seems to actually capture the environment, which means its thread-safe <linas>thought stis and davexunit would be curious to see above <linas>ah never mind .. maybe I need to study fluids more carefully. Sorry for the noise ***fangism1 is now known as fangism-ctrl-Z
<zacts>I just finished my first reading of the Little Schemer. Although, I'm going to re-read ch's 8 - 10. It's a nice book. <zacts>I need to train my mind to become a pretzel <lamefun>why are standard libraries so badly named? <ijp>there are various srfis that cover the same functionality, so the number is the only unique identifier <ijp>28 and 48 cover format strings (and 54 is another formatting srfi), 18 and 21 cover threading, 4 43 and 66 cover various sorts of records... <lamefun>why aren't they named threading-1, threading-2, etc? <ijp>9 57 76 and 99 cover records <ijp>lamefun: they don't necessarily build on one another <ijp>take records: 99 builds on 9, but 76 does not <ijp>then someone would come here and instead ask if they should be using threads-2 rather than threads-1, and why are the two incompatible <ijp>besides, srfis are not really standard libraries <ijp>some arguably are, most aren't <lamefun>C++ Boost has boost::signals and boost::signals2 which are incompatible. <ijp>srfi 97, which most r6rs implemenations follow, allows for an additional topic specifier <ijp>like (srfi :1 lists) , (srfi :43 vectors) , etc. <ijp>guile follows that in the r6rs import form, but not in use-modules, for historical reasons <lamefun>"why are the two incompatible" - major versions are exactly for breaking compatibility <ijp>and a new srfi does not in anyway correspond to a major version release <ijp>many of them are not even libraries <ijp>srfi 30 is multi-line comments <ijp>srfi 61 generalised cond <lamefun>how does that prevent them from using a sane naming convention? <ijp>guile's library names are historic and are not liable to change, and srfi 97, should you want it is supported in the r6rs IMPORT form <wingo>so if i were to make some facility to replace smobs, what should it be called? <ft>hum... why would (add-to-load-path "foo") add "foo" *twice* to %load-path? <ft>(GNU Guile 2.0.11.1-8d124 if it matters) <wingo>ft: perhaps once at expansion time and once at compile-time? <ft>Yeah, I'm trying it at the REPL. That doesn't seem intended. :) <ft>The macro has an "(eval-when (expand load eval) ...)" expression. Maybe expand and eval phases? <ijp>you could fix it to check for the value on load path, but as wingo says, pretty harmless <ft>Yeah, I just thought I'd mention it. :) <wingo>anyway it certainly shouldn't add it if it is already first in the list -- though probably it still needs to add twice or at least shuffle to make sure the path is in front <wingo>civodul: that's a very confusing overloaded word, no? <civodul>there's no need for anything more, IMO <wingo>smobs are not nice to deal with from scheme, and are limited in number <wingo>i was going to implement a replacement that can integrate with goops <wingo>but that's not goopsy in flavor <civodul>the limitation in the number of smobs is a problem, but that's orthogonal <wingo>and that you can use from scheme <civodul>code that uses the FFI can obviously make things more GOOPSy <wingo>it would be nice to be able to create a wrapped foreign type in scheme and have it be approximately equivalent to smobs <wingo>not sure whether to involve the ffi or not <wingo>right, i was going to use structs and that stuff, as gobject does <wingo>instance finalizers and all... <civodul>but was there any limitation with that approach? <wingo>but mark functions are terrrrrrible <wingo>and anyway we won't be able to remove smobs any time soon :/ <civodul>i think we have a wealth of somewhat overlapping mechanisms when it comes to creating dijoint types and to interfacing with C <civodul>so my first reaction is to not add another one <wingo>but it would be nice if we had something that was both nice from a c api perspective and nice from the scheme perspective <wingo>and, it would be nice to fix the manual so it's not talking about smobs all the time <civodul>i think 'o' struct fields were in that spirit, but it's never been used AFAIK <wingo>i've used 'o' struct fields before <wingo>they aren't as useful as 'r' fields <wingo>goops actually does this really well <wingo>(define-class-with-docs <gtype-instance> () <wingo> "The root class of all instantiatable GType classes. Adds a slot, <wingo>@code{gtype-instance}, to instances, which holds a pointer to the C <wingo> (gtype-instance #:class <read-only-slot>) <wingo>the #:class <read-only-slot> makes the slot have 'ur' protection <civodul>SMOBs could probablly be rebased on top of structs <wingo>right, except for mark functions <civodul>they could be structs with a couple of 'o' fields <wingo>but that's not a fundamental limitation i guess <wingo>we could add the ability for structs to have mark functions... you'd just store the mark function in the struct vtable like the instance finalizers already are <wingo>that's another motivation for doing this work -- almost nobody knows how instance finalizers work <civodul>i haven't found any use case where mark functions are needed since we use libgc <wingo>civodul: humm, good point... <wingo>indeed of all my c code on my hd there are only a couple mark functions, and they are bogus <wingo>one problem with any attempt to migrate smobs is legacy code that uses SCM_CDR and such to access word 0 of the smob <wingo>some of that might be SCM code though <wingo>we could probably find that code by deprecating SCM_CDR and such, recommending to replace with the inline functions scm_cdr, ... <civodul>(it's also crazy that we can expect that "everything" is available on GitHub nowadays...) <wingo>that's about the only use i have for github :P <wingo>searching to see the crazy things people do <taylanub>linas: I think my `interaction-environment' advice was bad indeed, I thought it returns a fresh environment every time but it doesn't seem to. <ijp>get yer fresh environments! lovely fresh environments! caught them myself this morning! <civodul>wingo: i'm not sure i see what you'd need to be ashamed of here :-) <wingo>dunno -- maybe it was the right thing then but it's disgusting to need a version of gc-protect-object that works during the sweep phase :/ <wingo>three cheers for no more sweep phase :P ***Shozan is now known as SHODAN
<mark_weaver>unknown_lamer: do you have time to answer a GOOPS question? <mark_weaver>he seems to want to override the initial value of the 'a' slot in the <bar> subclass, but I think he's not doing it correctly. <mark_weaver>GOOPS is definitely not handling it gracefully though. <mark_weaver>should GOOPS be doing what he expects, or should it be reporting some kind of error, or what? <unknown_lamer>goops should certainly not be returning a value from a different slot <mark_weaver>what is supposed to happen when a subclass includes a slot definition with a slot name that matches a slot from a superclass? <mark_weaver>is that a proper way to override some attributes of the slot? <unknown_lamer>CL-USER> (values (foo-a (make-instance 'foo)) (foo-a (make-instance 'bar))) <unknown_lamer>mark_weaver: the child overrides the parent, unless your metaclass says otherwise <mark_weaver>okay, so his code looks correct to you, and his expectation is valid? (I guess so) <unknown_lamer>identical clos code works, and the getter returning the value of a wholly different slot is ... not right <unknown_lamer>at least in this area, goops should match clos behavior exactly <mark_weaver>yes, it was obviously a bug, I just wasn't sure how it _should_ behave, but now I do. <mark_weaver>I guess maybe GOOPS never implemented this behavior there a subclass can include a duplicate slot name. <wingo>i thought goops carped if slot names were not unique *daviid wonder how harlequin got the copyright and all rights reserved over the CL hyperpsec <daviid>wingo: do you think you can remember why you added clutter_image_set_data to the overrides/clutter.defs ignore-glob list? <daviid>ok: since clutter-texture-new-from-file has been deprecated, the only way to 'play' with images is to gdk_pixbuf_new_from_file, clutter_image_new and clutter_image_set_data <daviid>by the way I removed "clutter_image_get_data" from that list [which does not exists] <daviid>given the set-data 'default' wrapper (in clutter.defs (line 4314)) and commenting the ignore-glob entry, the only complain I get is WARNING (opaque type for proc clutter-image-set-data guint8*). Resolving that type would not be sufficient? if not could you point me to a similar special wrapper that I could learn from? <daviid>in this particular case, maybe a better solution would be to define a set-from-pixbuf in C and wrap it, wdyt? <daviid>mark_weaver: in the user's goops example you were taking about, note that in <bar> he does _not_ define a getter, so I believe the result is correct given his code <daviid>if you define <bar> like this: (define-class <bar> (<foo>) (a #:init-value 'bar #:getter foo-a)), goops gives the proper [and expected] result