<ijp>add^_: actually I am using a fork, but the only difference is I fixed a logging bug (which is reportedin the tracker) <ijp>add^_: and it has dependencies on 'wak' <ijp>I pushed the naïve version of the queues module to pfds <nalaginrut>it's magic to use delimited-continuation, when I tried call k twice in shift, it run the same proc twice with each args I passed, just like 'fork' in userland ;-O <nalaginrut>wingo: if I try this (reset (display (shift k (k 1) (k 2))) (newline)), it'll print twice, 1 and 2. I want to know if the context will be copied twice, or just some GOTO magic? <dje42>If I have (define-class <foo> () value) in goops, how do I create an instance of <foo> ? <dje42>(make <foo> 42) gives me "Wrong type argument in position 2" <mark_weaver>dje42: you need to give the 'value' slot an #:init-keyword slot option, and then you need to pass that keyword before '42' in the call to 'make'. so e.g. (define-class <foo> () (value #:init-keyword #:value)) and then (make <foo> #:value 42) <mark_weaver>dje42: you might also want to add a #:getter option. <mark_weaver>or an #:accessor option if you want to be able to mutate the slot. <dje42>Yeah. I found Slot-Description-Example on the website *dje42 wonders if it's possible to make a smob look like a goops object <dje42>I was hoping I could just hook into the right place. Just have to find the place ... <mark_weaver>Though I don't know off hand of the easiest way to do it. I just know that in the worst case it can be done using the meta object protocol. <mark_weaver>wingo would know. guile-gnome, for example, makes gobject-based objects act like goops objects, and gobject classes as well. <dje42>thx, found the docs on the website. I'll dig deeper tomorrow. <add^_>ijp: which wak package is it dependent on? <add^_>uh, maybe you meant the spells package there. <add^_>Which actually, isn't there. <add^_>Ok, so I renamed the compat.guile.sls to compat.sls and whoop, works... <mark_weaver>ah, right. you could also use -x .guile.sls on the guile command line. <mark_weaver>though I should mention that using -x makes module lookups slower. <add^_>Isn't it the same as setting the %load-extentions <mark_weaver>the time spent looking for a module is N*M in the worst case, where N is the length of %load-path and M is the length of %load-extensions <mark_weaver>it does a system call (stat) for every combination of path-component and extension, looking for the file. <mark_weaver>that's the reason that .sls and .guile.sls are not in %load-extensions by default. <add^_>thanks for explaining that mark_weaver :-) <add^_>Doesn't seem to slow my system to a halt, which is good. Heh. ;-) <mark_weaver>np :) I'm toying with the idea of reimplementing module lookup, such that each directory in the path is read and scanned within libguile, to reduce the number of system calls and hopefully make it painless to add more extension types. ***cluck` is now known as cluck
<dje42>cool. smobs are already goops classes (IIUC) <dje42>goops didn't complain when I inherited from one at least :) <civodul>dje42: so gdb has an object system with inheritance & co? <dje42>I would phrase that as I'm providing a set of smobs, and I don't want to close doors on how the user may extend them. <dje42>Internally gdb is just C (maybe C++ some day). <dje42>So I'm looking into how one might extend my smobs (gdb values, types, architectures, pretty-printers, etc. etc) as goops objects. <dje42>Seems like this *could* be just a mechanical exercise once it's been done for one smob, and if it can be done presumably it's been done already (or so I hoped :)) <civodul>but you could just use plain SMOBs, and still users will be able to extend them (some some extent, as wingo notes) <civodul>you don't use the FFI at all, do you? <wingo>civodul: in guile-gnome, i don't use the ffi <dje42>Right, no FFI (at the moment anyway) <wingo>i use "native" slots in goops objects and instance finalizers <dje42>One thought I have is to provide the user two hooks: one for smobs coming out of gdb and one for smobs coming into gdb. <dje42>The smob->scheme hook could take the smob and return a subclass as the user chooses, and the scheme->smob hook could be called if gdb is given an object that is not a smob of the right type. <dje42>Then the rest is up to the user. <add^_>dsmith or dsmith-work (which ever you use right now): Where is the most "recent" code for SCWM? <wingo>if you want to allow goops inheritance, you should probably use goops to wrap your objects. <sneek>From what I understand, scwm is the Scheme Configurable Window Manger <add^_>I don't want to throw in an "is" there since it might bind something new to whatever.. <ijp>If any of you are want specific usage examples for pfds, now's a good time, since I'm in the mood for it :) <civodul>wingo: i was thinking that with the FFI you could use a define-wrapped-pointer kind of thing, and possibly have more flexibility <ijp>and I added a naïve variant for queues <wingo>civodul: i prefer that kind of api, yes <wingo>but it's possible to make something consistent in goops too <add^_>ijp: also, when your done with the pathfinder, link it to davexunit ;-) <add^_>dsmith & dsmith-work: Found it! *dje42 wants to not preclude using FFI now :) <dje42>All my smobs are just structs internally. <mark_weaver>dje42: have you considered using normal GOOPS objects, and calling into Scheme to create them and access them from C when needed? <dje42>OTOH, they're just wrappers of internal gdb structs that I don't want to expose. [all exposure is via functions that operate on the smobs] <dje42>mark_weaver: Yeah, haven't gotten to play with it yet. What I'd really like is to have something in place so that how they're extended is up to the user, and I just provide the means. <dje42>I can leave the decision until later, since there's a lot to do, and I'd like to experiment more, but not delay getting something upstream for *too* long. <mark_weaver>it might be worth reading the Dynamic FFI section the manual, and thinking about whether you could do more of this from Scheme. <dje42>One thought is that with the smob->scheme and scheme->smob hooks, the user can get goops objects out of gdb and pass them back into gdb. Plus, having read defined-wrapped-pointer-type (or rather skimmed ...) maybe these hooks would work there too. <dje42>Anyways, still lots more to read and play with. <dje42>thanks all. gotta head into my day job. <add^_>dsmith-work: yeah, also, I can't seem to get it to run, I guess I've forgotten what libs are needed (except the ones needed to compile) to run it :-/ <dsmith-work>add^_: Set the SCWM_LOAD_PATH (or was it the GUILE_LOAD_PATH?) <dsmith-work>You need an X server running. Xnest or Xepher will do nicely <add^_>Why do I need the SCWM_LOAD_PATH though? I thought that was setup when installed. <dsmith-work>Oh, I was talking about running it from the build dir <stis>yeah prompts in guile-log is finished, about 70 lines of scheme + 50 lines of C ***Guest2048 is now known as johnny__
***johnny__ is now known as j0hnny
***j0hnny is now known as johnny__
***ijp is now known as ijp|amused
***ijp|amused is now known as ijp|sorehead
***ijp|sorehead is now known as ijp
***Guest52082 is now known as johnny__