<nalaginrut>alas~I realized that I don't have a denotational semantics book, and there seems no PDF on line or kindle version <dje42>Ugh. scm_i_with_continuation_barrier is internal. <dje42>[I need scm_c_with_continuation_barrier, but I also need to supply the unwind and pre-unwind handlers.] <dje42>Is it possible to code around this? <dje42>Guess I can pass in a wrapper around another call to scm_c_catch, but it's unnecessary redundancy. Any reason not to make public something like scm_i_with_continuation_barrier? <nalaginrut>is it proper if I define 'return' like this: (define return (call/cc (lambda (k) k)) <nalaginrut>just found this way could emulate 'return' of C ;-P <wingo>it doesn't mean exactly what C's "return" means. <nalaginrut>well, just looks like C's "return" to return a value in any place of a procedure <wingo>the place that it returns to is the definition of return <nalaginrut>yes, I thought the continuation should be caught in the place of procedure, but I found the definition I pasted works *wingo hacking dwarf things <davexunit>*no dwarves were harmed in the making of GNU Guile* <xdje>dwarf as in dwarf debug info? *xdje would love a dwarf reader for guile <wingo>currently working on a writer <xdje>Awesome. 'tis on my wish list. Hoping to play with it in gdb+guile. <wingo>of course in gdb there are other dwarf libs at your disposal, but that's a fairly complete dwarf reader <xdje>Actually, it is a play on ELF. [according to someone on the dwarf committee who sits beside me] <wingo>dsmith-work: one can only hope! <foeniks>wingo, why choose gitorious over github? Any specific reason for the preference other than not using the biggest platform? <dsmith-work>foeniks: gtihub is often shunned because it is non-free. <wingo>foeniks: heh, just because gitorious is free software; github is way better tho ;) <wingo>not sure what to do in that regard in the medium term <wingo>though i don't like pull requests <wingo>it's a terrible form for patch review, compared to something like gerrit *jao finds gerrit's awful and much prefers github's code review <davexunit>github adds a lot of gloss to the pull request thing <davexunit>I would prefer something simpler and maybe not web based? <davexunit>I'm trying to get used to email code review. :) <ijp>well, email has its own problems, but fortunately I won't have to deal with any of them <wingo>civodul: having worked with rietveld, the thing google uses, i like the ability to see patch interdiffs <wingo>i.e. what changed between v1 and v2 of this patch <wingo>it's also nice to be able to track when a comment on a particular piece of code is addressed, when you go to finally say "r+" <wingo>it's easy to just leave off a comment when you respond to a review, and your perception of that comment compared to the reviewer's perception may differ <civodul>i agree that email is far from ideal <jao>hmm... i use github code reviews over email all the time (?) <civodul>too bad there's not an Emacs mode for that ;-) <jao>and receive notifications when someone replies to them <wingo>jao: isn't it tough to incrementally update a patchset over github's thing? <wingo>you end up tacking on "fixup" patches <jao>wingo, you just push new patches to the given branch *wingo likes perfect patchsets :) <jao>and all code is folded down and marked as modified <jao>not sure what happens if you rebase at the end with the old comments... we rarely do it, but i'd say they're not lost <jao>i could be wrong with that, though <wingo>i guess the issue is what if you have a patchset that should be broken up into 4 parts, then review causes you to change something with one of the early parts <wingo>either you merge something that you can't bisect, or you squish the whole changeset into one patch <wingo>or you make a new pull request, losing your context <wingo>maybe i am too obsessive in this regard <wingo>centralist, authoritarian mindset ;) <jao>yes, i'm not sure how to tackle that, or how github handles it. it's never been a use case in my experience. <jao>but then, i rarely look back at my code :D <davexunit>at my job, my boss has started squishing merges into one commit <tupi>wingo: if you answer ['yes i'll do it asap'] my guile-gnome-platform upon gtk3, guile-clutter, guile-clutter-gtk the latest, i promiss i write the best ever patch reviewer, in guile-clutter-gtk of course, how is that? :) haha [nice to dream though] <wingo>tupi: want commit access? (be careful though :) <wingo>tupi: send me the request on savannah and i'll add you <wingo>sorry for being so stupid about it <foeniks>is there any way to make guile more polymorphic? <tupi>I think i already did send a request twice. to start with, relax, I will only use it for examples and asking through email first ... <foeniks>maybe this is the lazy duck syndrome but it feels really tedious to always think about types and which variant of procedures to use <wingo>tupi: you're not on the "pending users" list for guile-gnome <foeniks>string-length, length, car, stream-car, etc. <wingo>foeniks: it's a hard question <wingo>scheme has traditionally been about names -- lexical scope is for me the core, essence of scheme <wingo>when you introduce polymorphism you lose precision on what names mean <wingo>so scheme has not gone that way historically -- both from a "how do I reason about this" perspective and from a "how do I compile this" perspective <ijp>you and I think about lexical scoping very differntly <ijp>for me, the point of lexical scoping is that names don't matter, position does <wingo>i'm not negative on polymorphism though, it's just a tricky thing to fit in <foeniks>I mean scheme has this "axiomatic" approach <foeniks>building up things from a `cons', really simplistic <wingo>unless you are making lists, you almost always want a more expressive constructor... <wingo>and when you have more expressive data types often you want polymorphism too :) <foeniks>yet I think the strength of polymorphism is strongest with the very essential operations <ijp>so in principle, in a properly lexically scoped language, I can programmatically change all the names, and it makes no difference <foeniks>I have started to write a clojure parser in scheme <wingo>ijp: sure, but you evaluate the whole program in an environment, and that environment precisely specifies the meanings of a set of names <ijp>this underlines macro hygiene, it explains why I don't agree with introspection on names, or undefinedness <wingo>but once you know that cons is cons -- and that is often the case -- then you know a lot about what cons does <foeniks>so I started pretty much without a very clear idea, not having used scheme for roundabout a year, I started with read-char following along some of the languages implementation in the guile tree <foeniks>then when being frustrated with the "statefulness" of read-char on a port, I thought I could just use a stream <wingo>ijp: but if cons is this extensible generic thing you don't know very much about anything, at that point <foeniks>and all of the sudden I had these 3 notions of sequences, lists of characters, strings, streams of characters <foeniks>and it would be so nice to operate with them with a single interface ***anderson is now known as anderSon
<wingo>foeniks: goops can be a useful stopgap in that regard. it's quirky but it does work well for some use cases <jao>(wingo, if there's a revert, i usually do a git revert and keep the old story. on not-yet-reviewed branches i do lots of rebase and the like, but when the patches enter the code review dance i tend to avoid rewriting history) <wingo>jao: makes sense. currently for the dayjob i'm working on spidermonkey, which means patches in bugzilla; ugh! <jao>wingo, that's a bit how it was back in the day :) <tupi>wingo: just sent the request. but 'my' joke above was more a nice ping refering to my email [and to mark] for investigating a port of the guile-gnome-platform and friends upon gtk3: did you receive these emails [mark's answer, then mine ...] <wingo>tupi: i did but there were a few months (!) when i was hacking on the compiler, and i was neglecting most email <wingo>working back through it but it is taking time <ijp>foeniks: on the subject of parsing, I've been looking over the org syntax document, and despairing <ijp>completely context sensitive <tupi>ok, just wanted to be sure. then when it is apropriate, let's talk ... <ijp>except for the outlining bit, which is pain like python's indentation is a pain <ijp>foeniks: you said you were writing a clojure parser <wingo>sometimes i want ,?foo -- like ,@(let ((x foo)) (if x (list x) '())) <foeniks>ijp, just wanted to make sure you were talking about this as well ;) <foeniks>I probably had started with that a little naive <foeniks>still a little concerned how I will integrate all the syntactic sugar like the #(inline-lambda %1 %2) stuff since it cannot be nested, etc. <foeniks>ijp, I actually suspect that there will be quite some aha moments when continuing with a clojure implementation <foeniks>also, it seems a lot of clojure is kind of "defined by implementation" <davexunit>sad to hear that org-mode syntax apparently sucks. <ijp>it's a death by a thousand cuts <foeniks>ijp, so you were talking about org mode, now I get it <ijp>I may still write a parser, just as a tribute to the masochism of programming