IRC channel logs


back to list of logs

<nalaginrut>morning guilers~
<nalaginrut>alas~I realized that I don't have a denotational semantics book, and there seems no PDF on line or kindle version
<nalaginrut>and even no published in China ;-(
<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))
<wingo>not usually...
<nalaginrut>just found this way could emulate 'return' of C ;-P
<nalaginrut>but I don't know if it's proper
<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>it's not the same.
<wingo>the place that it returns to is the definition of return
<wingo>(define return <>)
<wingo>like where that <> is
<nalaginrut>yes, I thought the continuation should be caught in the place of procedure, but I found the definition I pasted works
<nalaginrut>so I asked if it's proper ;-P
<wingo>sneek: later tell mark_weaver
<dsmith-work>Hey. Hows it happenin, Guileers
*wingo hacking dwarf things
<davexunit>*no dwarves were harmed in the making of GNU Guile*
<add^_>*all died*
<xdje>dwarf as in dwarf debug info?
*xdje would love a dwarf reader for guile
<wingo>xdje: here you go :)
<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
<davexunit>I take it that dwarf is a play on ELF?
<xdje>Actually, it is a play on ELF. [according to someone on the dwarf committee who sits beside me]
<wingo>xdje: fwiw,
<dsmith-work>And is there also Extended documeNtation formaT ?
<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?
<civodul>email? :-)
<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
<ijp>ghastly mess
<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>and that's tough with email
<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
<wingo>but email is ok :)
<civodul>i agree that email is far from ideal
<civodul>those functionalities look great
<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>maybe i misunderstand
*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
<wingo>you never revert, then?
<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
<tupi>ok, let me look
<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
<foeniks>I see the point
<ijp>you and I think about lexical scoping very differntly
<wingo>ijp: orly
<wingo>tell me more!
<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>but cons is silly ;)
<foeniks>polymorphism is a complexer concept
<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>of course
<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
<wingo>heh, indeed...
***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 :)
<foeniks>that macbook here still has rcs
<foeniks>back in the days
<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 ...]
<foeniks>no pull request then
<wingo>tupi: i did but there were a few months (!) when i was hacking on the compiler, and i was neglecting most email
<wingo>yours fell in that range
<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
<wingo>ijp: it's turrible
<ijp>completely context sensitive
<tupi>ok, just wanted to be sure. then when it is apropriate, let's talk ...
<foeniks>parsing what?
<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>the devil is in the detail
<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"
<ijp>i hate that
<davexunit>sad to hear that org-mode syntax apparently sucks.
<davexunit>I love org-mode.
<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