<sneek>Welcome back nalaginrut, you have 1 message. <sneek>nalaginrut, amz3 says: you need document all the things all the time nalaginrut ;) <nalaginrut>amz3: yes, I'll document them when all design become stable <davexunit>ACTION implemented auto-reload feature for 'haunt serve' <davexunit>make distcheck completed successfully. weeee. <davexunit>now, if I can make a home page for haunt using haunt, I will release 0.1 <rlb>So can goops instances be immutable? <rlb>Seems like you can always slot-set! <rlb>I'm wondering if I might need to use records (guile or rnrs) as the underlying type instead. <nalaginrut>IIRC, records is based on vtable, and the slot could be promised to be protected in low-level <rlb>Both types of records appear to offer immutability from a quick glance, so perhaps I'll use that, assuming I can still define-method(s) for them. <rlb>Might be an interesting addition to goops, if it's feasible... <nalaginrut>hmm...but if you use records, define-method failed to check the types for you <rlb>I'm not sure - I think there may be a way to specialize methods on records - I'll let you know shortly. <rlb>(think mark_weaver may have told me as much) <nalaginrut>rlb: please tell me if you succeed, then we may try a newer OO system <rlb>Will do - learning r6rs records now... <mark_weaver>rlb: it's pretty gross, but you can do something like (define <foo-class> (class-of <instance-of-foo>)) and that will create a class for a record type. <mark_weaver>and then you can use <foo-class> to define methods on that record type <mark_weaver>I've never done much with GOOPS and am only superficially familiar with that code. wingo is the one to ask, but I think he's been mostly incommunicado lately. <rlb>OK, thanks - that's not intolerable, though better goops integration might eventually be nice. <rlb>And I'd easily put up with that level of hassle in exchange for immutability in this case. <mark_weaver>rlb: we support immutable records in (srfi srfi-9 gnu) as well <rlb>mark_weaver: though if I lose inheritance, that's going to mean some non-trivial copy-pasting, or macrology. <mark_weaver>see 'define-immutable-record-type' and the nice "Functional setters" that we implemented fairly recently. <rlb>mark_weaver: right - any recommendations wrt choosing one or the other? <mark_weaver>the functional setters generate fairly optimal code also. <rlb>so perf-wise, might I be better off with srfi-9? <mark_weaver>I don't know for sure, but quite possibly the SRFI-9 stuff is faster. <mark_weaver>it should be noted, however, that the SRFI-9 immutable records are a guile extension, whereas R6RS records are somewhat more portable. <rlb>For now, the work is already fairly guile-specific since it requires goops to avoid giant switch statements. <rlb>(i.e. the seq protocol) <mark_weaver>I haven't looked at our implementation of R6RS records in particular, but in general when looking at our R6RS code I've found that it was not written with performance in mind, whereas I definitely paid attention to performance when I implemented the SRFI-9 immutable records. <mark_weaver>okay, I guess I would recommend using SRFI-9 immutable records then. <rlb>I didn't realize the guile's future/touch already used a thread pool. That was a nice surprise. <rlb>Next I'll need a more general thread pool (or pools), and maybe a solid parallel deque (i.e. producer/consumer)? Not sure yet. <rlb>...musing about java.util.concurrent Executors. <rlb>I'll need some bits to support agents. <rlb>But for now, seqs... <mark_weaver>rlb: btw, since you need inheritance, I guess you'd better use R6RS records after all. <mark_weaver>(there's no inherent reason why R6RS can't be as fast as anything else) <rlb>Well, I don't *have* to have it, but with goops, I'd defined a bunch of default seq methods (well, collection actually), that I guess I'd have to explicitly define per-type with srfi-9. <rlb>(define-method (associative? x) #f) <rlb>(define-method (coll? x) #f) <rlb>(define-method (counted? x) #f) <rlb>(define-method (reversible? x) #f) <rlb>(define-method (sequential? x) #f) <rlb>(define-method (sorted? x) #f) <rlb>Hmm, though those are fine, I suppose, since they're global defaults. <mark_weaver>rlb: actually, I have no idea how R6RS inheritance would interact with GOOPS inheritance. <rlb>It's the <seq> specific defaults that are an issue. <rlb>Yeah, I'm currently leaning toward srfi-9, and explicit definitions per-type. <rlb>(with macro or other help if that makes it less chatty) <mark_weaver>honestly, you might be better off using plain GOOPS classes, and relying (for now) on the user not using 'slot-set!'. <rlb>I'll play around - definitely prefer that the immutable types be immutable if possible. <mark_weaver>well, I'm not sure off-hand how hard it is to get around the so-called "immutable" record types either. <mark_weaver>and I don't know how seamless the SRFI-9-records-as-GOOPS-classes emulation is. <mark_weaver>you really need to talk to wingo about this stuff. civodul and I don't have much interest in GOOPS, whereas wingo has done quite a bit of work on GOOPS. <mark_weaver>I should also mention that GOOPS introduces quite a bit of mutability in the fundamentals of any system, because the method tables are mutable. <rlb>The main thing I need for this is just some way to have a (count x) for example that will work on N types (including ones added later) efficiently. <rlb>...and at the core for seqs: first/seq/next <rlb>(though there are plenty of others) <mark_weaver>well, first of all, it seems that you have chosen names that conflict with names from SRFI-1, which is probably the most widely used SRFI. <mark_weaver>well, clojure is its own language, but you are now bringing those names into the scheme world. <mark_weaver>I'm in favor of bringing some of the data structures, concurrency primitives, and related concepts from clojure into guile <rlb>all stuff I plan to ask about - for now I'm mostly just matching clojure, and keeping everything in separate modules, though I've expected that I'll have to change things. <mark_weaver>but, fwiw, I'm not in favor of bringing in all of the precise names and idioms from clojure into scheme, especially where they conflict with very widely used bindings in the scheme world. <rlb>Worst case, you could just rename everything clj- I suppose. <rlb>Right now I'm just trying to get things working at all. <rlb>Though I did rename clj cons to scons. <mark_weaver>heh, that was one name conflict you couldn't easily ignore :) <rlb>I haven't really thought much about any of the guile-side naming issues yet, i.e. what *has* to change, what probably should change, and what can be left alone. The implications, etc. <mark_weaver>well, anyway, I have to sleep soon. don't worry too much about my objections to the names; those could be changed later if desired, and I'm never shy about bluntly stating my opinions :) <rlb>I suppose with generics, any names that you might want to apply to existing guile types (and that conflict with existing functions) might have to be changed. <rlb>i.e. if clj's rest/next only applies to new types, it might not be a system-breaking problem. <rlb>Hmm, I'll need to become more familiar with goops's scoping too... <rlb>mark_weaver: no worries - I appreciate the candor. <mark_weaver>when you expressed an interest in implementing a clojure front-end for guile, I suggested that you first implement the data structure and concurrency primitives such that they can be used conveniently from scheme code. <mark_weaver>you have taken it much further and seem to be trying to copy all the names and little functions so that you can write code in scheme that is as close as practical to clojure's style and idioms. <mark_weaver>and there are issues with GOOPS. the mutability deep in the system has implications <rlb>No, I'm just currently doing N things at once, and I still can't promise it'll work out. i.e. I'm creating the data structures, and I'm writing the functions that I have to have to support the dialect, and then I'm pondering how some or all of those might be introduced to guile itself. <rlb>i.e. I'm writing "all those little functions" because they're going to be called from the dialect at least. <mark_weaver>also, there will always be a substantial performance penalty to using generics, although we can certainly make them a lot faster than they are today. <rlb>Well, I don't see any way around generics for clojure - it requires both faster (single-dispatch) protocols, and full multimethods. And the sequence abstraction requires that a whole set of functions all work on anything that's a "sequence". <rlb>"(slower) full multimethods" <mark_weaver>from my perspective, I would prefer to have implementations of the interesting data structure and concurrency primitives from clojure that don't use GOOPS internally. I would prefer for any GOOPS layer to be optional, and layered on top. <rlb>OK, so you don't want the seqence protocol? I definitely do. <mark_weaver>yes, you will need generics to implement clojure, that's true. <rlb>It's one of the bigger strengths, IMO. <mark_weaver>I would like the sequence protocol, yes, but I don't want to pay for it unless I use it. <mark_weaver>I want to be able to write non-generic code that uses the clojure data structures of interest, without paying the price of generic dispatch if I don't need/want it for a particular program. <rlb>Sure, and as I have it now (though it might not be sufficient for you), none of the functions become generic until/unless you (use-modules (... seq)). And sure, I imagine it's possible that we'll need to have seq-* for all the seq functions <rlb>Now I'm wondering at what point goops merges methods - is that a global namespace, or does it do it within your module, or...? <rlb>i.e. if you say (use-modules ((... seq) #:prefix seq-) will it avoid clobbering cons/first/rest etc? <mark_weaver>heh, this is a topic I've debated with daviid many times, and we've never reached agreement. <rlb>If the latter, then maybe everyone wins? <mark_weaver>generics are not a global namespace, they are just normal procedures, subject to the module system. <mark_weaver>they are procedures that have an associated method table, so calling the procedure has the effect of looking at the arguments and choosing the applicable method from the table. <mark_weaver>and they are effectively mutated when you add methods to them. <rlb>So if the seq module does a (define-generic (first ...)) and you use it with a prefix of seq-, does it leave your first alone? <mark_weaver>personally, I am strongly in favor of explicitly defining generics in a specific module, and then importing that module before adding methods to that generic. <rlb>I suppose I could try it and see ;> <mark_weaver>however, daviid is strongly opposed to this approach. he prefers to not define generics explicitly, but let every module that defines methods implicitly define generics and then let the module system merge them. <mark_weaver>the reason I'm opposed to daviid's approach is this: with that approach, you end up with many different generics around the system, with different sets of methods in their tables. <rlb>mark_weaver: reminds me of discussions about clos back when. <mark_weaver>and within any given module, the generics in that module only see the methods from modules that they have imported. <mark_weaver>so, suppose you have a system for drawing graphical objects, making use of a 'draw' method. <mark_weaver>and let's say you have a module that calls this 'draw' method. <mark_weaver>now, long after that module was written, you create a new class and define a 'draw' method on it. <mark_weaver>and then you pass an instance of that object into the pre-existing module with the 'draw' method. <mark_weaver>with the "merge generics" approach, there's no guarantee that the merged generic on that pre-existing module is the same generic that knows about the new class you created. <daviid>mark_weaver: that would be a bug <mark_weaver>because instead of just having one 'draw' generic that everyone adds a method to, you have a whole bunch of them in the system, each formed by automatically merging from others that were imported. <daviid>sorry to just come in :) i was busy ... <mark_weaver>right, daviid considers this a bug, because, afaict, he doesn't want the module system to apply to generics. he wants a global namespace for generics. <rlb>ACTION tries to recall what clos did... <mark_weaver>but then you have a different problem. then, if you have two subsystems that both happen to use the same names for some generics, but they have totally different meanings and semantics, then if you try to integrate them into the same program, boom. <daviid>clos has a clos name space, it is in the spec. the user just have to make sure he/she does not define twice a class using the same name. this is possible though, and trigger a class redefinition ... <mark_weaver>and anyway, it would be fundamentally at odds with modern scheme module systems, which are fairly well standardized now. <rlb>Sounds dicey to assume that you'll always have complete global knowledge about a program. <mark_weaver>one relevant difference between lisp packages and scheme modules is that in lisp, the mapping from strings to symbols depend on what package you're in. <daviid>rlb: which why a user should never define a generic function <rlb>Though I guess it could/would just shout for conflicts. <mark_weaver>whereas in scheme, the mapping from strings to symbols is global, and its the mapping from symbols to bindings that depend on the module. <daviid>rlb: in order to 'play' i recommand to merge generics, as a global setting <mark_weaver>the other thing is, there's really no sane way to implement the global namespace for generics, because there is no syntactic distinction between a method call and a procedure call. <mark_weaver>when the compiler sees (foo 1 2), it doesn't know at that point whether 'foo' is a generic or a normal procedure. <daviid>rlb: a generic function is a vontainer, which, by clos spec,can only be define once. let's assume you use guile-gnome, which defines get and set <rlb>mark_weaver: so wrt the clj bits, sounds like you'd prefer that those just start off as clj-count, etc.? <mark_weaver>so, even if we decided to make a global namespace for generics, there's no way to implement it, because at the time the lookup has to happen, the compiler doesn't even know whether it's a generic or not. <daviid>ok, mark_weaver with repsect to your last sentence, what we have is not optomal, but it works [the merge-dupplicate option I mean]. from the user point of view, a module always sees the methods it needs [not exactly 'a name space' I agree, but that is what we have and it owrks <daviid>mark_weaver: sure, me too actually :) <rlb>wrt the original question, I suppose I could also poke around to see how hard it might be to just support immutable goops instances (i.e. perhaps start by disabling slot-set!) <daviid>rlb: merge-generics is an option and it works [I strongly recommand to use it until you really know what you do] in guile-2.0, but wrt merge-generics, there is a currently bug in guile-2.2 [2,.1]. also, there are 2 serious bug related yo goops in guile-2.0, the main 1 is breaking inheritance of setters, the second is related to '#:export does not honor the merge-generics contract' <rlb>don't want setters, so I should be OK there. Suppose #:export might be an issue <daviid>rlb: i wrote a temporary macro to paliate the bug <daviid>setters are really important, but good if you don't need them 'right now' <rlb>I don't ever want them for this - these are immutable types. <rlb>(i.e. persistent data structures) <rlb>(I mostly only work with immutable data structures right now.) <daviid>i understand, although, how about the hard disk ? [joking] <rlb>daviid: the issue we were discussing fwiw is clojure wrt guile (i.e. a clojure guile dialect, and the possibility of having some of the interesting features also presented on the guile side in an "appropriate" way, i.e. seqs, refs, atoms, agents, the persisitent data structures, etc.). But clojure itself relies fairly heavily (particularly wrt seqs) on generic functions. <daviid>rlb: that would be great! also, i always wanted to work upon an immutable goops implementation too, but maybe not this life :) who knows <rlb>i.e. in clojure, pairs (lists) aren't special, the full set of operations work on all collections: lists/sets/sorted-sets/hash-maps/sorted-maps/seqs/strings/vectors/etc. And you can add your own by implementing the sequence interface. <daviid>ACTION use clojure too [playing more then 'really' using it though] <rlb>You can write one version of a function like partition, take, reduce, reductions, etc. that works on all of those types (on any thing that can become a seq). <daviid>i understand you are willing to work on that for guile/scheme, this is great <rlb>But the clojure functions look like count/reduce/partition/cons/first/next/rest/etc. <rlb>They use lots of short, generic function names, which makes for some nice, compact code, but raises "questions" wrt guile/scheme. <daviid>rlb: have to go afk but relly interested to share ideas wrt goops, whenever you want i'll be happy to do so ... <rlb>daviid: oh, hmm, and I wonder if for *one* approach to the guile side, you might actually not want a global goops namespace, i.e. you might define a bunch of clj generics like count/first/... and just make it clear that if you want to write code that looks more like clojure, you can, but you'll need to #:prefix the core scheme bindings, for that code i.e. scm:first scm:cons, etc. <rlb>Then there would be a parallel convention for those who want to write more idomatic scheme code. They'd just always #:prefix the clj functions with clj: during import (or whatever). <rlb>But for that to work, goops would need to make sure not to ever merge the current module's cons with either the prefixed clj:cons or the prefixed scm:cons. <rlb>Dunno, this is the most I've really thought about that part of the problem yet. <daviid>rlb: i'd rather define clojure classes and let the system dispatch. your solution does not solve the user problem: what about if i want to write my clj:cons for my class(es), import modules ... talk to you tomorrow... bue <rlb>daviid: I assume you'd (use-modules ... (... seq)) and then (define-method (cons-or-clj:cons-or-scm:cons ...) ...) or whatever you called it, depending on how you wrote your use-modules. Would that not do it? <rlb>Oh, I suppose not if the merge only affects your module - no one else would see it... <rlb>Suppose I'll need a better mental model of the way goops actually works. <rlb>(Thinking about it - I suspect clj probably doesn't require anything more than single argument disatch for the core. It avoids full multimethods when not necessary (i.e. prefers single-dispatch protocols b/c they're much faster on the jvm). <daviid>well, if your method name is so peculiar that there would be 1 method only, then you'd rather write a procedure, goops has and will always have a performance penalty. but if gooops, you want to name your cons, seq, list ... and have classes to let the system dispatch ... <rlb>By single-dispatch, I mean only dispatch on the first arg. <rlb>not general multimethods (generics) <rlb>i.e. clj has protocols which only specialize on the first arg, and then much more general multimethods, more like clos (with higher cost) <daviid>users not loading you clojure module(s) would still use guile's internals cons, list ..., once he/she loads everything becomes generics and they will suffer performance penalty <daviid>single dispatch still needs generics. goops is polymorphic [as opposed to single dispatch] <rlb>So cons would become a generic globally just via (define-method (cons ...))? <rlb>i.e. it's not at module-load time? <daviid>at module load time, like it is for some of guile's nternal w/wthout goops ... <rlb>OK, right, so in my example, the only people who would pay the penalty are those who explicitly loaded the clj module without a prefix. <rlb>(One convention I've become fond of in the clojure community is that after a while they pretty much universally stopped using "use", i.e. they alway use the equivalent of #:prefix or #:select.) <rlb>So it's quite clear where all your symbols came from. <rlb>(and new exports can't suddenly cause trouble) <daviid>i understand but this is really against the clos 'spirit' which i am much much fan of <rlb>Oh, I meant for everything, i.e. all symbols over there. <daviid>and hence my 'battle' to have a proper set of option in guile, which we have actually, it's just buggy right now <rlb>Though I do see ":refer :all" used wrt the test harness. <daviid>clos is an order of magnitude superior to any module system, but, you must make sure to name your class uniquely, that is all you have to do <daviid>immutable goops is the future: but we need deep thinking, slot-set! should be allowed, it would 'just' make a shared copy of the istance .. we can't deep copy instances 'all the time' <rlb>i.e. its more flexible dispatch <daviid>i doubdt it reaches the power of clos, but will red <rlb>Is there a way to create a module that explictly uses (guile) so that it can apply a renamer? <rlb>(In clojure, for example, if you explicitly mention the core, you can make adjustments, i.e. (:refer-clojure :exclude [ancestors printf])) ***michel_mno_afk is now known as michel_mno
<lloda>ArneBab: no real complexity. It's more that it discourages me from using structs. alists or closure-objects don't have that problem. <lf94>car, cdr functions make zero sense glancing at the with no explanation. I hope the guile manual does a good job x) <wleslie>car and cdr are the names of the first and second fields of a pair. <amz3>ice-9 match is prefered to using car and cdr. It's similar to javascript detructuring <amz3>I'd like to share a 4h hour bug hunt in bindings of wiredtiger. Context: All function that I've bound to get a minimal example use of the library are working. I wanted to add a support for transaction since it's one of the main feature of wiredtiger <amz3>the bind was ok, but the small snippet i use to test was failing at another call after (session-transaction-begin). Always with the same error code. <amz3>I just discovered that `cursor->set-key` is not returning an error code (like other methods do in wiredtiger) the signature is `void set_key(cursor, ...)` <amz3>the funny thing is that I could have met the bug before binding (session-transaction-begin) but random wanted something else :) <davexunit>I'm going to adjust the letters a bit, but I was definitely going for the crude look because I'm not an artist <davexunit>and the text is now horizontally centered with the ghost <remi`bd>still fighting with GNUnet right now; what about you? <amz3>I finally found the mojo to code something <amz3>it may not be unfamiliar then <amz3>when is the end of you gsoc? <amz3>I working on wiredtiger bindings (a key/value store that can be found in mongodb ;) <amz3>i'm trying to put together a small example application, search index kind of application <amz3>remi`bd: I have plenty of free time, maybe I can help you? <remi`bd>I’m supposed to finish coding in a little more than two weeks <remi`bd>my problems are mainly with the lack of documentation or proper error reporting in GNUnet; when all you have is a core dump, debugging can be very fastidious. <remi`bd>but I’ve managed to solve each problem one by one for now :) <amz3>if you need help don't hesistate <amz3>the bindings are part of the project I talked with you <amz3>I don't like to work with a regular rdbms, I know better ;) <amz3>remi`bd: do you have news about ijb? <remi`bd>by the way, thanks for proposing help :) <amz3>I'm nearly done with my example app using wiredtiger. I will be able to show it to the rest of the world :) <amz3>there is much less feature in the example app, than when I started. I assume this the way to learn humility <amz3>I used a bottom-up design like my master told me. I would be proud of me. <sneek> 13:22:49 up 35 days, 21:09, 0 users, load average: 0.00, 0.01, 0.05 <sneek>I last saw amz3 on Aug 04 at 05:17 pm UTC, saying: :p. <sneek>wleslie was here Aug 04 at 05:23 pm UTC, saying: sneek: botsnack. ***michel_mno is now known as michel_mno_afk
<davexunit>amz3: paul graham (the YCombinator guy) has an essay in which he describes how lisp allows one to develop both top-down and bottom-up. <amz3>good idea, i look into that thanks <davexunit>you can work top-down in the sense that you work on your high-level abstractions <davexunit>but you also work bottom-up because you can find and identify places where the code would be cleaner if you extended the language with a macro <davexunit>this isn't advice or anything, but you triggered this memory. <amz3>I can't code anymore, I need to do something else anyway <dsmith-work>My laptop at home would go to sleep about every 30 seconds after upgrading to Jessie (and systemd) <mario-goulart>I updated from wheezy to jessie (because I like to use STABLE) and it totally trashed my system. I mean, it was unusable. <davexunit>I've had that happen to me with debian, arch, ubuntu, etc. <davexunit>if I bork my guixsd, I can just boot the previous system that worked. <wleslie>typically OS upgrades end up with me formatting the system and starting over >_> <daviid>wleslie: never had to do that in 20y, but i had my headhackes too of course :). fyi, I 1st track gdm/gnome session failure using journalctl -xb: most of the time it is a ridicoulus incompatible file [even greeter settings can get you in gdm failure!] ... and most of the time you can fix these... just my 2c <wleslie>I use so little infrastructure now that's not the sort of thing that bites me anymore <daviid>wleslie: ok, jst wanted to share with others here, that journalctl -xb is your friend to track systemd, gdm, xdm, X11 ... problems <davexunit>daviid: I looked at the guile-gnome page, and I noticed a minor error that I believe is caused by not rendering your sxml with a utf-8 encoding. <davexunit>or rather, not putting the relevant meta tag in the generated html <daviid>i'm not a very good sysadmin by the way, but have to manage quite a lot of testing box @ univ here .. <daviid>davexunit: oh nice, what is the bug? <daviid>dave what page I mean? I'm pretty sure I did render using encoding but ... <davexunit>daviid: "© 2003-2015 Free Software Foundation, Inc." <davexunit>the "©" is caused by a non-utf-8 encoding being used. <wleslie>dpkg-query: no path found matching pattern *journalctl* <wleslie>I suppose I won't even get that until I upgrade (: <daviid>davexunit: that is in the template, so all page are using it. I always use this to generate the page: ./env guile -l <page>.scm -c '(setlocale LC_ALL "")(make-index)' > <page>.html <daviid>wleslie: be with you in a minute <davexunit>daviid: add this to the (head ...) form of your sxml: (meta (@ (charset "utf-8"))) <davexunit>I noticed this issue because I had the same issue myself :) <daviid>davexunit: tx! but curious, I did add this: <daviid>(meta (@ (name "Content-Type") (content "text/html;charset=utf-8"))) <davexunit>yes, I saw, but that doesn't seem to do the trick. <davexunit>I don't know the rules with all these meta tags. <daviid>and you have no (name ...) for that 1 ? <wleslie>actually I suppose I'd better get some sleep <daviid>i thought meta has to have both a (name ...) (content ...) <daviid>wleslie: ok ttyl then, prob missing a package [journalctl ...] <wleslie>hm, seems I don't have wheezy-backports <daviid>davexunit: just updated the index.html page [only], could you check? don't know when it will be uploaded though, since I did not change anything else, just have to wait like 10min [pretty fast generally but ...] <daviid>davexunit: i think i know why it did work before <daviid>i think this is not good: (content "text/html;charset=utf-8") <daviid>should be (... (content "text/html") (charset "utf-8")) <daviid>davexunit: I'd like to try this instead: ... (meta (@ (name "Content-Type") (content "text/html") (charset "utf-8"))) ... done! could recheck in a couple of min? [sorry to abbuse] <daviid>davexunit: just uploaded all [regenerated] html pages, using the above change ... <amz3>ACTION how to use the mailling list as dvcs <paroneayea>so one of the books that arrived is the postgresql book <paroneayea>maye I can succeed at writing a postgres ffi thing to the C library 