***amirouche1 is now known as amirouche
***amirouche is now known as amz3
<ijp>gah, I'm in box hell! <ijp>boxes inside of boxes, for no good reason1 <ijp>taylanub: the evil side of the "this code has no obvious bugs" coin *davexunit is still plugging away on his FRP implementation. <taylanub>davexunit: Are you going to post a link for what you have so far ? :P <davexunit>to have the desirable REPL interaction I've had to sacrifice all of the goodness of closures and have an uglier implementation. :( <ijp>taylanub: I'm implementing toy fp language, that compiles to combinators and does graph reduction <ijp>in order to do laziness, I need to share some nodes <davexunit>keep in mind that I use FRP sort-of loosely. <davexunit>I've seen a ton of widely different implementations of it so I'm just doing my own thing to meet guile-2d's needs. <taylanub>Ooh, that's a lot longer than what I had, will have to dig into it some time. <davexunit>taylanub: yeah it's a lot longer. I'm not happy about it, I implemented a more naive version in way less code. *taylanub saves this for later, doesn't have the brains right now. <davexunit>my big problem is that I want to be able to replace nodes in the signal graph. <davexunit>to do so requires quite a bit more complexity. <ijp>interesting that we are both complaining about similar problems <davexunit>I was trying to see if I could use (abuse?) macros to solve this <davexunit>yesterday I wrote a fresh implementation based on the circuit programming system from SICP <davexunit>it took very few lines of code and was quite nice, but of course was subject to the same problems as before. <ijp>I think my problem can be solved by doubling the amount of code I have :) <davexunit>things *seem* to work, at least the basic cases that I've tested. I imagine there's some number of edge cases where the logic doesn't work out quite right. <davexunit>but I'm not too happy with the code as it stands. <ijp>basically, I need to special case what happens at the very "top" of my graph <davexunit>I had an additional problem, I could have a top-level signal "foo", and then create a signal "bar" that used it. <davexunit>so re-defining "foo" needs to change "bar" and the signals that are used as inputs to "foo" <ijp>actually, if I add a dummy node, I can get rid of the special case <ijp>code-doubling avoided! <ijp>my graph is a really tree with some branches glued together <ijp>and in order to replace a node, I update the slot in the parent <ijp>so by making a fake parent at the top, I can handdle this just fine <davexunit>and right I'm using a doubly linked structure. <ijp>mine is not doubly linked <davexunit>mine is doubly linked so that I can replace a node in an arbitrary place in the tree. I didn't see a way around it. <amz3>what is graph reduction? <ijp>amz3: you take a graph, and you merge nodes together <amz3>I have a passion for graph <amz3>I just sent a mail to gnu system regarding this topic, maybe I should have included guile in the cc field <amz3>I mean the topic of graph <davexunit>ijp: is your source code available anywhere? <ijp>I'm liable to rewrite this thing another 4 times before I get it right <davexunit>I keep hoping that I can use weak references or something and let the GC do the work for me, but it never works out right. <ijp>cthulhu be praised, I may have managed it <ijp>though there is a better than even chance I've made it less lazy in the process <ijp>okay, so I think I may need two sets of boxes <ijp>no, I don't think it is <ijp>the idea was, you have a box representing the expression, and then sharing only involves pointing to the same box <ijp>I close emacs, and go watch buffy <davexunit>I am folding laundry and watching that hunger games movie right now. <davexunit>contemplating if I should just say "fuck it" to some of my goals. <ijp>damn, no davexunit here to share in my joy <ijp>madsy: 4 hours of making the same mistake over and over and over again <madsy>ijp: Ouch. You have my sympathy. <ijp>madsy: if you look in that gist, you will see two lines commented out <ijp>those are the lines are the mistake I kept on making <madsy>It feels good when it finally works though, right? <ijp>yes, I can finally watch buffy in peace <madsy>I haven't coded in a while. Maybe I should spend the day tomorrow on something *ijp rips up large pointer chasing diagrams and bins them <madsy>Stupid family gathering taking up my whole christmas vacation time <nalaginrut>speaking 'match', is there anything alternative of 'expr' in Racket? <madsy>I miss a good schematic capture tool for Linux. It would be interesting to make one using guile and gtk <ijp>nalaginrut: expr just denotes an expression in their pseudo-grammar <ijp>(match 9 ((= sqrt x) (list x))) => (3) <nalaginrut>alright, I think it's unrecorded in Guile manual <ijp>it says "a ``field'' of an object" <ijp>which is not a great description, even with the scarequotes <nalaginrut>ok, I think there is, but I thought 'field' imply the fields of record-type <ijp>you kind of need to read between the lines <ijp>oh wow, that mudkips thing is over 5 years old now <ijp>I remember because I bought a mudkip plushie to celebrate my 18th <ijp>taylanub: yes, but the prefix is very similar <zacts>I think I'll check out that guile game library. I figure that making games is a great way to learn comp sci concepts.. <zxq9>zacts: ooc, what game library are you talking about? <guest`>why this code '(set! +(let((original+ +))(lambda args(apply original+ args))))(display(+ 1 2 3))' works with 'guile -c' but in an interactive session it awaits for more input (like mismatched parenthesis)? <davexunit>guest`: + is a primitive procedure, so redefining it like could cause some real strange things to happen. <sneek>davexunit, you have 1 message. <davexunit>someone that knows more about this stuff could give you more detail. I couldn't tell you an exact reason. <davexunit>they managed to greatly change their GC architecture without having to change any C extensions. <davexunit>which, from what I've heard in the past about Guile's C core, wouldn't be the case if Guile's GC architecture was changed. <davexunit>guest`: yeah, I think this discussion has come up before. <davexunit>if you stick around, someone will probably be around to answer this properly sometime today. ***ijp is now known as GNU-ijp
***GNU-ijp is now known as ijp
<taylanub>guest`: To allow a function to be re-defined post-hoc, we would need to refrain from doing certain optimizations while compiling code that uses it. <taylanub>guest`: For some procedures that are expected to be fast, like simple arithmetic, vector referencing, etc., the procedure-dispatch overhead is nasty, so they're optimized (inlined), but this means that redefining them later has no effect on code that was already compiled. <dsmith-work>civodul: I'm curious what you needed to do to get guile-wm working. <civodul>dsmith-work: i don't know, it failed with Xnest <civodul>i'd need to try with Xephyr or a real server <guest`>taylanub: so compiling/inlining of 'guile -c' and interactive sessions are different? <taylanub>guest`: I think the REPL also compiles every line you give it but I keep forgetting the details. <taylanub>scheme@(guile-user)> (define (add x y) (+ x y)) <ijp>repeat over and over to yourself until it becomes second nature: the repl is special, the repl is special, the repl is special, .... <taylanub>So does the REPL use the interpreter (the one written in Scheme) or not ?.. <taylanub>Aha, but that compiles before executing ? <guest`>so with this code: "(define (factorial a)(if(= a 0)1(* a(factorial(- a 1)))))(display(factorial 10000))" I see the behaviour of "guile -c 'code'" is like "guile --no-auto-compile script" and "guile<<<'code'" is like "guile script" <davexunit>a lot of changes coming... eventually. bye-bye actions module and the existing scene system. <davexunit>and hello to FRP and a redesigned scene system that takes advantage of guile's parameters (hopefully) *taylanub should move over to Gitorious. What's the reason Gitorious is preferred by free-software enthusiasts again, though ? <zacts>apparently it only responds to food. *sneek gives zacts the raspberry *zacts would rather eat a beagle bone, for free software reasons <davexunit>github is nonfree software. github is built on free software, but that freedom never reaches its users. <ijp>davexunit: hows your graph thing coming along? <davexunit>dsmith-work: I'm sure there's something out there. <davexunit>but it's basic free software stuff: Service as a Software Substitue, The JavaScript Trap, etc. <muep>gitorious is a service on someone else's computer, too <davexunit>muep: the difference is that the software is AGPL. <muep>my impression was that SaaSS is considered unethical by the FSF, regardless of what license is used for the software that provides the service <davexunit>you could run your own gitorious server if you want with no restriction. <ijp>davexunit: what operations do you need on your graph? <muep>because the user can not really control what the software that implements the service does, while she could do that if she used a software running on her computer for the same task <taylanub>Can I somehow just push existing repos to Gitorious ? <muep>OTOH I do not think github is entirely SaaSS, since you really need a service instead of just a piece of software, in order to host a public source repository <muep>taylanub: yes, just create a new empty repository and then git remote add its URL and then git push there <taylanub>But I have to manually create a "project" via the web interface for each repo, right ? <davexunit>ijp: I made an implementation where I can replace arbitrary elements of the graph, but I'm not happy with the code. <muep>they might have some machine-friendly interface for setting up new repos, but I have no idea if they really do <davexunit>muep: I guess you're right, it is partly SaaS though. <davexunit>and it has all the lock-in typical of proprietary software. <davexunit>github has such recognition that it's sort of hard to leave it. your repos will be viewed less, for example. <muep>what lock-in do they have that gitorious does not have? <davexunit>there's lock in if you depend on: their pull requests, their releases, their wiki, their issue tracker, etc. <davexunit>if you're just hosting source code then there isn't much. <muep>if your users get accustomed to finding your project on gitorious, it too locks you into using their service instead of e.g. a home-grown one <ijp>davexunit: pointer to the code? <muep>though in both cases, it is pretty easy to remove all the code and leave a README that points to the current project site <davexunit>github locks you into a workflow, if you choose to use those features. <muep>I agree that the pull requests and the issue tracker may be problematic if your work really depends on them <davexunit>some people even use github clients are their computers. <davexunit>the company I work for is dependent on the pull requests part. before I arrived they used to use gitorious, too. :( <muep>my impression is that linux was temporarily hosted on github while kernel.org was down. but they did not end up dependent on the features that are exclusive to github <davexunit>muep: because they only used the source code hosting bit. <davexunit>which is easily replaceable because git is free software. <ijp>the issue tracker is more problematic than PR <ijp>fossil had the bright idea of packaging it with the repo, but that's about all I know of it <davexunit>PRs are easy enough to replace with gitorious merge requests, though some might not want to part with the comment history? <muep>I'd guess github allows exporting the issue database of a project, but not sure <davexunit>but I don't think it's good to keep supporting them the way I have been. <davexunit>I think they are doing some harm culturally. <muep>I think it is a nice service, even if they offer features that I think are better served with free software <ijp>davexunit: the reasons for the two layers of boxes in my code is pretty simple <ijp>the first box means that you don't have to maintain an incoming list <ijp>every "parent" points to the box, and so you only need to make one update <ijp>the second one was to allow the value itself to be shared <davexunit>I thought of a case that may prove problematic though: chains of signals. <davexunit>maybe that's where your graph reduction comes in? <davexunit>I could have bar connected to foo, but goes through baz to get there. <muep>at least bitbucket allows exporting the issue tracker <ijp>so merging two nodes really becomes sharing of a value in my version <mark_weaver>here's an idea: when you reference these replaceable top-level signals, you want the reference to be not to the signal itself, but to the variable. <ijp>mark_weaver: yes, exactly <muep>I am pretty much stuck with using some issue tracker service for my small projects, because it is a bit overkill to maintain a bugzilla instance or suchlike for the simple projects I have <mark_weaver>and you do that by making a little lambda expression: (lambda () <var>) <mark_weaver>the procedure resulting from that lambda expression will have a pointer to the variable object, and will query it each time. <mark_weaver>if the variable is redefined, it will pick up the new one. <davexunit>I think the other problem I brought up still remains though? a top-level signal at the end of a chain. you can build a new chain with the top-level signal, but the old chain remains, perhaps minus the head node. <mark_weaver>the references to downstream signals (i.e. the ones that we have to push changes to) should be weak pointers. <mark_weaver>and there should be pointers upstream that are not weak. <mark_weaver>or at least I think there should be. I'm typing as it comes to me. <mark_weaver>so if you arrange things correctly, I think the GC should just get rid of the obsolete stuff. <mark_weaver>basically, it should be the most downstream signals that keep everything else alive. <mark_weaver>you should only keep pointers to the most downstream stuff, i.e. where the user sees them, or sees the effects of them. <mark_weaver>and then, that downstream stuff will keep the inputs that they need alive as well. <mark_weaver>when you replace something in the middle, you need to refer to the inputs as part of the definition of your signal. <mark_weaver>things should be arrange so that the old inputs (if they were different from the new inputs) will just die if not used by anything anymore. <mark_weaver>the references to inputs will be stored as procedures that return the input signal. <mark_weaver>which will allow them to reference variable objects anywhere in the system. <mark_weaver>(toplevel module variables or internal variables, lambda handles them both) <davexunit>and a little macro would free the user from having to type (lambda () foo-signal) a bunch. <mark_weaver>you could make a little macro that's used to reference signal variables: (define-syntax-rule (^^ v) (lambda () v)) <ijp>like streams, you're going to end up with a bunch of unavoidable extra syntax forms <davexunit>streams were one of the inspirations for my desired API. <davexunit>nice to get input from both of you. greatly appreciated. <mark_weaver>glad to help! guile-2d is a very interesting project :) <davexunit>if I can get the FRP stuff in working order now, I can move around to playing with parameters to replace my existing scene system that I hate. <mark_weaver>davexunit: btw, I haven't forgotten about the REPL thing; I hope to get something into 2.0.10 that does what you need. I'm actually leaning toward making something that handles this use case directly, rather than by offering a generic read wrapper. <davexunit>mark_weaver: oh cool. I was going to mail the list about it again. :) <mark_weaver>to be more specific, I was thinking about providing a mechanism to create a REPL that will be created and periodically run within one thread, but which handles user input via another thread. <mark_weaver>so from the user's point of view, you'd create a REPL object within your main thread, and then periodically you'd call something that would run any pending REPL commands that had been typed by the user. <mark_weaver>hmm, mvars, that's a good question. I'd like to get those in too, but I'll have to look back at that old ML thread and refresh my memory of what wingo and civodul thought. <mark_weaver>but at least mvars is something that can be reasonably included in your own code if need be. <davexunit>I thought it was approved of. mvars would surely come in handy for this REPL, right? <davexunit>I just figured that you might want to take advantage of them in your implementation. <mark_weaver>oh, I remember, they wanted to give mvars a different name, or something. <guest`>muep,davexunit: "The original idea of web servers wasn't to do computing for you, it was to publish information for you to access. Even today this is what most web sites do, and it doesn't pose the SaaSS problem, because accessing someone's published information isn't doing your own computing." "Repository sites" ... "are not inherently SaaSS, because a repository's job is publication of data supplied to it." <mark_weaver>if the library is named (foo bar), then put it in $DIR/foo/bar.scm where $DIR is a component of your $GUILE_LOAD_PATH <mark_weaver>look in %load-path to see the default paths for your installation. you can add personal directories by setting GUILE_LOAD_PATH <ijp>davexunit: how do evaluate this signal graph? <ijp>like, actually run it <ijp>ah, I suppose you set! the root