<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 <ArneBab>are there already guile bindings for gnunet? <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>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 :) <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 <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>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 <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… <adhoc>ArneBab: or performance is someone else's problem ***heroux_ is now known as heroux
<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 <nalaginrut>ArneBab_: jit? maybe, my thought is to generate js code with gcc <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 <ArneBab_>I hope you’ll still manage to get there! <ArneBab_>wleslie: I’m talking about KMail with akonadi <wleslie>ArneBab_: I've had some success with wunderlust <ArneBab_>wanderlust became very slow with >10k mails in a single folder <wleslie>I usually keep important folders small <ArneBab_>I could reorganize my mails, with folders by year or such <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 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 : 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. <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) <nalaginrut>and, let guile-emacs take over emacs please folks ;-P <mdln>Speaking of IPA's, I could use a good beer <zacts>what is the latest released version of guile? <zacts>what is this v2.1.0 tag on git? <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>^ and since github, would make me assume it's not an official guile or gnu project? <artyom-poptsov>zacts: Hi. You're right, Guile-SSH is not an official GNU project. <zacts>I guess guile-ssh is your baby? <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 <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? <zacts>(and soon to possibly have college room mates) <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>artyom-poptsov: should I use guildhall to install guile-ssh on non guix systems? <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. <zacts>I'll be using guix on debian 8 for now, but I still need to patch a systemd init script for guix <zacts>so I don't have to manually run the guix-daemon <crocket>zacts, What do you use for guile package manager? <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_>(define-module (examples cli) #:use-module (ice-9 match)) (define (main args) (match args ((prog) (display args))) (newline)) (main (quote ("foo"))) <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>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. <ArneBab_>the indentation based scheme I wrote for Guile, SRFI-119 <ArneBab_>wrapping the forms in begin avoids delayed execution of code (only executed when the user starts typing the next line) ***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>(destructuring-bind (foo) '(1) foo) → warning: possibly unbound variable `foo' <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? <mark_weaver>remi`bd: the problem is, in the '_' clause, 'foo' is not bound. <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) <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. <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. <lloda>there's no function in C that takes a real number and produces its log as 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. <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>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>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. <lloda>that wouldn't work for nan+inf*i which actually means something different from nan <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>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>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. <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>Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. <mark_weaver>lloda: btw, do you actually need an inexact zero imaginary part to be ignored for you 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>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 :) <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 :-) ***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... <ijp>macros are surprisingly problematic <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>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>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. <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_>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 :) <ArneBab_>that’s also where the new release comes from :) <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 <amz3>stis_: hi, are you into NLP? <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) <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_>(same URL as the last one, just new content -- removed the dependencies on srfi and ice-9