IRC channel logs

2015-10-14.log

back to list of logs

***dje is now known as xdje
<paron_remote>o/ slwebber
<paron_remote>hello!
<slwebber>hey :)
<paron_remote>so, slwebber is my brother, has one of the sharpest minds I know in thinking about programming (smarter than me, for sure!) and is interested in getting into scheme and more language design stuff
<slwebber>hey everyone
<paron_remote>also I said I wasn't going to introduce him to #racket, but then he joined #guile instead, and I couldn't resist I guess
<davexunit>hey slwebber!
<slwebber>hey davexunit, nice to meet you
<daviid>oh slwebber welcome! we like it very much when the sharpest mind join #guile!
<daviid>have to run though, bbl
<nalaginrut>morning guilers~
<nalaginrut>sneek: later tell davexunit actually it's migration ;-)
<sneek>Will do.
<civodul>Hello Guilers!
<nalaginrut>well...gotta implement transaction for Artanis for migration rollback too, lot of work, maybe 0.1.2+ hmm...
<amz3>nalaginrut: you speak about rollback database migrations?
<amz3>this looks more like 1.0 release than 0.1.2+ ;)
<amz3>what will be the big point of the roadmap after 0.12
<nalaginrut>amz3: 0.2 will change the whole server core
<nalaginrut>I'm going to try a very slow version number increasing
<nalaginrut>so if it'll be 1.0 after decade, it's reasonable...
<nalaginrut>0.1~0.2 will concentrate on MVC and DB operations
<amz3>ah ok
<amz3>small number increasing is nice
<amz3>Release Early Release Often is nice too ;)
<amz3>IMO obviously
<nalaginrut>yes
<nalaginrut>I know this principle but seems not easy to do ;-P
<amz3>btw, davexunit released haunt static web site generator and added a skribe reader to it. IIUC he is not interested in markdown anymore because the syntax is too complicated, which I kind of agree but I think there is subset of markdown which functional for most use
<amz3>nalaginrut: my idea, would be to release MVC, then release DB stuff, even if it requires doing small change in MVC
<amz3>I think it can apply well to a web framework and you get feedback more quickly
<amz3>I think nobody expect it to be perfect before 1.0
<amz3>I mean that there is a great probability that people have knowledge about web related software, so you can get more feedback, more patch, more quickly regularly
<nalaginrut>amz3: yes, it's better to release it each time a key feature was added, but I wrote the whole MVC in a row, it's not good develop model, I won't do so next time. It waste too much time to let use play it
<nalaginrut>besides, I wrote scaffolding in a row
<nalaginrut>IMO all these should be released in 5 or 6 versions
<amz3>at the same time, I depending on your coding workflow, you might start something, then move to something else so it makes sens to delay the release
<amz3>actually that's what I do, it's the way I code more, mostly because I'm not confident in guile
<amz3>so i switch between difficult stuff, and easy stuff
<nalaginrut>amz3: yes it is, I have to say, before all these MVC/DB work started, I've no idea how should I implement a better one, so I write half A, then half B...till now I have a clear design in my mind
<nalaginrut>I think it happens in every beginning of premature project
<amz3>that's what i was thinking
<nalaginrut>the simplest principle is do one thing each time, but when you have nothing at all in the beginning, it's not so easy to follow ;-P
<nalaginrut>no mention it is a system
<amz3>what happenned with a software I wrote, is that I settled on a design, then wrote multiple backing store and stuff. People started using it, for some reason, maybe because graphdb is hype
<amz3>after that, i discovered that I've made a mistake, now I rewrote all the thing but I don't release because I don't want to break people code
<amz3>(also I need to write boring code to make it more useable without compiling a third party library)
<amz3>so taking time to release can be benefical
<amz3>actually, I shouldn't care about people code, they just have to install the previous version and port their code
<amz3>s/and/or
<nalaginrut>yes, I'm afraid of such issues, so I do it very carefully, somethings maybe overcautious, but I can still do big change before I tagged it 'stable' ;-P
<amz3>yes that's what i think
<nalaginrut>but we have to be sure that we're not going Hurd's way to release it never ;-D
<amz3>IMO a release doesn't alway mean stable
<amz3>FWIW nodejs does two release on stable, one unstable and maybe also snapshots
<nalaginrut>yup
<amz3>For my AI/NLP project, I want it to be "monolitic" - but I try implement things with loose dependencies, so that people are not bound to a particular workflow
<amz3>This is a design goal, I'm not to the point where there is important loose couple component
<amz3>while working on my git-like cli, I wrote with the idea or re-using it
<amz3>s/couple/coupled
<nalaginrut>amz3: I write it as monolithic one because of a very special reason: it's Scheme project, everybody know Scheme lacks many things to make it a product thing
<nalaginrut>I totally understand why Java community is advocating microservices
<nalaginrut>because there're too many things in Jave, microservices architecture is fine
<nalaginrut>s/Jave/Java
<amz3>my point for this loose coupled monolitic architecture, is that I don't want to deal with numerous dependencies but at the same time I want to maximise the useful-ness of my library so that people can re-use my tools or replace parts of it
<amz3>a better description is independant tools in a single repository ;)
<nalaginrut>amz3: I planed to make Artanis a plugin based on after 0.2, then we may split many things into plugins, after we have specific plugin package manager
<nalaginrut>s/based on/based one
<nalaginrut>now that we don't have a good package manager to handle these plugins at present, it's better keep it monolithic
<nalaginrut>or folks are hard to play it, so many prerequisites
<nalaginrut>amz3: I like "loose couple monolithic", that's why we have chance to split them in the future without change code too much
<nalaginrut>if there's couple between modules, we may add a new layer to decouple it, say, interfaces for external plugins
<nalaginrut>ACTION has to go home now
<amz3>bye
<nalaginrut>see you later guys
<ArneBab>how would I go about testing my srfi-97 implementation?
<ArneBab>can I call the equivalent of ,expand from code?
<ArneBab>found it!
<ArneBab>(equal? (macroexpand (quote (srfi :1))) (macroexpand (quote (use-modules (srfi srfi-1)))))) ; => #t
<ArneBab>(equal? (macroexpand (quote (srfi :1))) (macroexpand (quote (use-modules (srfi srfi-1)))))
<ArneBab>(equal? (macroexpand (quote (srfi :1))) (macroexpand (quote (use-modules (srfi srfi-1)))))
<taylan>ArneBab: I thought Guile already supports SRFI-97?
<ArneBab>it does?
<ArneBab>I don’t see it in modules/srfi/
<taylan>at the very least, (import (srfi :1)) will load (srfi srfi-1). I know this because I implemented the analogous transformation for R7RS.
<ArneBab>ah, nice!
<taylan>ArneBab: check module/ice-9/r6rs-libraries.scm, and some stuff in boot-9
<taylan>ArneBab: and FYI https://github.com/TaylanUB/guile/commits/r7rs-wip
<taylan>though r7rs-wip needs merging with master, and I'm not sure if I'd be able to pull that off. there's also the question of whether we want to support R7RS at all.
<ArneBab>Why shouldn’t Guile support R7RS? Some people seem to dislike it, but it looks like work is done to support it
<taylan>ArneBab: let me find the ML thread...
<taylan>ArneBab: oh, you were in that thread too, "request for feedback on SRFI-126." see Mark's mails I guess.
<ArneBab>oh… (memory’s hazy…)
<taylan>maybe you just didn't read the whole thread :)
<taylan>I also started a comp.lang.scheme thread asking about how many R6RS users/libraries there are out there. it's overall not that much I think, but still more than I thought. it's really awful how incompatible R7RS is with R6RS...
<ArneBab>found the thread (and the memory)
<ArneBab>doesn’t srfi-97 specify that (srfi :n) should be used toplevel?
<taylan>WDYM toplevel?
<ArneBab>outside (import)
<taylan>so the top-level form (srfi :n) works as an import? /me checks
<ArneBab>in my test (import (srfi :n)) works, but (srfi :n) does not.
<ArneBab>that’s how I understood it
<ArneBab>this is my implementation of srfi-97, by the way :) http://paste.lisp.org/display/156452#3
<taylan>from which wording do you deduce that (srfi :n) should work as a top-level form?
<taylan>heh, that's a simple implementation
<ArneBab>:)
<ArneBab>,expand (srfi :1) looks a bit strange, but I managed to put together a test which should work
<amz3>taylan: you work on making R7RS retro-compatible?
<ArneBab>srfi-97 only specifies that other SRFIs can be “referenced”. I had understood that as importing them
<taylan>amz3: how do you mean?
<taylan>ArneBab: I'm not sure. AFAIUI, people are supposed to use (import (srfi :n)), leveraging the existing R6RS feature.
<amz3>taylan: nm
<ArneBab>maybe I just missed context, because the SRFI never spoke about (import)
<amz3>Where can I find a list of Scheme minimal core (upon which all Scheme can be implemented)?
<amz3>otherwise said the primitives of scheme
<ArneBab>here SRFI-97 talks about importing: Authors that wish to use SRFI 5's let, rather than R6RS's let, simply import the SRFI 5 binding and exclude the R6RS binding for let (or rename to avoid the clash)
<ArneBab>but otherwise it just says “can be referenced…as in (srfi :1 lists)”
<ArneBab>so I thought that this is top-level syntax for SRFIs to use other SRFIs.
<ArneBab>Do you think that this would still be useful to add as explicit SRFI-97?
<ArneBab>if yes, there’s something I’d like to add: checking the names to ensure that (srfi :1 foo) throws an error (needs to be lists).
<taylan>amz3: the RnRS usually have a "primitive expression types" section, plus data type APIs which could be considered primitive. note that some SRFIs or other extensions add further primitive forms and types.
<amz3>thanks
<mark_weaver>ArneBab: in SRFI-97, (srfi :n) is not meant to be a top-level syntax. it's meant to be used within 'import', and Guile already supports SRFI-97 afaik, doesn't it?
<ArneBab>mark_weaver: with (import) yes (that’s what I learned from taylan)
<ArneBab>I did not understand that srfi-97 should only work with (import)
<mark_weaver>*nod*
<ArneBab>ok, it’s in the discussion: http://srfi.schemers.org/srfi-97/mail-archive/msg00044.html
<taylan>ArneBab: FYI, while (import (srfi :n)) is transformed to (import (srfi srfi-n)), (library (srfi :n) ...) isn't transformed to (library (srfi srfi-n) ...), meaning that you can't import a library defined as (srfi :n), instead it must be defined as (srfi srfi-n). I have a patch solving that but don't know whether the solution is good. (it's posted to the ML and can be seen in
<taylan> https://github.com/TaylanUB/guile )
<ArneBab>is there a way to get SRFI-97 adjusted so it explicitly states that (srfi :n) should be used inside (import)?
<mark_weaver>ArneBab: it's already finalized, so I don't think it can be changed.
<mark_weaver>but I think it's widely understood to be used within 'import'.
<ArneBab>or is it clear from “it fully conforms with the R6RS library reference syntax,”
<ArneBab>does that still work in r7rs?
<taylan>ArneBab: I think it's fairly obvious from the Abstract which says the SRFI is just an attempt to organize library names, i.e. it specifies no new functionality
<ArneBab>ok
<taylan>ArneBab: in R7RS, (srfi n) without the colon is preferred. this works in my r7rs-wip, but again I don't know if my patches are good.
<ArneBab>but that then does not actually conform to srfi-97, right?
<taylan>nope :(
<ArneBab>:(
<ArneBab>mark_weaver: I missed your email from 30.9., now reading the thread
<ArneBab>(about r7rs)
<ArneBab>is gmane broken right now?
<ArneBab>(is this empty for you, too? http://article.gmane.org/gmane.lisp.scheme.reports/4005 )
<taylan>ArneBab: empty here too
<ArneBab>regarding r7rs and r6rs I personally don’t have a strong opinion. I see the frustration of mark_weaver and wingo as a warning. Currently I mostly just use Guile as the platform. But I would be happy to be able to reuse as much as possible of what I learn here in case I want to use chicken, kawa (java), biwascheme (javascript), tinyscheme (embedded) or similar.
<ArneBab>(I know that some of these only support r4rs or r5rs)
<mark_weaver>the ability to share code with chicken and kawa is the main advantage I see to supporting R7RS.
<ArneBab>where can I find a list of all r7rs compatible schemes?
<ArneBab>(I’ve been searching for the past 5 minutes)
<ArneBab>mark_weaver: was the post by wingo you referenced in your mail the one where he complained that r7rs is written by people who don’t use scheme for real work?
<taylan>ArneBab: I don't know where the most up-to-date list might be, but I think John Cowan keeps such a list. you could mail him.
<mark_weaver>ArneBab: go to r7rs.org and then click on the "Implementation Support" link
<taylan>oh, neat
<mark_weaver>it's interesting that they list Guile, although the support is only on an experimental branch. I wonder if any of the other entries in that list are similarly "supported"
<ArneBab>mark_weaver: thanks!
<mark_weaver>ArneBab: I don't think that summary is quite sufficient, but I linked to the posts, and you should be able to read them, no? they are not long.
<taylan>I'll note that Gauche doesn't search for libraries the way one would expect. (import (foo bar)) will look for $path/foo/bar and not $path/foo/bar.sld like most do.
<ArneBab>mark_weaver: it says “Guile (partial)”, I wonder what that means…
<taylan>ArneBab: even on r7rs-wip, the support isn't complete. on stable, there's no real support, e.g. (define-library ...) is simply not recognized.
<mark_weaver>yeah, it's a stretch to make that claim, given that there's almost no support in our released versions, nor even on our primary branches.
<mark_weaver>makes me wonder how accurate the rest of the list is.
<taylan>FWIW I test my R7RS libraries on Chibi and Larceny so far. these work well, though Larceny's cond-expand has caveats that forces me make minor changes to the code sometimes. I intend to try Kawa and Gauche next, and Chicken when their support is complete. I'm also usually able to swap out library/module boilerplate to make a library's body of code work as-is (or with small changes) on Guile.
<ArneBab>mark_weaver: the projects which aren’t listed as “partial” all claim on their front page to support r7rs
<ArneBab>(though for foment I only found the archived google code project, no new home)
<ArneBab>mark_weaver: releases reminds me that I wanted to ask you about 2.0.12 (I would really like to see an official update)
<mark_weaver>ArneBab: the main blocker there is that we need to discuss the replacement API for SMOBs that wingo added without adequate discussion.
<mark_weaver>but wingo is not very accessible right now
<ArneBab>yes — is it mainly because he’s on honeymoon or did the immigration stuff hurt him even more than his post suggested?
<mark_weaver>I don't know
<ArneBab>this sounds really hurtful: https://wingolog.org/archives/2015/09/23/amores-prohibidos
<mark_weaver>yeah :-(
<ArneBab>I wonder if there’s something we can do to help
<ArneBab>also his tweets on policy sound like there are problems at igalia :(
<mark_weaver>oh, I didn't know about that :-(
<mark_weaver>bah
<ArneBab> https://twitter.com/andywingo/status/647419405924737024 “in an assembly at work we are polling about how much consensus we need in the future. consensus is a process is a process”
<ArneBab>I hope they got that sorted out
<paroneayea>hello!
<mark_weaver>hi paroneayea!
<paroneayea>how are things?
<paroneayea>ACTION sees above... I also hope Wingo is okay 
<mark_weaver>low on time and sleep, as usual :-/ currently working on setting up the second armhf build slave that was donated to guix a while back.
<mark_weaver>(a wandboard quad)
<paroneayea>oh neat
<paroneayea>I'm writing up a blogpost summarizing that conversation davexunit and I had with Sussman at FSF 30th
<paroneayea>to the best of my memory
<paroneayea>I also watched his talk on "We Really Don't Know How To Compute" last night, which was great
<paroneayea>I'm getting more and more interested in the propagators model
<paroneayea>I think I may pick up a copy of http://www.qrg.northwestern.edu/BPS/readme.html
<paroneayea>so I can understand truth maintenance systems and other AI concepts a bit better
<mark_weaver>yes, I did some reading on propagators a couple of years ago, and found it to be quite a compelling approach. so much to learn, so little time...
<paroneayea>mark_weaver: indeed
***Fuuzetsu_ is now known as Fuuzetsu
***Fuuzetsu is now known as Guest83459
***Guest83459 is now known as Fuuzetsu`
***Fuuzetsu` is now known as Fuuzetsu
<davexunit>I want to combine Sly and Guix to create a roguelike dungeon crawler titled "Dependency Hell"
<paroneayea>davexunit: haha
<amz3>I will gladly code the NPC that provides stack of parens
<davexunit>would be a fun game. the floors of the dungeon can be procedurally generated by traversing a package's dependency graph.
<efraim>how would circular dependencies be handled?
<davexunit>there are no circular dependencies in guix
<amz3>it's crossing edges that are an issue
<amz3>in 2d at least
***DeeEff_ is now known as DeeEff
<paroneayea>a writeup of the conversation davexunit and I had with sussman at FSF 30th
<paroneayea> http://dustycloud.org/blog/sussman-on-ai/
<nalaginrut>cool~
<amz3>ACTION gonna read this after watching genesis ;)
<mark_weaver>paroneayea: oooh, thanks for writing that up! fascinating :)
<paroneayea>mark_weaver: :)
<daviid>paroneayea: yes, thanks, will read later, can't wait but have to :)
<amz3>ahah it's as if you could travel the arrow of time both ways (result and explanation of the result)
<amz3>I tried to do something like that, I failed obviously
<amz3>I was calling voxel, what is called cell in propagator
<amz3>I'm forwarding that article #ai
<amz3>it might wake up someone
<amz3>Well, I fill guilty of pursing hotness, I think I should go back to the basics especially since I'm not having much fun with the algorithms (and OOP)
<amz3>I mean that I'm wondering what's the best way to go
<amz3>anyway!
<amz3>I'm going to reverse engineer the T-1000 with propagator now ;)
<nalaginrut>Cells' values are propagated from the results of other cells, but they also carry the metadata of how they achieved that result.
<nalaginrut>well...
<amz3>FWIW minikaren does this too, keeping the information of which variable is replaced by what, like in math proof...
<amz3>it use an assoc '((a b) (b c) (c 42)) which means replace 'a by 'b, 'b by 'c and eventually 'c by 42
<amz3>but here it's more complicated than the exemple minikanre i saw
<amz3>s/T-1000/genesys ;)
<nalaginrut>if we keep every step meta info in a complex system...
<nalaginrut>I wonder if it's practical in real world
<amz3>This is me just thinking out loud, but if the procedure is reversible, you don't need to store every step
<mark_weaver>the amount of metadata can always be limited or filtered somehow
<mark_weaver>but it seems important to build the system to support this kind of thing
<nalaginrut>anyway, it's possible to write a simple language (say, elementary arithmetic only) based on this model, and people don't have to write all the setter/getter
<mark_weaver>otherwise, our world will increasingly become run by machines with no accountability and no practical way of understanding why they took some actions or how to fix them.
<amz3>btw i don't know how propagator works, i just said, it makes me think
<amz3>logging is pain
<nalaginrut>mark_weaver: indeed, we just filtered useless/redundant info
<nalaginrut>but filtering seems easy for human brain
<nalaginrut>dunno if there exists efficient algorithm to eliminate all these redundant things
<nalaginrut>ACTION is considering to implement Simple language based on this model, simply
<nalaginrut>propagators as IR
<amz3>memoization is a way to save the result, i guess you already though of that
<nalaginrut>amz3: you know it'll be stateful if you store it somewhere, which could make the system complex
<amz3>I lake the words to explain in english maybe even in french
<nalaginrut>mathematicians are happy, because functional world reduced most of the complexity ;-P
<davexunit>nalaginrut: propagator networks are stateful
<davexunit>each cell has a stateless component, but the contents of a given cell are stateful.
<nalaginrut>davexunit: oh really? I thought it compute the whole cell-chain each time
<davexunit>no
<amz3>nalaginrut: math is simple for the one doing the math, CS is simple for everybody
<amz3>propagator somehow is meant to be better than math notation
<davexunit>well, computer programs in general.
<davexunit>because of the precision required to make them work
<davexunit>they can reveal ambiguities and misunderstandings
<amz3>not all programs
<nalaginrut>at least exclude non-halt programs
<nalaginrut>it reveals nothing
<amz3>no true, there is such a program: game of life :°)
<nalaginrut>alright, server is non-halt program, my bad ;-P
<paroneayea>davexunit: haha, now the HN comments roll in
<paroneayea>> This accountable argument is stone-old. You'll find it in an intro AI book. Of course only when implemented in lisp, so it needs be an older book.
<paroneayea> https://news.ycombinator.com/item?id=10388795
<paroneayea>btw, there's a propagators implementation for MIT/GNU Scheme
<paroneayea>maybe should be ported to Guile
<davexunit>yes, Scheme-Propagators
<paroneayea>well I spent most of today on that blogpost but it seems to have taken off, so I guess it was worth it
<davexunit>I told Sussman in an email that I wanted to try to write the system in Guile in order to understand how it all works
<davexunit>a Guile implementation could take better advantage of generic procedures via GOOPS
<davexunit>and use SRFI-9
<paroneayea>ACTION nods
<nalaginrut>the comment is true, symbolic AI is old story
<paroneayea>but that doesn't mean bad :)
<paroneayea>neural nets were an "old story" until a couple years ago too
<paroneayea>and now they're the new hotness
<paroneayea>same thing with most functional programming things
<davexunit>yeah functional programming is on a big upswing
<paroneayea>the AI Winter is entering a bit of a thaw stage I think
<paroneayea>but
<nalaginrut>yes, that's the point, someone think the modern methodology goes to a dead end
<davexunit>but unfortunately in the form of static, dead languages.
<paroneayea>free software has to work hard to make sure it doesn't defrost into the hands of big corporations who don't care about user freedom
<nalaginrut>well, we should say FP and GC are old story, they are
<nalaginrut>they were
<amz3>paroneayea: agreed
<nalaginrut>I think `add-content' is assignment, so yes, this model seems not functional
<davexunit>there's a functional component, and there's a stateful component
<paroneayea>sly also has a stateful component, but state is "folding over values of time"
<paroneayea>I think that's very similar to how this works out here
<davexunit>yes, Sly's FRP model is closely related to propagators, but at the same time not at all like a propagator network.
<davexunit>in addition to all the truth maintenance stuff, the graph formed by a propagator network is not an ayclic one.
<paroneayea>davexunit: yes that's true
<amz3>my though is that FRP hides non-functional behavior which make me think that non-functional has a place in programming. I'm wondering.
<davexunit>state is a necessary thing. *where* we need state is the tough question.
<davexunit>in the OOP world the answer is "everywhere" ;)
<ArneBab>gmane is back
<davexunit>functional models push state to the fringes
<davexunit>I use FRP to take a stateless function of what a game world looks like at any given time and make it stateful so that a game can actually be played.
<davexunit>paroneayea: I wish that when I got even half the upvotes you got when I posted the "art of the propagator" paper to HN.
<davexunit>"I wish that I got"* bleh
<davexunit>glad that finally something about propagators has sparked a little discussion
<nalaginrut>there're "essential states" can't be eliminated, so...
<mark_weaver>I haven't read too deeply into propagators yet, but I seem to recall that information is only added, not changed. if so, then you can view it as purely functional in a similar sense as haskell is purely functional.
<mark_weaver>i.e. you can view it as a set of immutable information, some of which has not yet been revealed.
<mark_weaver>but perhaps I'm misremembering
<paroneayea>mark_weaver: I think that's right.
<amz3>The guy behind ConceptNet agree with the article :D
<amz3>rspeer on hn
<amz3>I guess it's him
<davexunit>mark_weaver: gjs describes propagator networks as "stateless machines interconnected with stateful storage cells"
<mark_weaver>sure, it's stateful at one level, just like (non-strict) variables in haskell are stateful.
<davexunit>okay. I'm not very familiar with how Haskell works.
<mark_weaver>well, when one strips away all the optimizations, one can think of variables is haskell as containing promises in scheme, where expressions are implicitly wrapped with 'delay' and primitives automatically 'force' them.
<mark_weaver>s/is/in/
<mark_weaver>(maybe some haskell experts will correct me if I'm missing some subtlety here, which is quite possible, my knowledge of haskell is quite rusty)
<davexunit>oh sure
<davexunit>that makes sense
<davexunit>thanks for the explanation
<mark_weaver>but this restricted form of state can be thought of as stateless in the higher levels.
<davexunit>but yes, I agree that we can view the propagator network as functional
<mark_weaver>iirc, SICP talks about this in the lazy evaluation section, or maybe in the streams section (which also use promises)
<davexunit>I've read that section.
<davexunit>but I guess do not remember that particular example.
<mark_weaver>I should say, however, that I only read a little about propagators a couple of years ago, so maybe it's more stateful than I remember.
<davexunit>I view Sly's FRP system as stateless at a high level. it's erected on an imperative runtime system, but that's how you make computers do things.
<ArneBab>paroneayea: your article is a nice read — thank you for sharing it!
<nalaginrut>if it has memorization to cache some result, then it looks like lazy evaluation so much
<davexunit>civodul: I do not get a segfault on my system
<davexunit>I wonder what is going on
<nalaginrut>but I failed to find result caching in the original paper
<ArneBab>paroneayea: as criticism which is meant to be constructive: The final “have fun” part didn’t click as upbeat as I thought it was intended to be, but I don’t know why (it might just be my tiredness).
<davexunit>civodul: sorry wrong chat
<civodul>paroneayea: just read the article, it's inspiring!
<mark_weaver>nalaginrut: I don't think the word "caching" is quite appropriate in this case.
<mark_weaver>but the important point (iiuc), is that information is only added, not changed.
<paroneayea>ArneBab: I nearly added a "thanks for the chat, Sussman!" paragraph afterwards, because it kind of ended abruptly on the bullet points
<paroneayea>but then I was like "meh"
<ArneBab>:)
<paroneayea>ArneBab: civodul: glad you both generally liked it :)
<paroneayea>it's not a perfect article for sure
<paroneayea>but hey, it got #1 on Hacker News
<ArneBab>I like how you had deep tips in there
<paroneayea>despite being about scheme!
<paroneayea>well, partly about it
<ArneBab>some hints at deep understanding you found in the discussion
<paroneayea>ArneBab: the conversation definitely left me feeling I was grasping hints towards deeper undderstanding
<paroneayea>and the point of the blogpost was to record them before I forget the starting paths :)
<paroneayea>I think I've barely started on most of the trails pointed to in that chat
<ArneBab>it feels like something I had when discussing deep physics — or which I see hints of when a collegue talks about atmospheric retrievals: An understanding which goes deeper than mere techniques, something intuitive which I’ve been missing in most of my discussions with programmers.
<ArneBab>also “early expressions of these ideas are not always the best” is great in its simplicity
<ArneBab>and the notion of fun, that also goes deep
<ArneBab>paroneayea: in short: thank you!
<ArneBab>:)
<paroneayea>ArneBab: :)
<amz3>ArneBab: early pointers might helpful tho
<amz3>IMHO I always learn by relating to other stuff i know not the void
<amz3>and the literrature is quiet extensive
<amz3>I already read the paper one time it did not strike me as I not genius. The intent of propagator «making program adapt to situatiosn the programmer did not think about» is nice
<davexunit>the propagator network can deal with inconsistent worldviews, which I find very appealing.
<amz3>«and the literrature is quiet extensive» and having pointers to relate to can be helpful
<amz3>propagator can have several cell that solve the same problem in different way, and then one propagator choose the best solution somehow
<amz3>iirc
<amz3>really this is sound genius
<paroneayea>ArneBab: btw "early expressions of ideas are not always the best" is more or less an insight taken from ijp in here at some point
<paroneayea>when he said that things take a while to really clearly materialize
<paroneayea>or something
<paroneayea>I miss ijp
<paroneayea>I hope he comes back
<civodul>yeah, me too
<davexunit>and wingo
<mark_weaver>me too
<paroneayea>yeah
<ArneBab>paroneayea: res
<ArneBab>amz: yes
<ArneBab>paroneayea: yes
<ArneBab>and yes…