<daviid>wingo: incomplete, but here: http://paste.lisp.org/+6U2Y Notes: (a) using org mode, a lot easier to read imo, but if you [maintainers] don't like it i'll fix later; (b) it is the top of the file, once it's good and complete I'll merge patch ...; (c) only added 1 notable change so far, will work on that now but bugs fixed list is complete till yesterday [need to pull and complete everyday till we release of course, will do]; I added <daviid>documentation nodes dded/reviewed, which I think usefull for the genious who did read and remember perfectly all doc bits since 2.0.11, to warn them they better udate their mem, wdyt? <daviid>mark_weaver: your feedback is welcome too of course ... and civodul but he is sleeping I guess :) <mark_weaver>daviid: the change from #:renamer to #:prefix was only a stylistic improvement. afaiu, it shouldn't make any functional difference <daviid>mark_weaver: I do, but would you consider this a notable change? web: Export 'server-impl' procedures and the 'http' server implementation [commit 61e1c2130cee904e03561b6768ef963c1b8fbf71] <daviid>mark_weaver: is this user visible "Add SCM_VALIDATE_SIZE_COPY and SCM_NUM2SIZE", and if yes, a notable change? <daviid>wingo: mark_weaver, civodul, here http://paste.lisp.org/+6U33 [ NEWS for 2.0.12 - draft 2 ] which is complete till yesterday, commit a192c336a22b8c9ac354e88c2f2b317dff22b8c9 _except_ wrt goops fixes which I still need to add ***pehlivanlar is now known as ultrakebab
<spk121>daviid: w.r.t NEWS. foreign objects were reverted for 2.0.12 <daviid>spk121: could you please update/annotate the paste, and point me to the changes you made so I can check/learn: foreign objects are all but familiar to me, thanks! <spk121>daviid: all I did was strike all the text w.r.t foreign objects <daviid>spk121: ok thanks: no need to write about this at all? <daviid>spk121: when you say 'revert', it ounds to me that it is a user vivible change and hence must be signal one way or another, don't know ... <spk121>daviid: foreign objects were added and then removed after 2.0.11 <daviid>spk121: ah! I see this commit now, which passed below my nose: ff98cbb643d43c9f8c6ee0e0b4e1bad72aced62e Revert foreign objects. <daviid>if you spot any other things let me know, have to go afk, bbl <daviid>sneek: later tell spk121 maybe you did strike too much :) I beleive I must then keep an updated version of the second sentence: "*** SMOBs\\nFunctionalities has been added to disable automatic finalization: see the (Smobs) documentation node for the details and new functions. <spk121>Hi. If someone is running guile master, could they try this 1-liner to see if a 2.0.11 bug is also present in master? <sneek>spk121, daviid says: maybe you did strike too much :) I beleive I must then keep an updated version of the second sentence: "*** SMOBs\\nFunctionalities has been added to disable automatic finalization: see the (Smobs) documentation node for the details and new functions. <spk121>(use-modules (ice-9 optargs)) (define* (func A #:key B) #t) (func 1 2) <spk121>should give "invalid keyword" and not "error while printing exception" <wleslie>woo, automated builds for windows users <wingo>protip for speeding up git compilation when the bytecode version updates: fetch the corresponding tarball from hydra and unpack the prebuilt/ tree into your prebuilt/ <ecraven>in the table on top, hover over the column header to see which guile is which <ecraven>I don't have the CSS-fu to create vertical column headers :) <ecraven>(without investing more than 3 minutes) <wingo>ecraven: perhaps a bug with tests-finished; chez appears to have completed twice the number of tests as everyone else :) <ecraven>ah, I might have forgotten to clear the log file for that :-/ <ecraven>still working on that table, not ideal as it is <wingo>ecraven: just to check :) you compiled with -O2, right? it's probably easiest to compile from the release fwiw <ecraven>I use the arch linux pkgbuild as it is <wingo>as it builds much faster, already did the autoconf etc <wingo>so i guess you fixed the arch build to do -O2? <ecraven>there are arch packages for everything, the missing schemes I added to aur <wingo>at least before, there was some bug there <taylan>wingo: have you seen the latest state of my SRFI 64 implementation that I proposed as a replacement for Guile? it has all the features of the original, and is properly modularized and has other maintainability improvements. it passes the SRFI 64 meta test suite, and Guile's tests pass with it... <ecraven>wingo: ah, it seems it does not do -O2 <ecraven>so I should re-run that, after compiling guile with -O2, probably <wingo>ecraven: as long at it doesn't pass any CFLAGS you get -O2 by default <wingo>the bug was that in the past it passed CFLAGS= <wingo>you are a valiant person for doing all this benchmarking :) <ecraven>wingo: well, not so hard, I've got the makefile for running it all :) <ecraven>and the graphs are fun to do, just need to figure out a better way to present all this info <wingo>taylan: i haven't seen it, afaiu it provides no benefit besides maintainability in some way? i haven't touched srfi-64 at all so i have no horse in this race <wingo>ecraven: it should be sufficient to just rebuild libguile/ <wingo>if you have build .go files for the scheme stuff, no need to clear that out <wingo>please do file a bug with arch to fix guile's cflags :) <taylan>wingo: maintainability, and *arguably* nicer default output (in particular, not silent at success, but rather prints "[PASS]" as seems common) <taylan>the upstream SRFI 64 implementation is, IMO, kind of an unholy mess :) <wingo>ok, i punt for now then, i think you should take it up with mark_weaver who merged the original srfi-64 impl <wingo>i don't use srfi-64 so i can't judge well <taylan>there's more important things I need feedback on from mark_weaver (who's quite busy AFAIK) so I'll leave it aside for now <lloda>I have fixed an issue with my branch lloda-array-support and I have rebased it on top of last master. Reviews sought. I can provide summary (did so a while ago in the ml). <mark_weaver>taylan: while I agree that the upstream srfi-64 is not nice to look at, there are many benefits to sticking with upstream: (1) upstream is maintaining it, so we don't have to, (2) upstream has been widely tested for many years, and has been tested precisely on the existing srfi-64 test suites out in the wild, whereas your new one is likely to have some bugs lurking, and is likely to break some existing uses of srfi-64. <mark_weaver>of course, I appreciate your effort to clean things up, but the thing is, this is not code that I want to be paying attention to. I would prefer to delegate the job of maintaining it to upstream. <mark_weaver>on the other hand, if you'd like a better srfi-64 implementation and/or default behavior, I would encourage you to work with upstream to get some improvements merged there. <wingo>imagine giving debbugs control commands to sneek <ArneBab>Is there a really fast way to check all chars in a file (put differently: what’s the fastest way to read a file — is there something faster than open-input-file?)? <ArneBab>I’ll need to go through a few hundred terabytes of files <ArneBab>rather around a hundred terabyte (and I hope I can cut that down) ***dsmith is now known as dsmith-work
<lloda>there is (get-bytevector-n) from rnrs which on a random test takes 0.033615s real time to read a 17761319 byte file <lloda>by the way uniform-array-read! and uniform-array-write are still in the documentation even though the code was removed back in 2011 <ArneBab>lloda: I’d now need a bytevector-index, but I don’t have that… <ArneBab>and my current tries using ports take 10 seconds where my python takes 0.3 seconds <wingo>ArneBab: what are you looking for? <wingo>what doe you mean check all chars in a file <wingo>i want an implementation of channels or something like that on top of ethreads or 8sync or guile-a-sync or something <wingo>i.e. a concurrency primitive that works on scheme datums, not byte streams <daviid>wingo: hello! afaict, cris vine does not not show up here <daviid>I invited him [by email] to join us here because I needed talk about guile-a-sync, which I use for 1 of my project for which I need interaction with glib main loop _and_ gule-inotify2 ... so far he did not ping <daviid>he's very responsive to email though, and we resolved my issues by email <paroneayea>wingo: I'm itching to get to 8sync tested to work with the new ports stuff... <paroneayea>basically I have to do a simplest possible implementation of our standard by next week. Sadly, it's easiest to glue it together in python <paroneayea>but long term I want to make the version I want to work on for a long time in Guile. <wingo>yeah, but that takes time. still, things are getting better i think <paroneayea>guile has grown a lot in the 1.5ish years I've been involved <wingo>now, you come with a problem and folks come out and say "i have a library for that" <wingo>there's still room to invent and reinvent but it's a nice thing <wingo>we just need to be able to share our work in a better way :) <paroneayea>guix has helped there, but yeah, doesn't fit for everyone <wingo>it's going to be amazing when 2.2 is released <wingo>for people running some gnu/linux variant, the easiest way to get guile 2.2 is going to be guix <wingo>unless you're already running a system that packages the prereleases, like arch or something <wingo>paroneayea: which libraries were you missing, just out of curiosity? :) <paroneayea>wingo: well, I need a database to store stuff in, so I was originally figuring on hacking on guile-squee or using the gdbm bindings <paroneayea>wingo: and then I need an activitystreams library, and hey I have one, but I wanted to finish the json-ld integration and I never finished that, whereas I have a totally working python library... <paroneayea>wingo: and maybe most annoyingly, https / tls stuff in guile is still not good! <paroneayea>wingo: so, all stuff that long term I'm not worried about in guile, but python has a much faster "one week turnaround" possibility here <mdls>Anyone here use GNU OS and/or Guix? <paroneayea>mdls: I think a lot of both in this channel, yes :) <daviid>taylan: I see "Fix SRFI-2 (and-let*) implementation [commit 57e877591532703714ec8ffb5aaefc378fc18423] ... Re-implemented this in a more verbose but accurate way." Is this linked to any bug report? I don't think so but just want to be sure. If not, I still wonder if I should or not make an entry in the NEWS ? <daviid>ok, I added an entry in the 'Fixed Bugs', reviewers may drop it if ... <amz3`>paroneayea: using gdbm is a long road, you'd rather use guile-wiredtiger, it's a bit more complex (several tables, multiple columns) but it pays off <amz3`>actually there is a way of using guile-wiredtiger where it really look like a rdbms <amz3`>I should write about it prolly <amz3`>paroneayea: what would you like to store? I could write the database part of your application <amz3`>I know what, I could add a suggest search feature to hyper! <amz3`>But I was thinking about the database part, I'm wondering whether I should move to a graphdb or plain wiredtiger tables <amz3`>Also, doing a webui can be helpful actually <amz3`>graphdb seems appealing, I'll streams everywhere O_O <amz3`>or I could write a: how to build a relational database library using wiredtiger... <amz3`>what's a good example app for an RDBMS? <wingo>closed 51 bugs in the past week! <amz3`>If I write an article before then end of the month I'll make it my high score post count <random-nick>are guile threads some sort of green threads or they spawn real os threads? <ijp>they take the sabbath off, but otherwise yes <ijp>futures get put on a worker queue, but I don't remember if that gets exposed for users <daviid>wingo: I can patch and email if you prefer, let me know [I used lisppaste for this because I wanted to get a feedback with draft 1, but now I may as well patch and send...] <wingo>daviid: patch not strictly necressary but email would be nice so it enters my todo list <daviid>wingo: ok, i've just emailed to guile at devel <jao>good evening, wingo :) <taylan>daviid: I believe there was no bug report on debbugs for and-let*, at least not by me <taylan>mark_weaver: re. SRFI 64, I can understand, no problem. (it's not wasted effort either way since the implementation is part of my R7RS SRFI libraries collection) ***dsmith is now known as dsmith-work