IRC channel logs

2015-06-23.log

back to list of logs

<amz3>first step after the graph database is done, is to build an ui for blogging/sharing some kind of keepsafe
<amz3>then I do a graphdb over dht/gnunet so that it works over gnunet
<amz3>maybe I'll get the gnunet/dht backend first
<amz3>it's a database you do whatever you want it replace sqlite/mysql/postgres/mongo
<ArneBab>if it provides the performance characteristics, yes
<amz3>presence over gnunet can work with sqlite
<amz3>this is not the problem
<ArneBab>are there already guile bindings for gnunet?
<amz3>remi is working on it
<amz3>for gsoc
<ArneBab>that’s nice
<ijp>ArneBab: for boot-9, psyntax, the runtime, and the file
<amz3>performance are overrater, if i may. caching and small number of users don't require big databases
<ArneBab>ah, yes
<ArneBab>amz3: I stumbled into performance bottlenecks quite a few times. I.e. the only address book which can keep up is bbdb
<ijp>ArneBab: about half of it is boot-9
<amz3>hopefully I have similar perfomance with sqlite, it will be good already
<ArneBab>amz3: that would be pretty good, yes
<ijp>which is about a 10x line increase over boot-9.scm
<ArneBab>ijp: and half of the lines are curly braces :)
<ijp>right
<amz3>ArneBab: I'm a newbie really, I don't know much about perf to say the thruth. I find graphdb to be a nice datastructure to work with
<amz3>compared to sql
<amz3>or even mongodb
<ArneBab>amz3: I know enough about perf to know that it’s hard to get right ☺
<amz3>I won't say, I don't care about performance, just that getting something working over gnunet is more important. I have an idea how to do that with graphdb so I'll try that
<ArneBab>sounds good
<ArneBab>better having something which works well than having nothing perfect ☺
<amz3>you know bdb, berkeley db right?
<amz3>wiredtiger is built by the guys that did bdb
<amz3>bbdb is emacs thing
*amz3 looking at bbdb
<ArneBab>the on-disk format of bbdb is essentially just lisp written to disk. But whatever it does to query that data beats all the other address books I tried.
<ArneBab>it beats them as in “it actually gets me the contact data I want within the fraction of a second it has before I notice a lag”
<ArneBab>I have some 2700 addresses in my address book, most of which I’ll likely never need, but that’s already enough to slow down most address books.
<ArneBab>and for emails there isn’t anything which is able to work fast. mu4e manages somehow but both thunderbird and kmail/akonadi take ages to load my mail. Often it seems as if once developers use a database they stop thinking about performance…
<dsmith-work>ArneBab: wow
<adhoc>ArneBab: or performance is someone else's problem
***heroux_ is now known as heroux
<nalaginrut>morning guilers
<nalaginrut>~
<ArneBab_>moin nalaginrut
<nalaginrut>heya
<nalaginrut>ArneBab_: I've taken a look at gcc for js backend, when I decided to start some prove of concept, unfortunately, I got some other work to do now, so sad ;-(
<nalaginrut>maybe I have to delay few months to come back for the hack
<ArneBab_>that sounds pretty cool
<ArneBab_>you mean the gcc-jit, right?
<nalaginrut>ArneBab_: jit? maybe, my thought is to generate js code with gcc
<ArneBab_>ah, sorry - I misunderstood.
<nalaginrut>in brief, compile C/C++ to js
<ArneBab_>dsmith-w`: I have a few hundred thousand emails in my maildirs. I fear that wasn’t on the feature-list of the people deciding to throw all the data into a database.
<ArneBab_>nalaginrut: which would allow running programs in the browser without relying on LLVM
<nalaginrut>ArneBab_: yes, that's the idea ;-)
<wleslie>ArneBab_: you're using mu?
<ArneBab_>I hope you’ll still manage to get there!
<ArneBab_>wleslie: mu actually copes :)
<ArneBab_>wleslie: I’m talking about KMail with akonadi
<wleslie>ArneBab_: I've had some success with wunderlust
<ArneBab_>on my homeserver I use mu4e
<ArneBab_>wanderlust became very slow with >10k mails in a single folder
<wleslie>hmm
<wleslie>I usually keep important folders small
<ArneBab_>I could reorganize my mails, with folders by year or such
<crocket>yo
<crocket>bipt, http://imagebin.ca/v/26C6t83RRwHX
<ArneBab_>wleslie: but that’s a maintenance overhead I had hoped to be able to avoid :)
<ArneBab_>(which ironically means that I want performance to be someone elses problem ☺)
<wleslie>I understand
<wleslie>I understand because I still have a hacked openimap in my github that I said I'd replace with some twisted 'soon' four years ago
<crocket>bipt, http://paste.lisp.org/display/150359
<crocket>bipt : When I press 'C-x C-f' in guile emacs, I see "Error in post-command-hook (icomplete-post-command-hook): (wrong-type-argument number-or-marker-p #<scheme 91/41>)" in minibuffer.
<crocket>Ignore the pastes above
<mark_weaver>bipt: FYI, regarding crocket's bug report above: he's using guile-emacs from guix, which is at commit 41120e0 (emacs) and d8d9a8d (guile)
<crocket>Let guile emacs take over emacs
<nalaginrut>out of topic, should 'guix' pronounced 'gaix' ?
<crocket>It's pronounced as geeks
<mdln>'geeks'
<mark_weaver>nalaginrut: no, it's pronounced /gix/
<nalaginrut>s/pronounced/pronounce
<mark_weaver>sorry, /giks/
<nalaginrut>ok ;-)
<mark_weaver>(my IPA is not very good)
<nalaginrut>and, let guile-emacs take over emacs please folks ;-P
<mdln>Speaking of IPA's, I could use a good beer
<mark_weaver>:)
<mark_weaver>I guess more properly: /ɡiːks/
<zacts>wait I'm totally confused
<zacts>what is the latest released version of guile?
<zacts>v2.1.0 ?
<mark_weaver>2.0.11
<zacts>or v2.0.11?
<zacts>huh
<zacts>what is this v2.1.0 tag on git?
<zacts> http://git.savannah.gnu.org/cgit/guile.git/tag/?id=v2.1.0
<mark_weaver>the guile version numbering convention is that released versions have an even minor number (second number)
<mark_weaver>odd minor numbers are for not-yet-released major versions
<zacts>oh I see!
<zacts>sorry :-)
<mark_weaver>np
<zacts>thanx
<zacts>so what is this guile-ssh?
<zacts>and is the canonical git repo this: https://github.com/artyom-poptsov/guile-ssh
<zacts>^ and since github, would make me assume it's not an official guile or gnu project?
<mark_weaver> https://lists.gnu.org/archive/html/guile-user/2015-02/msg00023.html
<zacts>ok
<artyom-poptsov>zacts: Hi. You're right, Guile-SSH is not an official GNU project.
<zacts>oh hey
<zacts>cool
<zacts>artyom-poptsov: yo
*mark_weaver --> zzzz
<zacts>I guess guile-ssh is your baby?
<zacts>gn mar
<zacts>mark_weaver:
*zacts is soon to follow
<artyom-poptsov>Yes.
<zacts>neat
<zacts>so you use libssh underneath
<zacts>I wonder if there is a linuxbrew package for it
<zacts>as I'm also using linuxbrew for things too
<zacts>until I fully switch to guix
<zacts>GuixSD that is
<crocket>Where do I file the bug report for guile emacs?
<zacts>or maybe I should use ijp's guile package manager
<zacts>crocket: don't they have a mailing list?
<mdln>zacts: GuixSD is pretty comfy, what's holding you up?
<crocket>GuixSD is alpha
<zacts>mdln: full disk encryption
<zacts>(and soon to possibly have college room mates)
<zacts>lol
<mdln>haha fair enough
<zacts>crocket: I'm looking, yeah perhaps one of the Guile mailing lists, but I dont' know sorries
<zacts>emacswiki has the most info I've found thus far on guile emacs
<mdln>zacts: I think the mailing list for it is under Guile or Emacs (maybe both?)
<mdln>I was sub'd at one time iirc
<zacts>guildhall
<zacts>artyom-poptsov: should I use guildhall to install guile-ssh on non guix systems?
<zacts>mdln: I have no idea
<artyom-poptsov>zacts: I'm afraid that the only way to install Guile-SSH by now is to compile it from sources manually, or install it though Guix.
<artyom-poptsov>s/though/through/
<zacts>ah ok
<zacts>cool
<zacts>I'll be using guix on debian 8 for now, but I still need to patch a systemd init script for guix
<zacts>and sysvinit
<zacts>so I don't have to manually run the guix-daemon
<zacts>on each boot
<crocket>zacts, What do you use for guile package manager?
<ArneBab_>wleslie: :)
<zacts>crocket: I'm not using anything yet, but I just saw ijp's guildhall on github
***michel_mno_afk is now known as michel_mno
<ArneBab_>when I a module definition in a begin, match does not work for me:
<ArneBab_>(begin (define-module (examples cli) #:use-module (ice-9 match)) (define (main args) (match args ((prog) (display args))) (newline)) (main (quote ("foo"))))
<ArneBab_><unnamed port>:1:0: In procedure module-lookup: Unbound variable: prog
<ArneBab_>the following works however:
<ArneBab_>(define-module (examples cli) #:use-module (ice-9 match)) (define (main args) (match args ((prog) (display args))) (newline)) (main (quote ("foo")))
<ArneBab_>can I fix that?
<ArneBab_>I have an idea why it happens (syntax definitions not being available in the begin, yet), but is there a way to avoid it? Something similar to begin, which provides the syntax imported in earlier forms in the body so it’s available for later forms?
<amz3>I am looking at it
<amz3>why are you using (define-module) ?
<amz3>no, it's ok I though there was something else
<amz3>I don't what you are trying to do,
<ArneBab_>it’s code I wrote to track down a bug in wisp (code running in the REPL but not from a script).
<amz3>define-* are AFAIK "root" forms, they can not be used inside begin or let
<ArneBab_>when evaluating several forms, wisp wraps them into begin
<ArneBab_>when I remove the use of match, everything works.
<amz3>what is wisp?
<ArneBab_>the indentation based scheme I wrote for Guile, SRFI-119
<ArneBab_> http://srfi.schemers.org/srfi-119/srfi-119.html
<ArneBab_>wrapping the forms in begin avoids delayed execution of code (only executed when the user starts typing the next line)
<amz3>sorry I can't help
<ArneBab_>no probs - thank you for trying!
<dsmith-w`>Tuesday Greetings, Guilers
***dsmith-w` is now known as dsmith-work
<remi`bd>hello! I wrote a small destructuring-bind macro over match (because I find it more expressive than using directly match) but Guile keeps complaining about unbound variables
<remi`bd>here’s the macro: http://paste.lisp.org/display/150397
<remi`bd>(destructuring-bind (foo) '(1) foo) → warning: possibly unbound variable `foo'
<remi`bd>(but it returns 1)
<remi`bd>where am I wrong here? is there a better way to write this syntactic sugar macro? should I stick with match because destructuring-bind is not idiomatic?
<remi`bd>thanks in advance :D
<mark_weaver>remi`bd: the problem is, in the '_' clause, 'foo' is not bound.
<mark_weaver>I guess maybe you should quote the pattern
<mark_weaver>where it is passed to throw
<mark_weaver>as it is, you are putting the pattern in there, and it's being interpreted as an expression.
<mark_weaver>so you probably want this instead: (throw 'match-error "destructuring-bind" 'pattern list)
<remi`bd>oh yes
<remi`bd>thanks a lot!
<mark_weaver>np!
<ArneBab_>ok, I fixed the issue, though not as I would have wanted it. Now any toplevel form ends a wisp chunk.
<ArneBab_>this can mean that the REPL spews intermediate output, but in the process I learned that it’s actually better than Python: That throws a SyntaxError in that case while it easily takes it in code files.
<lloda>hello mark_weaver, did you see my reply about the log(-nan) issue
<amz3>remi`bd: did you get my mail? if so can you send it back, I did not backup it
<mark_weaver>lloda: yes, I did. I'm okay with adding a case for NaN as you suggested.
<mark_weaver>although I wonder how you can assume that the result of log(x) is real when x might be negative
<mark_weaver><lloda> The doc for clog in the C library says that 'If z is NaN+yi (for any finite y), the result is NaN+NaNi and FE_INVALID may be raised'.
<mark_weaver>lloda: based on this ^^, we should probably follow suit and return +nan.0+nan.0i in those cases as well.
<remi`bd>amz3: I’ve got it!
<lloda>mark_weaver: in the examples you gave of cproj, when a half-nan number still meant something, the other part was always inf. The same is true for clog. nan+finite*i or finite+nan*i is the same as just nan.
<lloda>also, (sqrt nan.0) => nan.0 which is real?, but of course you don't know if the actual result would have been real? if you had managed to have finite numbers for the (/ inf inf) that got you the nan...
<lloda>in other words, return a real nan from log doesn't really assume that the result would be real
<mark_weaver>lloda: I think in most cases we should follow what C11 specifies
<mark_weaver>although it's sometimes hard since C11 has distinct functions for real/complex.
<mark_weaver>and because we distinguish exact zero from inexact zero, etc.
<lloda>but the C11 functions don't change domains
<mark_weaver>we should probably follow the C11 functions for complex numbers
<lloda>... I can't really argue with log(nan) should be log(nan+0i) and let's see what C does with log(nan+0i).
<mark_weaver>well, I haven't thought deeply on it, let me know if you disagree :)
<mark_weaver>rather than doing experiments, I would prefer to follow the actual C11 spec.
<mark_weaver>(or the latest draft, which is publicly accessible)
<lloda>there's no function in C that takes a real number and produces its log as a complex number.
<mark_weaver>as you know, every real number is a complex number
<lloda>yeah, as I said above, I can't argue with that
<lloda>but returning log(nan) => nan *means* the same as returning nan+nan*i and avoids the type extension.
<mark_weaver>and the Scheme numerical procedures work on complex numbers, so I guess our 'log' should follow 'clog'.
<mark_weaver>well, the scheme standard says that +nan.0 is real, although I admit that this is somewhat bogus.
<lloda>(sqrt -nan.0) -> etc, is actually the same issue.
<mark_weaver>true
<mark_weaver>what does the C11 standard say about csqrt(NaN) ?
<mark_weaver>well, I mean csqrt(NaN+0i)
<mark_weaver>I don't have time to work on this right now, alas.
<lloda> http://en.cppreference.com/w/c/numeric/complex/csqrt
<lloda>exactly the same as for clog, actually
<lloda>I saw a draft of C11 for clog and it was c&p in cppreference, so I take this as good
<mark_weaver>we should also be looking at what R6RS says
<mark_weaver>(ignore R7RS on this subject, IMO)
<mark_weaver>I guess it doesn't say anything about this.
<mark_weaver>anyway, gotta go... talk later!
<mark_weaver>but in general, I'd say follow R6RS and C11
<mark_weaver>and if they conflict, let's talk :)
<mark_weaver>but sure, sqrt(+nan.0) => +nan.0+nan.0i sounds right to me.
<lloda>D: now I seriously regret bringing this up, since I'll need to defend against sqrt(nan) giving me complex numbers, just as I was already doing with log(nan)
<mark_weaver>and yet it's not mathematically defensible :-(
<mark_weaver>although admittedly NaN is kind of a mess anyway
<mark_weaver>lloda: can you explain the issue? are you putting the results into a homogeneous array that only accepts reals?
<mark_weaver>if so, maybe we should silently convert any complex NaN into a real NaN at the point where a C 'double' is needed.
<mark_weaver>that might be a better place to do it.
<mark_weaver>WDYT?
<lloda>that wouldn't work for nan+inf*i which actually means something different from nan
<mark_weaver>right, that's a different case.
<mark_weaver>is that a case that will occur in your use case? and what do you need it to be coerced to, as a real?
<lloda>the issue is what you wrote, (array-map! log A B) will fail with a type error if the arrays are of real type just because log(nan) is 'complex'
<lloda>that will never occur in my use case, since B is all positive or nan
<lloda>my workaround is to take the magnitude of B, which believe it or not, works with nan
<lloda>so (log (magnitude -nan)) => nan, while (log -nan) => complex (!)
<mark_weaver>(log -0.0) => -inf.0+pi*i
<mark_weaver>that might also be an issue for you.
<mark_weaver>I think maybe that you need is the R6RS flonum library
<lloda>all my numbers are positive or nan, so that doesn't happen
<lloda>I don't know about that library, I'll look it up
<mark_weaver>lloda: okay, then under my proposal, (log +nan.0) => +nan.0+nan.0i which would be coerced to a real +nan.0 to put back into a homogeneous array of 'real' element type.
<mark_weaver>but there might be some other edge cases for two-argument log.
<lloda>so it would work as coercing a+0i => a ?
<lloda>that sounds pretty acceptable
<mark_weaver>right
<mark_weaver>regarding the R6RS flonum library, in theory we should be able to make it faster than our general numerical operations, but right now it's notably slower.
<lloda>hmm
<mark_weaver>so +nan.0+Bi where B is not infinity, would become a real NaN when put into a C 'double', 'float', etc.
<mark_weaver>+nan.0+/-inf.0i would have to be handled differently, I think.
<mark_weaver>since it actually represents a complex infinity of indefinite phase.
<lloda>I agree in principle, but then shouldn't this work?
<lloda>scheme@(guile-user)> (define a (array-copy #0f64(0)))
<lloda>scheme@(guile-user)> (array-set! a 3+0.0i)
<lloda>ERROR: In procedure array-set!:
<lloda>ERROR: In procedure bytevector-ieee-double-native-set!: Wrong type argument in position 3 (expecting real): 3.0+0.0i
<lloda>
<lloda>Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
<lloda>
<mark_weaver>right, we should probably fix that too.
<mark_weaver>this is a proposal, not how things work currently.
<lloda>right, understood.
<mark_weaver>lloda: btw, do you actually need an inexact zero imaginary part to be ignored for you use cases?
<mark_weaver>*your use cases
<lloda>I still think it would be ok to just return log(nan) => nan and nobody would ever complain, but your proposal seems acceptable.
<lloda>no, I'd only need log(nan) => nan+nan*i and for that to convert back to nan
<lloda>the only reason I got nan+pi*i was because that's what log(-nan) returns now, which I think we both agree is wrong
<mark_weaver>it's no less correct than returning plain +nan.0 :)
<mark_weaver>so if you think it's okay to say the imaginary part is 0, I wonder why you think it's wrong to say the imaginary part pi :)
<mark_weaver>*is pi
<lloda>well, those imaginary parts have no meaning. But if it's zero, then the result fits in a real, and within that domain (that is, as nan, not as nan+0i) , that's a correct 'not representable' result.
<mark_weaver>holding a baby, we'll have to continue this later :-)
<lloda>take care :)
***michel_mno is now known as michel_mno_afk
<lloda>although I don't have much more... I would say that you go from log(nan) to nan, instead of log(nan) -> log(nan+0*i) -> nan+nan*i. It makes sense to go from R to C when it helps to keep the function defined, but that doesn't happen in this case. So why not stay in R?
<mark_weaver>lloda: you may have the right of this, but I'd like to think on it some more...
<lloda>sure
<ijp>macros are surprisingly problematic
<mark_weaver>ijp: what do you mean?
<ArneBab_>new wisp release! *happy* wget https://bitbucket.org/ArneBab/wisp/downloads/wisp-0.8.4.tar.gz; tar xf wisp-0.8.4.tar.gz ; cd wisp-0.8.4/; ./configure; make check; examples/newbase60.w --decode-datetime Za6P-Jsy
<amz3>:)
<mark_weaver>ijp: are you speaking generally, or are they causing a problem for your javascript backend?
<ijp>well, the problem is that huge syntax objects are being generated that probably won't be of any use
<mark_weaver>yeah, I've been troubled by those as well.
<mark_weaver>they are specific to the 'syntax-case' system, not to macros in general.
<mark_weaver>more precisely, they are needed to support 'datum->syntax', iirc.
<mark_weaver>I actually wrote some code to strip all that crap out for purposes of producing psyntax-pp.scm, because I convinced myself it would be safe in that particular case.
<mark_weaver>ijp: see 'squeeze-syntax-object!' in module/ice-9/compile-psyntax.scm
<mark_weaver>but the problem is, that stuff is needed in case the syntax object in question is ever passed as the first argument to 'datum->syntax'.
<mark_weaver>and it's hard to prove that a given syntax object will never be passed as such an argument.
<mark_weaver>the problem can probably be mitigated quite a bit by aggressively sharing equal datums in literals, as guile does in its compiler near the bottom of the stack.
<mark_weaver>(below cps)
<mark_weaver>ArneBab_: so, because of the hackish way that 'define-module' sets the current module for the benefit of subsequent forms, it probably doesn't work correctly when it's part of a 'begin' form.
<ArneBab_>mark_weaver: it seems so
<mark_weaver>and I'm not sure I would call that a bug.
<mark_weaver>'define-module' is not really supposed to be a normal form that could appear anywhere at the toplevel.
<ArneBab_>mark_weaver: I now avoided that by making wisp stop to wrap the code in a begin form (and compile directly down to tree-il, as the scheme does-
<ArneBab_>the scheme language)
<mark_weaver>I don't understand what you just wrote.
<ArneBab_>mark_weaver: sorry… wisp used to wrap forms in a block of code into a begin. A block is code separated by two empty lines. It no longer does so.
<ArneBab_>I had done that to make the output at the REPL a bit nicer, but having correctly working code strikes me as more important :)
<mark_weaver>ah, okay, makes sense :)
<ArneBab_>that’s also where the new release comes from :)
<mark_weaver>:)
<ArneBab_>mark_weaver: I also just sent a mail for the SRFI with the question whether it can be finalized.
<ijp>mark_weaver: squeeze-syntax-object! is interesting, but I'm not sure if I can use it
<mark_weaver>ijp: yeah, in the general case you can't
<amz3>stis_: hi, are you into NLP?
<stis_>non linear programming?
<stis_>I'm working on constraint satisfaction on finite domains atm.
<stis_>see clpfd in swi prolog (I'm in discussion with the author to port it over to guile-log)
<stis_>amz3: ^^
<amz3>:)
<amz3>just asking
<amz3>i've been looking around conceptnet5, might be the first thing I load into my graphdb
<amz3>actually I have script that loads that in python, it takes several days with a single thread
<stis_>hehe, yeah that 100x performance hog can mae its marks
<ArneBab_>ijp: I uploaded a new newbase60 package for guildhall: https://bitbucket.org/ArneBab/wisp/downloads/newbase60_0.zip
<ArneBab_>(same URL as the last one, just new content -- removed the dependencies on srfi and ice-9