IRC channel logs


back to list of logs

<nalaginrut>morning guilers~
<paroneayea>hi nalaginrut
<paroneayea>what's the haps
<nalaginrut>no coding work, continue to write documents...
<mark_weaver>Good talk: "Programming Considered Harmful"
<nalaginrut>oh, they removed OOP/Extreme/TTD/Pair... finally?
<nalaginrut>I mean they used to use "OOP Programming Considered Harmful" as title, now they removed it finally ;-P
<nalaginrut>I'm kidding
*nalaginrut is watching...
<mark_weaver>ah :)
<ArneBab>saul: nice!
<nalaginrut>well, this video revealed too many my caveats, I'm going to delete it
<civodul>Hello Guilers!
<ArneBab>moin moin
<ArneBab>saul: I like it how you stick to the basics (and avoid stuff like the stuff I did ☺): That makes it much easier to understand what your code does.
<saul>ArneBab, I used named let for almost all my looping. Everytime I encounter a fold-* (or try to use it myself), I have to check the reference manual.
<ArneBab>saul: same for me…
<saul>I understand what fold does, I just can not seem to remember the order of the arguments or which way is left or right.
<ArneBab>saul: nowadays I also use srfi-42: It’s list comprehensions (build lists)
<saul>ArneBab, since more than half of my Scheme programming is in GIMP's Script-fu (TinyScheme), I tend to avoid relying on too much of the high level stuff (e.g., SRFIs and ICE-9)
<ArneBab>saul: script-fu ← cool!
<ArneBab>moin wingo
<mark_weaver>saul: here's another way to compute the potential energy, using srfi-42 eager comprehensions:
<mark_weaver>(that's analogous to the code you pasted at <>, but note that blocks tor users outright, please consider using a different paste site)
<mark_weaver>that code optimizes clarity and simplicity over efficiency
<ArneBab>saul: I’m not sure why fold seems hard to get (I just wrote 2 explanations, and all seemed fishy), but for me it is similar.
<ArneBab>I think (if I understood correctly what you wrote)
<mark_weaver>I don't usually use srfi-42 in my own code, but that's how you might do it anyway.
<mark_weaver>although there is some cross-cutting of concerns, I confess..
<saul>mark_weaver, I will start using (and thanks for the code).
<wingo>good early morning / late evening mark_weaver :)
<mark_weaver>hi wingo!
<mark_weaver>I think I'd probably rather promote use of foof-loop for something like this, for several reasons. alas, we don't have it in guile.
<mark_weaver>for one thing, foof-loop generates purely functional code, whereas srfi-42 generates imperative code.
<mark_weaver>and even if you don't care about functional programming, our compiler does better when there's less mutation
<mark_weaver>I'm tempted to add foof-loop to guile to avoid tempting people to use srfi-42 for the sole reason that it's already included in guile.
<mark_weaver>what do other people think?
<wingo>mark_weaver: i don't have much experience with foof-loop -- that's the one that's maintained by Riastradh, no?
<wingo>if it makes us write better code it sounds good to me :)
<mark_weaver>I think there are two variants, one by alex shinn and one by riastradh
<mark_weaver>and iirc, the only difference is the way you can extend it for new generator types
<mark_weaver>(or something like that)
<mark_weaver>and actually, we could make a nicer extension mechanism than either of them by using ck macros.
<mark_weaver>but yeah, I think the one from riastradh is the current state of the art
<mark_weaver>well, current preferred foof-loop implementation
<wingo>what do you think about racket's looping constructs?
<mark_weaver>I've seen them used, but haven't really studied them.
<mark_weaver>I guess it's worth a look, of course
<wingo>yeah me neither
<mark_weaver>but I must say that when I looked closely at riastradh's foof-loop, I was impressed
<mark_weaver>at first I had a bad reaction to it, thinking it was like common-lisp's loop macro.
<mark_weaver>and at one point I mentioned that on #scheme and riastradh challenged me on it, and i realized that I hadn't studied it closely enough.
<wingo>we could have (ice-9 loop) for foof-loop and (ice-9 for) for racket loops
<wingo>if that's a thing we wanted
<mark_weaver>when I looked closer, it seemed much saner than I had thought on first glance.
*mark_weaver looks at racket's for
<mark_weaver>wingo: one thing I notice right away: both srfi-42 and racket's 'for' encourage forms that end up requiring a dispatch on the type of the sequences, and many sequence types are supported.
<mark_weaver>whereas foof-loop generally doesn't do those type-dispatches. it is known at compile time what type of sequence is being traversed.
<wingo>mark_weaver: i think for can inline the iterator in some cases
<wingo>see the bottom of the page
<wingo>apparently that set of cases is extensible too
<mark_weaver>wingo: right, both srfi-42 allow the user to optionally specify the sequence type
<wingo>^ reference, rather than manual
<mark_weaver>*both srfi-42 and racket 'for' allow it
<mark_weaver>but they both _encourage_ the generic operations, because the code ends up shorter that way.
<wingo>i don't see much generic iteration in the examples tho
<wingo>i guess the examples at the top, yeah
<wingo>hmm :)
*wingo ignorant
<mark_weaver>it's not even clear to me which way is better, just a notable difference.
<wingo>another link fwiw
<wingo>would be nice to have a better generic lazy sequence abstraction
<mark_weaver>hmm, if it's lazy, then how about srfi-41?
<mark_weaver>though I guess it's a bit heavier than I'd like
<wingo>i think srfi-41 could be an implementation of the generic sequence interface
<wingo>you wouldn't want to use srfi-41 for iterating over a vector tho
<mark_weaver>wingo: yeah, we could do a *lot* better than srfi-41 efficiency-wise
<mark_weaver>anyway, I'm an idiot for staying up so late. much sleep...
<mark_weaver>*must sleep
<mark_weaver>happy hacking!
<wingo>likewise and sleep well too :)
<ArneBab>mark_weaver: having foof-loop in guile would be neat - currently it’s hard to get.
<ArneBab>(I had to include a link to the guildhall setup in py2guile for that)
<dsmith-work>Tuesday Greetings, Guilers
<ArneBab>moin dsmith-work
<paroneayea>will anyone from here be at FOSDEM?
<paroneayea>would be nice to meet some other guile folks in person
*civodul raises his hand
<paroneayea>hey civodul :)
<paroneayea>I met someone into guile at FOSDEM last year but I can't remember who their name was :(
<paroneayea>Deb Nicholson and I (Chris Webber) met them for lunch
<civodul>i saw wingo said he's coming
<paroneayea>oh cool
*davexunit wishes he could make it to FOSDEM
<paroneayea>wingo: I'd love to meet you if there was a chance!
<paroneayea>I think Deb said there was some GNU gathering, maybe I'll make it to that...
<paroneayea>I'll def be going to this though:
<paroneayea>davexunit: FOSDEM is great, and also insane
<paroneayea>soooo many people and so much to see, and pretty much always nowhere near enough time
<davexunit>it's just so far away
<nalaginrut>seems GHOST gone away after I updated debian
<civodul>paroneayea: check the discussions on
<civodul>a couple of dinner/beer options have been proposed
<jgrant>So, I've been playing with Skribilo a bit and it's been awe-inspiring to me thusfar. :^)
<civodul>by atheia actually
<civodul>i hadn't noticed you were here :-)
<civodul>jgrant: heh, nice
*jgrant is strongly considering refactoring his current blog, that's in Frog -- into Skribilo. Like 3/4ths of the way there to conviencing hemself.
<atheia>civodul: heh, yeah; guile, guix & hurd is where I tend to lurk around…
<atheia>paroneayea: I believe it was me you and Deb met last year for lunch?
<wingo>paroneayea: yeah let's meet sometime!
<wingo>fosdem is such a mess tho :)
<atheia>So you'll be here again this year. Cool!
*mark_weaver recommends the talk "Programming Considered Harmful"
*davexunit loads to watch later
<mark_weaver>and right after watching that, I watched "High-Performance and Scalable Updates: The Issaquah Challenge" <> in which I learned details of RCU in linux (the kernel), and was utterly horrified.
<mark_weaver>if that's the road Linux is going down, it's guaranteed to have subtle bugs.
<mark_weaver>maybe I'm reading too much into it, but it seems to me that at points in that talk, Paul McKenney is almost hinting that he's been forced down this road because his employer (IBM) would be disadvantaged if Transactional Memory were more widely used.
<mark_weaver>but I've never seen a more compelling advertisement for Transactional Memory than Paul's talk on RCU.
<mark_weaver>or maybe Paul sincerely believes that this level of cascading complexity in the design is justified for performance reasons.
<daviid>hello guilers
<sneek>Welcome back daviid, you have 2 messages.
<sneek>daviid, wingo says: the answer to your issue will not make you happy :)
<sneek>daviid, wingo says: turns out the fix to #17355 was wrong; that really accessor methods aren't meant to be "chained"
<mark_weaver>but I for one would rather run a kernel that uses algorithms whose correctness I can convince myself of.
<davexunit>mark_weaver: to some people, performance is the end all be all.
<davexunit>performance at all costs. write *everything* in C.
<jgrant>davexunit: Binary.*
<davexunit>cue xkcd comic.
<mark_weaver>davexunit: this goes *way* beyond writing everything in C.
<davexunit>it certainly sounds scary.
<jgrant>Too bad whoever came up with Binary, wasn't named Benard and named it after himself. Benardary.
<davexunit>I am ignorant of what RCU is.
<davexunit>and transactional memory. I'll have to do my homework.
<mark_weaver>shared-mutable-memory multiprocessing is such a nightmare. the more you learn about what's being done to try to preserve this nice intuitive (but utterly unscalable) model and make it efficient is leading to madness.
<mark_weaver>almost no one understands it anymore.
<mark_weaver>our mental models of what's going on have diversed significantly from the actual semantics of modern machines, which almost no one understands.
<mark_weaver>our systems are guaranteed to be steaming piles of bugs
<mark_weaver>transactional memory is the only sane solution I've seen for preserving this basic shared-mutable-memory model, but alas it seems to require hardware support to implement efficiency (as intel is doing)
<mark_weaver>but it would be ever better if we stopped trying to use this model and went to communicating sequential processes, IMO.
<daviid>wingo: ah, oh, arghh :) no, inherited slots are inherited :) they are the 'same' slot, exactly the same [not talking about the location in memory, neither about goops internal machinery] : everything that was defined 'upon/with' that slot is inherited and when a setter is called upon such an inhereted slot, it is the code that was defined for the super that is[should be] called. anything else is an error, I think
<mark_weaver>but I realize this is blasphemy these days :)
<wingo>daviid: sorry, your interpretation does not agree with goops design :)
<wingo>please respond on the ml
<daviid>well it is a design error :) then
<wingo>that's an interesting opinion :)
<wingo>the fact is that defining a slot `a' on a subclass overrides or shadows `a' on any superclass
<daviid>that's correct
<wingo>so the subclass *does not have* the superclass's slot
<daviid>i'm not talkig about that
<daviid>i sne d a clear test case of a inherited slot, not a slot redefinition
*mark_weaver thinks daviid wants a way to override certain attributes of the superclasses slot, like the initial value.
<daviid>mark_weaver: no, i want the inheritied slot to be inherited :)
<daviid>see the test case
<mark_weaver>daviid: where is the test case again?
<daviid>it is hort, very versy short and says it all
<mark_weaver>daviid: but if you declare a slot in a subclass with the same name as a slot in the superclass, I would think that wingo's interpretation is correct. otherwise, if your name accidentally conflicts with a private slot in the superclass that you may not even know existed, it would be bad.
<mark_weaver>but this seems to be a common theme, that daviid doesn't like the module system and wants global namespaces.
<wingo>daviid: so you also *overrode* the method for the subclass -- just like redefining the method. the old method, the old accessor method for the subclass is gone
<mark_weaver>(perhaps I'm oversimplifying, but that's my impression)
<wingo>so there's no accessor to chain to
<wingo>or no method, rather
<daviid>wingo: what? :) i did not redefine anything, the setter is not called, it should
<wingo>(define-method (access (self <subclass>) val) ...)
<daviid>mark_weaver: i think you are mixing things, i am talking about a fundamental clos spec here, not the module system
<wingo>that overrides the method that is installed by the class definition
<wingo>same specializers -> overridden method
<daviid>wingo: i don't are we talking about the same thing here? here the code:
<wingo>daviid: no time now, please send something the the ml
<mark_weaver>daviid: btw, I came up with an example to demonstrate the fundamental problem with merge-generics:
<wingo>daviid: also please build stable-2.0 or master, latest version, before posting an example
<daviid>i don't have much time either actually, but it is a [serious] bug
<daviid>wingo: i run stable-2.0 the latest
<mark_weaver>daviid: I'm curious what you have to say about that example.
<wingo>daviid: your example would not work as you say on the latest stable-2.0
<wingo>it is a serious bug *to you*; that does not entitle you to my time
<paroneayea>atheia: aha!
<paroneayea>and wingo I'd love to meet up with you at fosdem!
<daviid>wingo: it isd a clois spec, not my spec
<wingo>frankly i am unhappy with the tone of this conversation, after i spent a month working on goops, because of your bug
<daviid>i am unhapy as weerll
<wingo>so please, not so demanding daviid.
<wingo>lol but i am not asking you to work for me.
<daviid>i am helping guile man, not asking you anything
<daviid>i am using it and reporting bug
<wingo>i have said my piece.
<daviid>me too, peace then
*mark_weaver looks at daviid's paste
<daviid>mark_weaver: i don't have time now but i will look at yours as well
<mark_weaver>wingo: hmm, fwiw, I'm also confused why david's example in doesn't work. he's not actually overriding any methods in the subclass. the subclass overrides *nothing*, and yet it doesn't seem to be inheriting methods of the superclass.
<mark_weaver>bah, just missed him.
<daviid>wingo, mark_weaver: it works with the latest stable-2.0! i must have tried it [2 days ago] using the detached... my mistake, my appologies, it _does_ work like expected now
<mark_weaver>daviid: ah, that's good news
<daviid>and this is fantastic, i had to werite bad code for years because of that but, great! thanks!
<mark_weaver>sneek: later tell wingo: your disagreement with daviid turned out to be miscommunication, and daviid apparently not testing with the latest stable-2.0. he's happy now, fwiw.
<sneek>Got it.
<mark_weaver>sneek: later tell wingo: happy on this particular issue, anyway
<sneek>Will do.
<mark_weaver>daviid: is that a reasonable summary?
<daviid>yeah, mark_weaver thanks, too bad we mixed up talks about 'the accessor' problem [as reported by another user] and my setter problem, which till the very latest was a real bug, for which i did not report and should have ... but anyway, all fine, i am double checking now with more sophisticated code then the test case i sent... i was sure i did check with stable, but did not also his answer [the ml] was as if he 'refused' to debug, i did
<daviid>not recheck today, came to hello and ... well closed now, in peace as far as i am concerned
<mark_weaver>that's good :)
<sneek>Welcome back wingo, you have 2 messages.
<sneek>wingo, mark_weaver says: your disagreement with daviid turned out to be miscommunication, and daviid apparently not testing with the latest stable-2.0. he's happy now, fwiw.
<sneek>wingo, mark_weaver says: happy on this particular issue, anyway
<wingo>oh that's good
<wingo>paroneayea: yeah let's meet some time! i will at least be at, if other things fail
<paroneayea>wingo: oh cool
<paroneayea>wingo: I am giving 3 talks:
<paroneayea>wingo: and yeah, whoa :)
<paroneayea>I didn't anticipate all 3 being accepted
<paroneayea>and all 3 are new
<paroneayea>so I am going a little bit crazy in prep mode
<paroneayea>the last two are co-presented with Deb Nicholson
<paroneayea>wingo: I can probably make your talk, but will very shortly afterwards have to head to my own :)
<wingo>paroneayea: they seem to start at the same time!
<paroneayea>wingo: oh yours says sunday not saturday
<paroneayea>no wait
<wingo>it's friggin confusing
<wingo>o/~ fosdem o/~
<paroneayea>oh I see now
<paroneayea>confusing indeed
<wingo>i downloaded the android app from the f-droid thing, it's the only way i'll be able to make sense of anything
<paroneayea>oh there's an app on f-droid?
<paroneayea>I'll fetch that
<paroneayea>wingo: When you said "android app" I almost immediately reflexed "I don't use Google Play", so rare to have such a one-off app available on f-droid :O
*wingo doesn't have do google play either; too bad in some ways, but f-droid was a surprising find
<paroneayea>wingo: will you be at the conservancy dinner by any chance?
<wingo>paroneayea: i think i have other plans
<paroneayea>wingo: aha :)
<wingo>fosdem is so big :)
<wingo>some other old friends coming into town...
<wingo>from the gstreamer days
<paroneayea>wingo: well, I have nothing immediately after my saturday talk. Maybe I can try to catch you after that
<paroneayea>wingo: oh cool
<paroneayea>gstreamer \\o/
<paroneayea>wingo: we use gstreamer for transcoding in mediagoblin
<paroneayea>for video support
<wingo>nice :)
<wingo>a number of the gst folks will be at fosdem
<wingo>sebastian, tim, wim
<wingo>a few more i think
*paroneayea thinks how we can coordinate meeting
<paroneayea>civodul: oh hey, I think I should be able to make your Guix talk
<paroneayea>I'd really like to see that.
<civodul>heh, cool
<civodul>it's always a pain to synchronize at FOSDEM
<rekado>ouch: "Error while printing exception."
<civodul>yeah that's always frustrating :-)
<civodul>you can attach gdb with the libguile-gdb thingie, add a breakpoing on scm_error, and you might get more info
<civodul>(dirty hack)
<civodul>hey, rotty
<civodul>long time no see!
<rekado>found it. One level of parentheses too much. `((#:python ,python-2)) instead of `(#:python ,python-2)
***pchrist_ is now known as pchrist
<dsmith-work>sneek: seen rotty
<sneek>I last saw rotty on Jan 14 at 07:32 pm UTC, saying: mark_weaver: in case your wondering why I haven't pushed the patch you gave the go: I'm not getting past "make distcheck", neither on pristine stable-2.0, nor with my patch applied.
<mark_weaver>is that supposed to be from Jan 14 2015?
<mark_weaver>I have no idea what he's talking about
<mark_weaver>might it be from Jan 2014?
<mark_weaver>dsmith-work: would sneek print the year if it was more than a year old?
<dsmith-work>mark_weaver: Hmm. Probably not.
<ArneBab>mark_weaver: with my limited experience, I disagree strongly with “programming considered harmful”. →
<ArneBab>mark_weaver: If the programming is bad, all the context you write around it will not make the code good. It will not make the machine help you solve the problem you face. Or solve it better than before. You need more than programming for a project, but without good programming, all the stuff around it is just building castles in the clouds
<ArneBab>^ the result of seeing software engineering failing completely at producing something useful in practice.
<ArneBab>(caveat: experienced while studying)
<mark_weaver>ArneBab: I don't understand what you mean by "If you disregard programming, you have to design for bad programming (more problems than needed), and that results in overly complex design."
<mark_weaver>I'm not sure what it means to "disregard programming", nor how that relates to his talk.
<mark_weaver>I wonder if you've worked on projects with sufficient complexity to run into the problems he's talking about.
<ArneBab>mark_weaver: in the talk he kept talking about problems of saying that we do programming.
<mark_weaver>did you see the definitions he gave at the beginning of the talk? of computer science, software engineering, and programming ?
<ArneBab>let me check whether I missed something essential there
<ArneBab>mark_weaver: he defined “real programmer”, not programming. He talked about programming as just jotting down text.
<ArneBab>and showed the effects of bad programming.
<mark_weaver>ArneBab: he defined "programming" on slide 6
<ArneBab>I’ll check
<mark_weaver>and "programmer" on slide 7
<mark_weaver>the "real programmer" thing was much later
<ArneBab>so he defined programming as just producing code.
<mark_weaver>did you notice the essential difference between that definition and the definitions of "software engineer" and "computer science" ?