IRC channel logs

2014-03-12.log

back to list of logs

<mark_weaver>heh
<civodul>mark_weaver: i made the glthread/lock.h change
<civodul>review welcome :-)
<mark_weaver>thanks!
*mark_weaver looks
<mark_weaver>civodul: what will be the process the next time we want to run gnulib-tool? revert this patch, run it, and then reapply it?
<mark_weaver>civodul: it looks like there are some other gnulib updates in here, as if you used a different commit of gnulib than I did.
<mark_weaver>i.e. that effectively there was a gnulib update in this commit as well
<mark_weaver>and yet nothing in the commit log about that
<mark_weaver>so I don't know what version to switch my gnulib tree to
<mark_weaver>oh, nevermind. it is mentioned in the commit log after all.
<civodul>mark_weaver: our gnulib-cache.m4 does gl_AVOID([lock]), which means we don't pull in lock.[ch] at all
<mark_weaver>but not in the summary line, so it will be harder to find it again in the commit log.
<civodul>so there's no manual intervention needed
<mark_weaver>ah, good.
<civodul>actually i didn't know what Gnulib version you used, so i picked one close to the date of your commit
<civodul>but it turned out to not the exact same one
<civodul>no significant difference, though
<mark_weaver>yeah, it's pretty close, and the changes looked like improvements :)
<mark_weaver>e.g. 'sed' replaced with '$SED'
<civodul>yeah
<mark_weaver>I used v0.1-77-gd9361da
<mark_weaver>thanks for taking care of this. I think we're very close to a release. I just want to get 2.0.10 done asap.
<mark_weaver>I have a patch to fix undefined behaviors that I'm about to push, davexunit's fix for hash-for-each on weak tables, and then the dreaded NEWS (which I've been procrastinating, I admit)
<mark_weaver>s/undefined behaviors/dependency on undefined behaviors/
<mark_weaver>mostly having to do with shifts of signed integers, casts from unsigned ints to signed ints, etc.
<mark_weaver>clang alerted me to these problems, and I suspect they might be the cause of problems on other platforms, e.g. the crashes-on-first-run on ia64.
<civodul>oh, tricky
<civodul>good that you dig into that
<mark_weaver>so yeah, I really mean it this time, I want to get 2.0.10 out within a week. I guess I'
<mark_weaver>I guess I'll have to do without access to the build farm. oh well.
<mark_weaver>we'll just hope for the best.
<mark_weaver>(unless you have a better suggestion)
<civodul>apparently it's still all dead
<mark_weaver>ah, okay.
<civodul>i think we should fix a deadline, and fixes that don't go into 2.0.10 will go in 2.0.11 :-)
<mark_weaver>agreed.
<mark_weaver>what's a good date for you?
<mark_weaver>maybe also put out a call for testing?
<civodul>"within a week" sounds good to me
<civodul>and yes, a call for testing would be nice
<mark_weaver>(not quite yet, after I get this undefined-behaviors patch in, and the new tarball is built on hydra)
<civodul>yeah, sure
<mark_weaver>I'll get it in in the next few hours, so it should be ready tomorrow.
<civodul>cool
<civodul>could you do a first pass on NEWS too? :-)
<civodul>i can take it where you leave it
<mark_weaver>the dreaded NEWS :) yes, I'll poke at it.
<civodul>great
<civodul>for now, bed for me
<civodul>good night/day!
<mark_weaver>okay, goodnight!
<nalaginrut>morning guilers~
***Lajjla is now known as Ahli[DE]
***linas_ is now known as linas
<Ahli[DE]>nalaginrut, ''tis 5:08 and I cannot sleep.
<Ahli[DE]>Truly, mine is indeed a tortured existence.
<nalaginrut>Ahli[DE]: well, to my experience, if you can't sleep and you happened to open computer, you can never fall asleep...
<civodul>Hello Guilers!
<davexunit>hey civodul!
<artyom-poptsov>Hi civodul
<artyom-poptsov>civodul: I wonder whether we can use Guile-SSH channels as a medium for secure transferring of Guile-RPCs.
<artyom-poptsov>(if it makes sense at all)
<civodul>artyom-poptsov: TLS may be more appropriate, i think
<jemarch>hi
<civodul>hey jemarch
<artyom-poptsov>civodul: Probably. But as far as I understand you will need to implement some protocol over SSH channels anyway, if you want to use them to solve a more complex problem than just transferring of some data. So why don't use ONC RPCs?
<civodul>artyom-poptsov: ah yes, but i mean ONC RPC over TLS, rather than over SSH
<civodul>well i guess it depends on the use case
<civodul>custom protocols means that it's harder to deploy
<mark_weaver>I like the idea of TLS, but unfortunately I've heard plausible arguments from people I trust that it has been deliberately weakened by the NSA.
<civodul>well, everything could/may have been weakened by the NSA :-)
<mark_weaver>I recall seeing a post by John Gilmore, who was present at the standardization meetings, talking about this.
<mark_weaver>it sounds like TLS can be made secure, but you have to go out of your way to disable all of the insecure options, and of course bypass all of the CA stuff entirely, to have any hope of security.
<civodul>yeah
<mark_weaver>I realize that this is all coming off as quite vague and hand-wavy, so I suppose I will have to dig up some references.
<civodul>although in practice the real issues have been much more trivial: GnuTLS, goto fail, etc.
<didi>Well, the CA situation is hopeless anyway.
<didi>At least for browsers.
<mark_weaver>civodul: I don't really see why you would specifically steer people away from SSH and toward TLS.
<mark_weaver>I have to go offline for a while very soon, so I don't have time ATM to dig up references, but I can do so later.
<civodul>i don't steer people anywhere :-)
<mark_weaver>I, for one, have vastly more confidence in SSH.
<civodul>it's just that i view SSH as secure *shell*, so i'd tend to use something else for non-shell things
<mark_weaver>well, I think that's just a name. I don't see why that matters. SSH in practice is now designed and widely used to tunnelling arbitrary protocols and even to set up VPNs.
<cluck>:)
<civodul>yeah
<mark_weaver>if you use TLS, just be damned sure that you know what you are doing, because it comes out of the box quite insecure, AFAICT.
<mark_weaver>not that this really matters all that much, but I was the second full-time programmer at PGP Inc, working with Phil Zimmermann. (the last non-free software I worked on).
<mark_weaver>I'm not actually a competent cryptographer, but Phil told me that I had a good head for thinking about security issues nonetheless.
<artyom-poptsov>civodul: FWIW, there are examples of using SSH protocol as a basis for things beyond shell, such as SFTP and tunneling (as mark_weaver pointed out).
<mark_weaver>TLS was designed by a committee, several members of which were deliberately trying to weaken it. SSH, on the other hand, was designed by a single group apparently trying to make the thing as secure at they could make it, and for a long time has been led by the OpenSSH people, who are pretty hard-core.
<mark_weaver>anyway, going offline for a while, ttyl!
<civodul>right
<da4c30ff>what function to call to access a Scheme variable from C?
<taylanub>da4c30ff: The variable will need to be a top-level such that it's in the interface of a certain module, then you can use the module API to access it.
<ijp>da4c30ff: (info "(guile) Accessing Modules from C")
<ijp>there is a way to get the value directly, I believe, but the usual way is to get the variable object, and then reference that
<da4c30ff>thanks, scm_c_lookup and scm_variable_ref were the functions I was looking for
***scott_ is now known as Guest95286
<scott__>Hi, I was just wondering how much it'd take to change the software that uses older guile-1.6 to upgrade it use guile-2.0?
<ijp>probably a lot
<scott__>I mean do we have to change a lot of code or just here and there?
<scott__>has the syntax been changed a lot since then?
<ijp>probably depends which parts of guile it used
<scott__>and what do you suggest would be the best way to approach this if I had to really upgrade the software source?
<ijp>go slowly, try for 1.8 first, but keep an eye on what NEWS says
<scott__>okay.. so I should aim for 1.8 first and after that for 2.0.
<scott__>thankyou but if you have any other advice , do tell :)
<Ahli[DE]>mark_weaver, you seem to be fairly knowlegeable here. Do you know if it's possible to create a function (f id) where id is an identifier syntax object such that f returns an identifier syntax object which is identical in the sense of free-identifier=? iff id is identical in the sense of free-identifier=? with the added condition that it returns an identifier which is nonidentical to any other identifier in id's environment of course.
<Ahli[DE]>Basically, I need to generate a hidden identifier from another identifier that can't normally be accessed in a macro transformer.
<mark_weaver>I can't quite parse your question, but I suspect that 'generate-temporaries' is what you need.
<mark_weaver>but there's no need for an 'id' argument. maybe I'm failing to guess what you meant to ask.
<mark_weaver>you wrote "returns an identifier syntax object which is identical in the sense of free-identifier=?", but you didn't say what it's identical to.
<mark_weaver>and you wrote "iff id is identical in the sense of free-identifier=?" but again didn't say what 'id' is being compared with.
<mark_weaver>so I can't make sense of what you're asking for.
<Ahli[DE]>mark_weaver, no, generate-temporaries lack of an id argument ruins it.
<Ahli[DE]>Let me rephrase
<ijp>mark_weaver: he wants a deterministic procedure for mangling ids so that he can use it an an unhygienic macro
<Ahli[DE]>mark_weaver http://hastebin.com/raw/honihafexo
<Ahli[DE]>maybe this makes more sense.
<Ahli[DE]>I need to be able to deterministically go from #'name to #'some-other-id
<Ahli[DE]>Where #'some-other-id is guaranteed not to conflict
<mark_weaver>are these parameters lexically scoped, or dynamically scoped?
<mark_weaver>In Scheme terminology, "parameters" are dynamically scoped.
<mark_weaver>see http://srfi.schemers.org/srfi-39/srfi-39.html
<mark_weaver>If they are lexically scoped, I wonder what is the rationale for this.
<Ahli[DE]>THey are paramatres in the sense that they attempt to simulate dynamic scoping yes.
<Ahli[DE]>As in, they are basically set! to a new value at the start of the block and set! back to their old at the end.
<Ahli[DE]>The reason I rolled my own is because I didn't want them to be objects, I didn't want them to be able to escape their scope
<Ahli[DE]>As in, I don't want (let-param [[foo "bar"]] foo) ; ==> returns paramatre object that is reset away from bar due to dynamic unwind
<Ahli[DE]>I don't want that to be possible I mean, that should be a scoping error in my model.
<mark_weaver>I'm not sure what you mean precisely by "escaping their scope".
<mark_weaver>if you have one piece of code that sets a parameter, and you want to be able to access that from a different procedure in another scope, then it cannot be local to a lexical scope.
<ijp>Ahli[DE]: as I already pointed out on #scheme, you have the same problem in dynamic scoping if you return a (lambda () var)
<mark_weaver>well, if you can't access the parameter objects (independently of their values) then how does the code written in a different module access the parameter?
<mark_weaver>indeed, in fact you can export the ability to access and set! a lexical variable by returning (cons (lambda () var) (lambda (x) (set! var x)))
<mark_weaver>(i.e. a pair of two procedures, one that fetches the value and another that sets it)
<mark_weaver>or in your case it might be (lambda () (param foo))
<Ahli[DE]>mark_weaver: http://hastebin.com/raw/hoxobocome
<Ahli[DE]>ijp, well yeah, that's why I don't want dynamic scoping.
<Ahli[DE]>mark_weaver, well, in order for the different module thing to work I need that function I wanted
<Ahli[DE]>Since they will satisfy free-identifier=? across modules.
<ijp>Ahli[DE]: then what are you writing?
<mark_weaver>I still don't understand what function you want, because your specification for it was malformed.
<ijp>how will your wheel prevent this type of puncturing?
<ijp>most of your complaints about parameters have been based on making wrong comparisons with dynamicly scoped code
<mark_weaver>Ahli[DE]: you gave an example of a procedure setting the parameter, but you didn't show how the parameter would be accessed from another procedure in a different module.
<mark_weaver>if the parameter object is not stored in a variable visible to both modules, then how do you do this? I guess you could do it by having a global namespace for these parameters, but that's very bad. then you can get inadvertent clashes between parameters of the same name, meant for different purposes by different authors.
<mark_weaver>and that would lead us back to the bad old days of dynamically-scoped lisps, where one would get in the habit of choosing very long names for the variables, in the hope that no one else chose the same name.
<mark_weaver>the fact that parameters are represented as objects, and not merely names, is a major step forward. it seems like you're trying to go back to the old days without realizing why we moved away from that (long ago).
<Ahli[DE]>mark_weaver, well, I am just going to have to solve that with an [export-param ...] special form I guess
<mark_weaver>well, then you're effectively exporting a parameter object. so how is this different from parameters?
<Ahli[DE]>export is for variables, export param for paramaters, which of course just gets rewritten to exporting the secret variable in the end.
<Ahli[DE]>mark_weaver, I don't want to repraesent them as names, that's why I need this function
<Ahli[DE]>A paramatre object can be accessed outside of the param special form, this can't.
<mark_weaver>what's the advantage of having a separate namespace for parameters?
<Ahli[DE]>Like I said, I want if you do [begin [define-param x 3] x] to be a scoping error, x does not exist.
<Ahli[DE]>It's just one way of implementing the idea that they can't escape their scope.
<ijp>Ahli[DE]: what about (lambda () (param x))
<Ahli[DE]>With paramatre objects, if you do (paramatrize ((foo "bar")) foo) then foo is mutated the moment it escapes that scope
<Ahli[DE]>the object bound to foo, I should say
<ijp>(let-param ((foo "bar")) (lambda () (param x)))
<ijp>these problems don't go away, they just get rewritten differently
<ijp>that's what you keep failing to appreciate
<ijp>so it's not an object? so what, you can make an object with the exact same behaviour
<Ahli[DE]>ijp, hmm, I suppose that's fair.
<Ahli[DE]>Yeah I guess it's fine.
<mark_weaver>right, you can always make a procedure within the lexical scope that escapes and does whatever is needed by proxy.
<ijp>the same debate happens with boxes vs normal variables
<Ahli[DE]>Yeah, you're right I guess.
<mark_weaver>in fact, this is the basis for our implementation of 'the-environment' and 'local-eval' in Guile 2.0.
<Ahli[DE]>Yeah, I guess it comes down to paramatre objects essentially being thunks which use (param x) inside I guess
<mark_weaver>right
<Ahli[DE]>Or alternatively modelable as 1 argument functions which get passed the paramatre
<mark_weaver>in guile, parameters are actually implemented in terms of '
<mark_weaver>'fluids', which are guile-specific.
<mark_weaver>fluids aren't thunks, they are accessed via 'fluid-ref' and 'fluid-set!', and set within a dynamic extent using 'with-fluids'. same idea, slightly different syntax.
<mark_weaver>s/thunks/procedures/
<mark_weaver>(I actually prefer the fluid API, but parameters seem to be more popular)
<mark_weaver>(and more portable)
<mark_weaver>I should mention that anything like this, where a dynamic environment is automatically passed down the call chain, is problematic, because it doesn't mix well with some important programming techniques, most notably lazy evaluation.
<mark_weaver>e.g. when you force a promise that was delayed elsewhere, which dynamic environment does the delayed code get run under?
<mark_weaver>and more generally, there's always the danger that the parameters will propagate to code that you didn't expect it to propagate to, and that will cause problems.
<mark_weaver>for example, I have a long pending patch (never published) to add arbitrary precision floats to Guile.
<mark_weaver>but when you do something like (sqrt 2), what precision should it use for the result?
<mark_weaver>the only sensible mechanism I could think of was to use parameters/fluids.
<mark_weaver>however, imagine how this would be used in practice. you have some calculations to make at high precision, so you use 'parameterize' to set the precision and then do a bunch of stuff in that dynamic extent. maybe you print some of the values.
<mark_weaver>but what if the printing procedure does some arithmetic internally as part of its work. or who knows what else is happening under the hood.
<mark_weaver>your parameter settings will affect the behavior of code that you aren't even aware of, and that you shouldn't be aware of.
<Ahli[DE]>Hmm, I guess the one it was forced under.
<Ahli[DE]>As in, what happens if you model paramatres as deep argument passing which is sort of what I use them as a more convenient thing for.
<mark_weaver>well, if that's your answer, you'll be glad to know that's what actually happens with promises.
<ijp>if you think about it in terms of exceptions, it makes a little more sense
<mark_weaver>when promises are forced, the delayed expression is evaluated in the dynamic environment of whatever forced the promise.
<Ahli[DE]>Excellent
<Ahli[DE]>I like to reason about paramaters as simply implicitly passed arguments.
<mark_weaver>however, consider this now: (with-input-from-file "foo" <code-that-returns-a-lazy-stream-of-its-contents>)
<ijp>yeah, crazy innit
<mark_weaver>now that seems intuitive enough, but it doesn't work.
<ijp>in haskell, with lazy IO, you basically have to give up on any kind of decent error handling
<mark_weaver>in that case, you wanted the delayed code to run in the dynamic environment of the thing that created the lazy stream.
<ijp>I should probably find out what the current fashion in IO is down haskellland
<mark_weaver>or maybe not even entirely. maybe you want some parameters from the thing that created the stream, and other parameters from the thing that forced the stream.
<mark_weaver>it's kind of a mess.
<ijp>I stopped paying attention after iteratees
<Ahli[DE]>Well, I wouldn't in that case.
<mark_weaver>my answer is to avoid parameters whenever it's not too painful to do things another way.
<mark_weaver>I admit that sometimes it's the best tool we have for a particular job (e.g. 'current-input-port', 'inexact-precision', etc)
<ijp>they are an effect, use with caution
<Ahli[DE]>Haskell doesn't have Lazy IO.
<Ahli[DE]>The entire point of putting IO in a Monad is to force it to be strict and in a well defined order.
<ijp>haskell certainly does have lazy io
<mark_weaver>and of course, the current exception handler is essentially treated the same way.
<ijp>readFile & friends
<ijp>unsafeperformIO under the hood
<Ahli[DE]>Well, the entire point of putting it in a monad is to make it more appealing syntax I guess, the entire point of passing realWorld around is to do that
<Ahli[DE]>Well, parameters can be modeled simply as passing arguments to functions so I don't see how they are an effect.
<ijp>now, it is frowned upon for any important code, granted, but it is there
<Ahli[DE]>Ohh, that stuff I thought you meant to imply all IO in Haskell is lazy
<Ahli[DE]>Well lazy file reading in HAskell is basically unsafe.
<Ahli[DE]>It can be used safely but it can even give you segfaults.
<ijp>Ahli[DE]: put it another way, I can write state passing code: does that mean state isn't an effect?
<Ahli[DE]>Well, so is unsafeCoerce and unsafePerformIO, you can use it responsibly and implement completely safe functions using it, you just lose guarantees.
<mark_weaver>the way I look at it, sometimes a piece of code has two relevant dynamic environments: the dynamic environment where the delayed expression was created, and another when it was forced. same for internal procedures.
<ijp>I can think of all my C programs as having one extra parameter per global variable, does that mean there are no glboals?
<Ahli[DE]>I wouldn't be surprised if you could implement unsafeCoerce using lazy file reading.
<Ahli[DE]>That's fairly philosophical I guess. I'd say it means that if what you do can also be simulated without state it doesn't open up the can of worms that state opens up.
<ijp>if you simulate state, you get all the problems of state
<ijp>if you simulate dynamic scope, you get all the problems of dynamic scope
<Ahli[DE]>It means that there is no distinction that affects you.
<ijp>etc.
<mark_weaver>ijp++
<Ahli[DE]>When people talk about state and mutation in this context they talk about its evil,s if you use state and mutation in a way that simulates identical behaviour to what can be done without it then you don't expose yourself to those evils.
<Ahli[DE]>Well, that's the point paramaters do not simulate dynamic scope, they simulate a subpart of it.
<ijp>if you are careful, and only bite off as much as you can chew, it's simpler to handle, but that's as true in guile and haskell as in C
<mark_weaver>parameters are like dynamic variables, where the "name" of the variable is unique for each parameter object.
<Ahli[DE]>Just like these kinds of restricted states do not simulate unrestricted state but a subpart that isn't quite as harmful.
<Ahli[DE]>So you don't get all the problems at all.
<Ahli[DE]>Mutation isn't harmful, unrestricted mutation is harmful.
<ijp>in other words, the Why is more importan than the How
<mark_weaver>so you don't have to worry about collisions, at least. the other problems with dynamic scope still remain.
<ijp>this is my opinion, feel free to subscribe to others
<Ahli[DE]>Well, isn't that basically the biggest harm of dynamic variables? THat that neednl; t be the case and weird conflicts may arise?
<mark_weaver>the name conflict problem is a big one, and it's good that parameters solve it. but some other very serious problems remain.
<Ahli[DE]>mark_weaver, well, since identical behaviour to paramaters can be implemented with pure static scope without mutation by passing them as explicit function arguments, the same problems also arise with static scope then.
<ijp>Ahli[DE]: as I said, the problem is the behaviour, not the method
<mark_weaver>basically, if you have a program that makes a lot of use of parameters, you are basically ruling out the possibility of using many other important programming techniques such as lazy evaluation, and other such uses of lexical procedures.
<ijp>if you are not careful, it doesn't matter whether you have parameters, dynamic scope, or do a global rewrite
<mark_weaver>Ahli[DE]: the difference is that when you pass arguments to procedures explicitly, you get to choose which of the "
<mark_weaver>two "parents" of a delayed expression will pass down the parameter.
<mark_weaver>when it's done automatically, the language has to make an arbitrary decision without any intelligence, and it often gets it wrong.
<Ahli[DE]>Well yes, paramaters always pass the argument of one of the environments yes. But I don't see how this loses you provability or reasoning.
<mark_weaver>a delayed expression essentially has two "parents" that it might inherit parameters from: the parent that created it, and the parent that forced it.
<Ahli[DE]>As far as machine analysis by a compiler goes and optimization techniques, the two are indistinct.
<mark_weaver>sometimes you want one, sometimes you want another.
<mark_weaver>and although I haven't thought it through, I suspect there are cases where there are more than two parents. for example, curried procedures.
<Ahli[DE]>mark_weaver, isn't the choice always the environment where the thunk is forced specifically to simulate a passing argument model?
<mark_weaver>where you have the parent that created the original procedure, the parent that passed in the first argument, the one that passed in the second argument, etc.
<ijp>Ahli[DE]: *we* always do it that way, that doesn't mean it is the best decision in all case
<ijp>see mark_weaver's stream example above
<mark_weaver>parameters give you convenience, but at a major cost.
<mark_weaver>heavy use of them closes many other options.
<Ahli[DE]>I don't see the cost I have to admit, in the model of the environment where the thunk is forced it's basically syntactic sugar for deep argument passing.
<ijp>what's the old saying, the model is not the object?
<Ahli[DE]>Which is typically what you use it for anyway, to not have to do this so you don't get functions which take 7 arguments.
<ijp>forget implicit argument passing
<mark_weaver>don't get me wrong, I effectively make use of parameters quite a lot, e.g. the implicit parameter that specifies the current exception handler, the current input/output/error ports, etc.
<Ahli[DE]>Haskell doesn't have parameters, I had to program XLib in Haskell half a year back and a lot of the functions I had to use and write had 8 arguemnts, this is without keyword arguments, 6 of those arguments they just pass down to functions they call unaltered
<mark_weaver>I will acknowledge that we don't know another good way to deal with those things.
<mark_weaver>but I *wish* we had a better way.
<Ahli[DE]>Exceptions is also something that would be pretty hard to conveniently do without them, you'd have to pass the exception handler to pretty much every call
<Ahli[DE]>Well, say there was another way, that still didn't stop people from using deep argument passing which is the same thing so I don't see the problem.
<Ahli[DE]>But maybe this is my reasoning on a purely theoretical level and your reasoning on practical mistakes human beings make.
<ijp>hehe, quite the opposite actually
<mark_weaver>well, I've tried my best to explain the problems. I don't know how to make it any clearer.
<ijp>mark_weaver is talking about the parameter interface, and the things it leaves unspecified, you are talking about an implementation which specifies it
<ijp>but it's went round in circles enough, I think
*zacts is thinking about checking out the possibility of importing guile-2.0 into slackbuilds.
<zacts>tomorrow I'm seriously planning on finishing up cleaning up my patches for FreeBSD ports.
<mark_weaver>zacts: btw, it seems now that 2.0.10 is quite imminent, within a week, and probably no major changes made between now and then. now would be an excellent time to test the latest tarball from http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest
<mark_weaver>there have been some important changes since your last test, that might affect portability on freebsd, so it would be great if you could test the latest tarball.
<mark_weaver>Madsy_: ditto ^^
<mark_weaver>and ditto for anyone on this channel. it would be great to test the latest tarball on a diverse set of platforms and OSes.
<mark_weaver>(make sure the tarball is at least 2.0.9.239)
<Madsy_>Hm?
<Madsy_>Oh
<Madsy_>I have to get 2.0.9.219-e1bb working again first :/
<mark_weaver>Madsy_: there are fixes in there for the missing tests and cross-compilation problem with c-tokenize, among others.
<Madsy_>I'll try building from a clean directory. Somehow I suspect ./configure is caching something it shouldn't
<mark_weaver>Madsy_: fwiw, in lieu of notes, I tend to just keep transcripts of my shell session where I build something.
<Madsy_>mark_weaver: Yeah I checked my shell history but it was too late
<Madsy_>Anyway I'm 90% certain my current setup should work. Except it doesn't
<mark_weaver>(I use emacs shell mode, but other good ways include logging in 'screen' (using C-a H) or the 'script' command.
<mark_weaver>bummer.
<mark_weaver>well, I guess we'll have to sort these things out in the 2.0.11 cycle.
<Madsy_>Next time it works I'll write it down for sure
<mark_weaver>I intend for the gap between .10 and .11 to be much less than the one from .9 to .10, since there are some important problems to fix and features to add, including R7RS support.
<zacts>mark_weaver: nice, I'll check it out.
<mark_weaver>zacts: thanks!
<mark_weaver>civodul: fwiw, I think it's a good time to post calls for testing.
<mark_weaver>wdyt?
<civodul>mark_weaver: yes, go ahead :-)
<civodul>i think if fixed the cross-compilation issue Madsy_ reported
<civodul>and 'make distcheck'
<mark_weaver>yes, I saw that, thanks!
<mark_weaver>do you think it's appropriate to post to platform-testers?
<mark_weaver>are you suggesting that I should run 'make distcheck', or telling me that you did it?
<civodul>i did, and that allowed me to notice a couple of issues that i fixed
<civodul>platform-testers is appropriate yes, but they need to be told a deadline
<civodul>so they don't spend time on it once it's too late
<civodul>the risk with platform-testers is to get reports for crazy platforms ;-)
<davexunit>off topic, but do you guys know of a good irc channel or forum to ask general programming questions in?
<civodul>other than this one? :-)
<mark_weaver>there's such diversity of languages and programming styles, that I can't think of any forum that can cover them all well.
<davexunit>I am working on a problem involving levenshtein distance
<davexunit>but going further than just the levenshtein differences, outputing the actual operations that it would take to transform one string into another.
<civodul>nice
<mark_weaver>okay, the question is more to do with algorithms
<davexunit>yes
<civodul>we need to hook up levenshtein distance in Guix
<civodul>guix package -i dash -> did you mean "guix package -i bash"?
<davexunit>neat :)
<taylanub>After I ,reload my module in the REPL, some subsequent commands result in a "Wrong type argument: Error while printing exception.", anyone ever had this ? Restarting Guile works.
<civodul>davexunit: so make sure to share that when you're done ;-)
<davexunit>calculating the distance as a number is easy, I used the simple wagner-fischer algorithm to do it.
<civodul>ok
<davexunit>civodul: what algorithm did you apply?
<civodul>davexunit: i didn't implement it, just saying that we should
<davexunit>ohhh
<davexunit>okay. :)
<civodul>which is where you come in ;-)
<davexunit>maybe I could contribute that sometime. :)
<mark_weaver>I suspect the key is to store in the matrix not only the minimum distance, but a set of edit operations that has that minimum distance.
<mark_weaver>that's the first solution that comes to my mind, anyway.
<davexunit>mark_weaver: I've made some matrices by hand and wrote out what the optimal paths are, but I've been failing to write a program that can output that path correctly.
<davexunit>or rather, it can output *some* test cases correctly, but not others.
<mark_weaver>obviously that means the storage requirements are much higher.
<davexunit>yeah, it's more intensive, but that's okay.
<davexunit>I just want it to work at all before I even think about performance.
<mark_weaver>if you do proper sharing of the data structures used to store the edit operations, it shouldn't be too bad though.
<mark_weaver>e.g. by consing onto the list of the minimum neighbor.
<mark_weaver>so actually, I guess the asymptotic memory usage isn't any higher.
<mark_weaver>(the storage per entry in the matrix is bounded to a constant)
<mark_weaver>davexunit: I guess I don't see any complication here. each time you fill in an entry in the matrix, you store both the distance and the sequence of editing operations, which would be represented as a list, so you'd just cons the new operation to the sequence from the minimum neighbor.
<davexunit>mark_weaver: yeah, that's essentially my thoughts too. I just haven't gotten it right.
<davexunit>going to step away from it and make pizzas
<davexunit>then try again later or tomorrow or something.
<ijp>davexunit: if I don't have any better ideas, I usually just ask #emacs
<davexunit>civodul: I think adding levenshtein distance stuff to guix would be fun. I'll add that to my TODO list.
<civodul>yesss!
<ijp>taylanub: the error while printing exception is my favourite error
<ijp>I forget what causes it though, maybe you are throwing an exception with arguments that the exception pretty printer can't handle
<taylanub>My module throws no exceptions. I have a custom record printer, maybe that's relevant.