IRC channel logs

2016-02-04.log

back to list of logs

<wilo_>:)
***dje is now known as xdje
***Administrator is now known as Guest28718
<paroneayea>ArneBab_: yo!
<paroneayea>so I just met the Parinfer main guy
<paroneayea>I was at dinner, there was someone new at Stripe, talking about Clojure, and how they feel like lisps are under-recognized
<paroneayea>and I was like "Have you heard of Parinfer?"
<paroneayea>him: "I wrote Parinfer"
<paroneayea>me: "Oh shiiiiit"
<paroneayea>and then I showed him some stuff in emacs, which apparently may help with an emacs port
<paroneayea>and I also showed him Wisp! and he agreed it was more or less the same idea
<ArneBab_>paroneayea: cool!
<ArneBab_>paroneayea: from the parinfer site: “unbalanced quotes in comments” ← that was a major pain in my pure preprocessor versions of wisp.
<ArneBab_> https://shaunlebron.github.io/parinfer/#inserting-quotes
***Administrator is now known as Guest50957
<brrt>ohhai #guile
<brrt>i'm wondering if people here are familiar with the problem of global register allocation and the implications for correctness
<brrt>answer, probably, yes
<brrt>i find that this is by far the hardest bit to wrap my head around
<wleslie>if you run into trouble you can always spill
<brrt>thing is, i had a representation that didn't properly consider basic blocks
<brrt>without basic blocks, this is impossible
<brrt>not to mention what happens when a function call is wildly inserted in the middle
<wingo>global meaning in a whole procedure?
<wingo>here is a way to do it: http://www.christianwimmer.at/Publications/Wimmer10a/Wimmer10a.pdf
<wingo>that's on ssa; you can do it without ssa based on the original linear scan paper
<wingo>the key idea is to compute "liveness ranges" on all your variables. if you fail to find a good allocation, you split the liveness ranges by introducing spills.
<wingo>around a function all callee-saves get spilled.
<brrt>yes, whole-procedure :-)
<brrt>that is amazingly similar to what i had cooked up
<wingo>there are a few more techniques. appel in his ML compiler book gives an implementation that does graph coloring. you can also try the puzzle-solving technique: http://compilers.cs.ucla.edu/fernando/projects/puzzles/intro/
<brrt>my IR is SSA :-)
<wingo>cool
<brrt>yeah, never realized it before actually
<brrt>but each node computes a single value, and the name-of-the-value is simply the number-of-the-node
<wingo>the tricky problem in linear scan is live range splitting.
<wingo>neat
<brrt>i had tried to implement it as an online algorithm, and that doesn't correctly do live-range-splitting
<brrt>much pain resulted
<brrt>anyway, thanks for those papers :-) i'm going to lunch now
<brrt>one thing i'm puzzling over is how to add constraints, e.g. preferably put a variable that will go into a function call argument into the right register in the first place
<wingo>i don't know how to do that with linear scan. maybe the wimmer or sarkar papers cover it
<wingo>with graph coloring it's called "pre-coloring"
<wingo>with puzzle solving the paper shows some examples
<amz3>héllo #guile :)
<amz3>has anyone had a look at ijp's javascript backend?
<amz3>I have no particular question, just asking whether someone made some progress
<nalaginrut>amz3: I'm waiting for the status too
<amz3>last time I checked the code, it was building buggy code
<amz3>non-runnable code
<amz3>I wondering whether it will roll for another GSOC or not
<amz3>...
<amz3>sneek: help
<amz3>later tell davexunit, you might be interested by this commit about FRP papers https://github.com/joaomilho/papers-we-love/commit/f8991ba514942b4ab5db16c7982ae9f87805e81f
<amz3>sneek: later tell davexunit, you might be interested by this commit about FRP papers https://github.com/joaomilho/papers-we-love/commit/f8991ba514942b4ab5db16c7982ae9f87805e81f
<sneek>Okay.
***_zxq9_ is now known as zxq9
<brrt>wingo: thanks, i'll check it out
<brrt>i was thinking of adding constraint nodes in some sense
***amz31 is now known as amz3`
***amz3` is now known as amz3
<amz3>huh, the most popular post on my blog is about guile-log parser combinator!
<amz3>I'm afraid to read it tho
<amz3>;)
<amz3>the second most popular is about how to build graph based recommendations, which I should port some time to scheme..
<amz3>and the third is a silly post about how to build an AI x)
<amz3> http://hypermove.net/notes/do-it-yourself-an-artificial-intelligence/
<brrt`>azm3: i disagree that AI is about equations :-)
<amz3>what is it about then brrt` ?
***brrt` is now known as brrt
<brrt>well, in general, computation is not about equations
<brrt>computation is about mechanism
<brrt>hence, AI is about finding (the|a) mechanism behind certain cognitive functions, particularly, useful cognitive functions
<brrt>i'm talking about weak AI, of course
<amz3>logic doesn't count as equation?
<brrt>i think logic is about projection
<amz3>hmm, computation is about mechanism, but aren't mecanism about equations?
<brrt>no, equations are a very limited thing
<brrt>:-)
<brrt>that's what i think, at least
<amz3>lambda calculus is limited then ?
<brrt>lambda calculus is not about equations
<peterbrett_work>Does anyone have a example of using SRFI-41 streams in a practical application that I can look at?
<amz3>really?
<peterbrett_work>They look really cool, but I can't work out what they're *for*
<brrt>but about evaluation, which is a procedure, hence a mechnaism
<amz3>peterbrett_work: they are lazy streams, like generators in python
<brrt>not that i know all about lambda calculus, not at all, though
<peterbrett_work>amz3: Oh - so you use them like coroutines?
<amz3>peterbrett_work: coroutine, is a way to implement lazy streams
<peterbrett_work>Uh, okay
<peterbrett_work>That still doesn't help me figure out an idiomatic way to use them :) Have you written any programs that use them?
<davexunit>peterbrett_work: not exactly a "practical" example, but here is a short example of how I've used them to represent infinite series: https://git.dthompson.us/project-euler.git/blob/HEAD:/problem-2.scm
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, amz3 says: you might be interested by this commit about FRP papers https://github.com/joaomilho/papers-we-love/commit/f8991ba514942b4ab5db16c7982ae9f87805e81f
<davexunit>amz3: thanks!
<amz3>yes, I wrote a stream of json objects for instance for a several a file of several Go
<peterbrett_work>davexunit: Thanks
<amz3>I look the source code
<peterbrett_work>amz3: Thank you, too :)
<amz3>I don't find the code :/ but basically, where you would use a simple generator in python,you can use streams in scheme
<amz3>basicaly you delay the evaluation/computation of a list because it's too big or infinite
<amz3>I use like I said to iterate over a big json file, but also to iterate over database entries
<peterbrett_work>Is there something that's similar but based on asyncs?
<amz3>the stream spits associations instead of strings
<amz3>peterbrett_work: async/await?
<davexunit>no.
<davexunit>streams satisfy a different use-case.
<peterbrett_work>Okay, thank you
<peterbrett_work>That sort of solves some of my confusion
<davexunit>coroutines are different and pretty trivial to implement yourself in guile.
<amz3>in python generators are confusing the situations because they are used to implement lazy streams but there is alternative implementations in scheme
<peterbrett_work>I meant for operating on sequences of things that are simultaneously being computed elsewhere
<peterbrett_work>(e.g. on another thread)
<peterbrett_work>Only blocking when required
<davexunit>sounds like a stream to me.
<davexunit>but not really.
<peterbrett_work>So - a stream of asyncs?
<davexunit>I dunno.
<peterbrett_work>Yes, I have an application for such a thing :)
<davexunit>if you want multi-threaded computation, use par-map
<davexunit>or par-for-each
<davexunit>or roll your own, probably not too hard since you know what you want.
<peterbrett_work>Hah, I'm still working on knowing *exactly* what I want :)
<peterbrett_work>Here's an example of what I'm trying to do
<peterbrett_work>I have a file, which I'm loading. The file contains references to other files, that I want to load
<peterbrett_work>While loading the file, I'd like to start loading the dependencies in other threads, but not return the file result structure until all the dependencies have been loaded
<peterbrett_work>And I'd like to not load any dependency more than once, even if it's used multiple times
<davexunit>sounds like a job for par-map
<peterbrett_work>Apart from the deduplicating, I guess
<davexunit>(par-map whatever (delete-duplicates deps))
<peterbrett_work>And there's the problem of dependencies that are reachable by multiple paths: if I have A->B and A->C->B, I only want to load B once
<davexunit>compute the set of dependencies first
<davexunit>then load them in parallel
<davexunit>or memoize the loading procedure
<peterbrett_work>But I can't compute the complete set of dependencies without loading the complete set of dependencies… so I have to be able to do extend the dependency graph incrementally :)
<peterbrett_work>(non-DAG is an error)
<davexunit>okay, so memoization should work.
<davexunit>it won't compute branches that have already been computed.
<davexunit>I'm assuming that you are programming in a purely functional style here.
<peterbrett_work>Ideally, yes
<davexunit>par-map and memoization only make sense if the procedures you work with are referentially transparent
<davexunit>otherwise, good luck.
<peterbrett_work>Let's assume that they are
<peterbrett_work>(or I can replace them with procedures that are)
<mark_weaver>peterbrett_work: note that our module system is not thread safe, unfortunately. creating new modules in multiple threads concurrently is not safe, nor is adding new bindings to a given module in more than one thread.
<mark_weaver>terrible, I know.
<peterbrett_work>mark_weaver: Let's assume that I'm loading data files, not Scheme modules
<davexunit>I was under the impression that these "dependencies" were not guile modules, but something in his own program.
<peterbrett_work>Yes, that's right
<mark_weaver>peterbrett_work: okay, that should be fine
<peterbrett_work>(loader-load "foo.dat")
<mark_weaver>so, using 'read', not 'load'.
<peterbrett_work>Uh, yes
<mark_weaver>or your own reader
<mark_weaver>okay, that's fine.
<peterbrett_work>Sorry, my terminology is clearly confusing
<davexunit>if you memoize loader-load, calling (loader-load "foo.dat") twice will return the same object
<mark_weaver>carry on :)
<peterbrett_work>Let's call it "read" then :)
<amz3>load is procedure in scheme
<davexunit>where "same" means eq?
<peterbrett_work>Yes, sounds ideal
<peterbrett_work>Is there an example of a functional memoized function? That seems tautological (but I'm sure it's not)
<davexunit>(par-map (memoize load-the-thing) stuff)
<davexunit>though, this actually gets a bit more complicated
<davexunit>because now you need to use a thread-safe data structure to do the memoization
<peterbrett_work>I assume this is "where memoize is a complicated function that peterbrett needs to define ;-) )
<davexunit>peterbrett_work: the typical way is to use a hash-table to cache results in.
<davexunit>the hash table maps argument lists to return values
<davexunit>if the argument list is in the hash table, return the cached value
<peterbrett_work>Okay, so mutable global state is actually required
<peterbrett_work>fair enough
<davexunit>not global
<mark_weaver>you'll need to protect the hash table with a mutex in that case
<davexunit>yes
<davexunit>peterbrett_work: here's a thread unsafe memoize procedure: http://git.savannah.gnu.org/cgit/guix.git/tree/guix/utils.scm#n398
<mark_weaver>and mind the difference between eq? and eqv? and equal?
<mark_weaver>(or maybe you need to roll your own)
<davexunit>tweak as needed for your use-case.
<mark_weaver>I have to go afk for a while...
<davexunit>at the very least you'll need a mutex to protect the hash table.
<peterbrett_work>Cool, thanks. That's neat :)
<amz3>soon enough, there will be STM in Guile and you won't bother :o)
<davexunit>I haven't heard of any plans for STM.
<amz3>;)
<civodul>STM is for imperative programming
<wingo>you could use a promise as a threadsafe memoization :)
<mark_weaver>wingo: note that only legacy Guile promises have built-in thread synchronization. SRFI-45 promises do not.
<wingo>ack
<peterbrett_work>ACTION was reading SRFI-45 and getting confused
<peterbrett_work>Not a complaint, but an observation: I quite often get, "You can use <X:thing> to solve <Y:problem>!" but often have trouble getting from X to Y. I suspect that's my problem for being slow on the uptake though
<brrt>what, why have promises if not to have synchronization :-o
<davexunit>brrt: promises are for lazy evaluation.
<davexunit>the word "promise" has different meanings depending on which programming language community you are talking to. in Scheme, a promise means "I promise to evaluate this expression later when someone asks me to"
<davexunit>as opposed to the now more commonly known "promise" popularized by JavaScript.
<wingo><mark_weaver> wingo: note that only legacy Guile promises have built-in thread synchronizatio
<wingo>er
<wingo>not what i meant to paste :)
<wingo> https://webkit.org/docs/b3/
<wingo>neat stuff
<davexunit>neat
<mark_weaver>my sparc server, where I run my irc client, died immediately after I wrote that SRFI-45 promises are not thread safe. I missed anything after that.
<mark_weaver>and the gnunet logs don't seem to have any of that either
<davexunit>not much happened
<mark_weaver>okay, thanks
<davexunit>wingo posted something JIT related in WebKit that he thought was neat: https://webkit.org/docs/b3/
<mark_weaver>davexunit: thank you!
<civodul>mark_weaver: sparc64, like an ultrasparc?
<mark_weaver>civodul: yes, TI UltraSparc IIe (Hummingbird), in a Netra T1
<mark_weaver>running Debian
<civodul>cool
<civodul>i have an Ultrasparc III
<mark_weaver>it crashes a fair bit because Linux (the kernel) has some bugs that cause unaligned memory accesses, and I guess no one notices anymore since most Linux users are on platforms that handle unaligned accesses gracefully.
<mark_weaver>civodul: ah, nice!
<civodul>yeah, plus sparc support is lacking
<mark_weaver>I fixed one of the bugs many years ago and it was accepted upstream, but lately I don't have time.
<civodul>in the kernel and libc
<mark_weaver>and I'm about to switch to a new AMD-based box running Libreboot anyway.
<mark_weaver>it's too bad, because the hardware seems quite robust and well designed. I have much more confidence in it than X86, but our software doesn't support it well.
<mark_weaver>I'm dismayed by how unreliable our systems have become in recent years.
<mark_weaver>(not to mention undocumented and backdoored)
<civodul>heh
<peterbrett_work>This is probably a silly question, but how do implementations of particular SRFIs end up in Guile?
<peterbrett_work>I mean — Guile is supposed to be "batteries not included", but some SRFIs look superficially like batteries
<ehiggs>i thought arm doesn't like unaligned accesses. it's only intel that doesn't mind them
<sneek>Welcome back ehiggs, you have 1 message.
<sneek>ehiggs, fps says: it was just the first google hit ;)
<peterbrett_work>So how do you decide which ones to put in?
<wingo>is guile supposed to be batteries not included?
<civodul>i don't think so
<mark_weaver>yeah, that's news to me :)
<peterbrett_work>wingo: Well — that's how it's been explained to me over the last 10 years I've been using it
<wingo>hmm :)
<civodul>by whom? :-)
<peterbrett_work>"Why don't you have a JSON parser?" "Why don't you have a CSV library?" etc.
<wingo>those srfis have been there the last 10 years too :)
<mark_weaver>granted, we don't have nearly as many batteries as some other systems, but that's not our goal.
<wingo>i think we will have a json parser at some point fwiw
<civodul>JSON did not exist 10 years ago, so it doesn't count ;-)
<peterbrett_work>It's not a difficult format to parse :)
<mark_weaver>there's a JSON parser under review, waiting for a revision by the submitter.
<wingo>haha, neither is any particular form of csv. but csv in general is hard :)
<mark_weaver>*cough* davexunit *cough* :)
<mark_weaver>peterbrett_work: anyway, to answer your original question: SRFI implementations are added to Guile when someone does the work and proposes a patch :)
<mark_weaver>is there a particular SRFI you have in mind?
<peterbrett_work>Okay, so there's not a sort of strict set of criteria used to decide whether something belongs in the Guile tarball
<peterbrett_work>No, just generally curious
<peterbrett_work>:)
<peterbrett_work>For the sake of argument: SRFI-44 :P
<mark_weaver>SRFI-115 is on my TODO list, but I don't want to just use the reference implementation. I want it to be efficient.
<taylan>peterbrett_work: some SRFIs catch up in the community more than others. I think 44 is one of the less popular ones. at least, I barely ever hear of it.
<mark_weaver>peterbrett_work: so, SRFI-44 doesn't seem to have much uptake. According to http://srfi.schemers.org/srfi-implementers.html, there are *no* scheme implementations that support it.
<taylan>heh
<peterbrett_work>:-)
<mark_weaver>that's the thing about SRFIs: anyone can make one, and finalize it, without a single other person agreeing that it's good.
<brrt>davexunit: aha. in perl6 land, they represent a concurrency thing too
<mark_weaver>which is great. I like that process.
<mark_weaver>the ones that are good are adopted, and the junk is left alone.
<brrt>which is, when you think of it, completely oppossite to a lazy value
<peterbrett_work>From the point of view of someone embedding Guile, I feel like I can't accept plugins that use libraries not included in the main Guile distribution, because I feel bad about bundling 3rd party libraries and I want to keep the dependency list under control
<taylan>by the way once Guile has R7RS support, some from https://github.com/TaylanUB/scheme-srfis could be added to upstream. mostly just library wrappers around reference/sample implementations though.
<mark_weaver>taylan: wow, there are a lot of them in there!
<peterbrett_work>Yes, very impressive!
<taylan>:) very few test suites sadly
<nalaginrut>ACTION rewrite session management, maybe add redis as session backend too
***_zxq9_ is now known as zxq9
<nalaginrut>hmm...guile-redis is too large to integrate
<amz3>ACTION has NIH regarding this subject ;)
<nalaginrut>now session management is flexible enough to let users define their own session backend, so maybe just let users do redis one as plugin
<amz3>hey, I managed to write something for wiredtiger, prose style documentation
<amz3> http://hypermove.net/notes/getting-started-with-guile-wiredtiger/
<amz3>I started this because I was not very confident with the API, tho it's simple
<amz3>not confident anymore since I did not hack on this for some time
<amz3>I still recommend using wiredtigerz module but this only explain the wiredtiger primitives
<amz3>well, wiretigerz is not enough it simplify some usecases
<amz3>wiredigerz.scm is a module beside wiredtiger.scm in the repository
<amz3>along some .md files
<davexunit>nalaginrut: guile-redis needs a rewrite.
<davexunit>I looked at it, and everything is macros.
<davexunit>which is unfortunate.
<davexunit>mark_weaver: I know, I have to stop being lazy and address your comments about the json reader/writer
<davexunit>paroneayea has expressed additional concerns about the chosen s-expression format
<davexunit>so I need to keep that in mind, too.
<nalaginrut>seems we can't see redis session backend in 0.1.2, and if I provide plugin way for users, I have to start to design package management for these plugins
<nalaginrut>I prefer delay package manager to 0.3.x
<davexunit>a package manager *just* for your web framework?
<nalaginrut>davexunit: we have to manage the plugins, because I can't implement all things and integrate into the framework
<nalaginrut>if I provide plugin mechanism, I have to provide its manager
<amz3>davexunit: +1
<paroneayea>davexunit: wingo gave a pretty strong response that we can afford the extra cons by going non-alists in this day and age of computing while we were at FOSDEM, if that additional view helps :)
<nalaginrut>amz3: +1 for what? I failed to see previous discussion because of the network
<davexunit>paroneayea: what do you mean by "extra cons"?
<amz3>nalaginrut: for the concern related to the package manager
<nalaginrut>are you afraid of the package manager? ;-)
<paroneayea>davexunit: '((key1 . val1)) vs '((key1 val1))
<paroneayea>consing on the '()
<davexunit>paroneayea: okay, I get it now.
<paroneayea>davexunit: as I've said before, the headache I get is where val1 is like
<paroneayea>'(some list of items)
<paroneayea>and then I see ((key1 some list of items))
<davexunit>the problem there is that it's now inconvenient to lookup a value based on a key
<paroneayea>which is worse if there's even more nested items
<paroneayea>davexunit: because you can't use assoc?
<paroneayea>writing the equivalent assoc method is pretty easy..
<davexunit>assoc, assq-ref, assoc-ref, etc.
<davexunit>there are lots of procedures that operate on conventional alists
<davexunit>in guile and elsewhere.
<amz3>nalaginrut: no... yes... maybe... it depends actually on the kind of package manager
<paroneayea>I don't think it's very hard to add the equivalents
<paroneayea>and anyway!
<paroneayea>sxml already does this
<davexunit>so, I agree that the extra cons looks better.
<paroneayea>sxml is also (@ (key1 val1))
<paroneayea>so it's not a stretch for us to do it too with (ice-9 json)
<davexunit>paroneayea: the problem there is that you typically *don't* do lookups
<paroneayea>davexunit: one other argument could be
<paroneayea>we could provide a (json-pp) method
<paroneayea>which actually does rewrite things a little
<paroneayea>before it pretty prints
<paroneayea>I would be okay with that route too
<paroneayea>since it's only for human reading that it's difficult
<amz3>nalaginrut: I'm wondering whether the monolitic nature of artanis is not an impediment and why not addressing each problem separatly is not a better solution.
<amz3>nalaginrut: again this is your project and you have the vision and you adress it as you like :)
<nalaginrut>amz3: but I need to collect more information and feedback
<amz3>nalaginrut: well, I'm not sure, I lake exp.
<amz3>nalaginrut: you need feedback on what ?
<nalaginrut>amz3: if we have good plugin mechanism and pkg manager, we may split its modules, and not a monolithic anymore
<nalaginrut>I mean the specific feedback for the plan of pkg manager
<amz3>nalaginrut: wait for it, but I think having a pkg manager similar to... nodejs might a good thing... but which doesn't break current way of making modules in Guile
<nalaginrut>anyway, I'm considering a Artanis specific pkg manager, not a generic one
<davexunit>paroneayea: I need to think about it some more. it's additional complexity, and alists are extremely prevalent. I'd like to get the maintainers' opinion on the subject.
<paroneayea>davexunit: so, in the case of moving away from alists is not welcome
<nalaginrut>so far, I don't see any possible to break modules in Guile, and other pkg manager of Guile
<paroneayea>would you support adding (json-pp)?
<paroneayea>er
<paroneayea>would you support adding (sjson-pp)?
<davexunit>paroneayea: would that procedure produce pretty-printed JSON-formatted output?
<amz3>nalaginrut: my idea, is to have a package manager that install dependencies in the source tree "as is", *not* in a separate location loaded via GUILE_LOAD_PATH
<paroneayea>davexunit: oh, yeah well we could do that too, in that case I was talking about pretty printed s-expressions with the alists rewritten :)
<paroneayea>davexunit: but!
<amz3>nalaginrut: not sure what problem this brings
<paroneayea>I do have a kinda-working json pretty printer
<paroneayea>with actual json syntax
<nalaginrut>amz3: it's not a good solution
<amz3>nalaginrut: why?
<davexunit>paroneayea: I'm in favor of a JSON pretty printer, but not an sexp pretty printer in addition to what is already in (ice-9 pretty-print)
<paroneayea>davexunit: ok!
<nalaginrut>amz3: because people need to install the packages locally, this won't effect global things
<paroneayea>davexunit: so I kind of have one
<davexunit>cool!
<amz3>nalaginrut: yes, you install dependencies for each project in the same source tree as the project
<davexunit>I'd like to implement it as a generalization to the existing printer
<davexunit>with a pretty? flag.
<paroneayea>davexunit: well that's what I did
<davexunit>great
<paroneayea>davexunit: let me pull up the code so you can look for yourself
<nalaginrut>so my pkg manager is most for local installation within application folder
<nalaginrut>I even don't care about the global installation
<amz3>so do i
<amz3>but if we agree on this, explain what's specific to artanis?
<nalaginrut>I think this is the second different feature from other pkg manager
<nalaginrut>amz3: for Artanis specific plugins, an API checking may need in pkg manager, and proper version control
<nalaginrut>it's unnecessary for guildhall or guix
<amz3>nalaginrut: offtopic, kindof, do you know if it's possible to do management only with coookies without storing session information server side
<davexunit>nalaginrut: the question I have is: what makes artanis plugins anything more than just a set of guile modules?
<nalaginrut>but I have to say, my pkg manager also support non-Artanis packages
<amz3>nalaginrut: sorry, to authentificate a user without session informations stored server side
<nalaginrut>davexunit: Artanis has its own way to load modules in application folder
<nalaginrut>and not globally, so we can't just install packages in site-dir
<nalaginrut>it'll be in lib/ directory,
<nalaginrut>in the application folder
<nalaginrut>amz3: you can just use :auth, the session won't be established if you don't use :session
<nalaginrut>of course, the Artanis module won't break anything, it use the same way of Guile
<nalaginrut>just add local lib path to load-path
<amz3>I have to fight my NIH syndrom, but maybe I will go my own route, because I don't feel confortable.
<amz3>nalaginrut: don't feel under-appreciated if create my set of web tools :)
<nalaginrut>but as I said, it's necessary to check API and version, this is unnecessary for any generic pkg manager
<nalaginrut>frankly, my pkg manager may not be called if you're not in Artanis application folder
<nalaginrut>because of lacking of enough meta ino
<nalaginrut>s/ino/info
<nalaginrut>and won't effect anything out of the application folder
<nalaginrut>it's good for deploy, when users done their work, they just copy the application folder everywhere
<amz3>I already asked the question, but does anybody do Natural Language Processing using Guile?
<nalaginrut>I've tried Chinese for a bot
<nalaginrut>but just word splitting, Chinese is hard to split
<nalaginrut>there's no word splitting issue for English, because English (or Latin derivatives) has delimiter
<amz3>where can I find a recent copy of (ice-9 json)?
<davexunit>amz3: my laptop. beyond that, grab the patch off of guile-devel.
<amz3>got it thx https://lists.gnu.org/archive/html/guile-devel/2015-08/msg00003.html
<davexunit>cool.
<daviid>wingo: hello. now that you released [congrat!], and fosdem is behind, could drop an eye on this problem: http://paste.lisp.org/+6JGN/1 and help me to understand what's going on and how to fix it, thanks!
***sbp_ is now known as sbp
<davexunit>wingo: *excellent* new blog post
<davexunit>really great to have a bunch of TODOs enumerated, with background.
<davexunit>I don't know if I could actually do one of these projects, but the goals and necessary briefing have been laid out in such a way that I feel like it would be possible to try and make some amount of progress.
<wingo>davexunit: tx! in another project the maintainer does braindumps a lot, and i find it really helpful
<davexunit>it definitely answers the "so, how can I help?" question
<wingo>i thought of posting to the ml but it would be nice to pull in compilers people from outside too, so bloggies for now
<wingo>daviid: i don't know, sorry. would take a couple hours to figure out.
<wingo>i suspect clutter layout manager needs special support in guile-clutter.
<daviid>wingo: oh, a couple of hours really? too bad! I was hoping, with this little fully self content example, with the comments at the end, that you could help at least point me in some direction, in half hour, but maybe that was too optimistic
<daviid>the doc says there is nothing special about clutter layout anager, it is just like specialising an actor. I really wonder why my allocate method is not called
<daviid>wingo: it could be something really stupid in my little example, maybe...
<daviid>wingo: 1 of the problem is I don't know how to track this issue, where should I look, what to trace... I was hoping to learn a bit more fro you tracking this one ... but I understand, time is the most precious 'thing' of our lives ...