IRC channel logs

2019-11-05.log

back to list of logs

***sneek_ is now known as sneek
<RhodiumToad>hm. is there some reason why for-each over 3 lists would be 10x slower than over 2 lists, for the same lengths?
<lloda>RhodiumToad: special case for 2 args while 3 args depends on rest args and apply
<lloda>just a guess, and 10x is a lot, but it's a pattern I've seen
<sneek>So noted.
<lloda>what did you note sneek
<chrislck>sneek: what is just a guess, and 10x
<sneek>I've heard just a guess, and 10x is a lot, but it's a pattern I've seen
<chrislck>lol
<chrislck>sneek: botsnack
<sneek>:)
<nly>lol
<lloda>it's just the comma? haha
<RhodiumToad>fwiw, the context is: how best to do a function or macro that executes something a fixed set of times with a fixed set of values bound to variables
<RhodiumToad>like (for-each (lambda (a b c) ...) '(1 2 3) '(4 5 6) '(7 8 9))
<chrislck>RhodiumToad: maybe your case would benefit from a custom for-each type macro
<RhodiumToad>the values could have been calculated by a do-loop, but using do in a macro is tickling some compiler bug
<RhodiumToad>winner so far is (let ((proc (lambda (a b c) ...))) (proc 1 4 7) (proc 2 5 8) (proc 3 6 9))
<RhodiumToad>(there are actually more than 3 calls, but not that many more)
<RhodiumToad>this fails on a 32-bit arm build: https://dpaste.de/9gg6
<lloda>RhodiumToad: I don't think that should take 10x longer for three args. for-each is the natural way to write it I'd say
<lloda>if your case is small enough I'd send it to the list
***Server sets mode: +nt
<wingo>civodul: i was wondering if we should adopt one of these fancy code review tools
<wingo>github pull requests are quite convenient but it's not great for a gnu project to be on github
<wingo>i use phabricator for firefox work, which is pretty nice also
<wingo>and gitlab is fine
<wingo>but perhaps gerritt might make sense?
<wingo>i know there's an instance that sourceware runs for other gnu projects that perhaps we could use
<wingo>i am on the gdb mailing list and they just switched to it
<wingo>the email bridge seems to work fairly well
<civodul>wingo: we could give Gerrit a try, sure
<wingo>i never know how many r's and t's are in gerrRiT
<civodul>me neither actually :-)
<civodul>i see an emacs-magit-gerrit package, so it must be great
<wingo>hehehe :)
<civodul>what would it take to set that up?
<civodul>perhaps we can use the sourceware instance?
<wingo>yeah perhaps, we can ask them
<wingo>ok let's float the idea on the mailing list maybe. gdb and glibc having experience with it recently can let us know how it would fit into our workflows
<daviid>wingo: does gerrit depend on js, possibly nonfree js?
<wingo>daviid: i wouldn't think so, given that glibc and gdb use it
<wingo>i mean it probably has js
<wingo>but probably not non-free js
<daviid>ok
<wingo>something to verify tho of course
<daviid>fwiw, i won't use (any of these) tools, so i hope what ever is pick-up has indeed a dead good interface with email, and copes with the current workflow, patch, ML, review ...
<wingo>apparently gerritt's email interface is pretty nice
<wingo>and there is a magit extension for it as well
<daviid>ok, great. saying this because sice gnome moved to discorse ( a total disaster imo), i can't contribute anymore (i don't want to, to be correct), of course just my 2c ...
<daviid>imo, if one has to browse to contribute, or review, there is 'something wrong' in the project 'design', again my 2c - i know there will always be a division between those of us who beleive in the pr workflow and those who prefer the email workflow ...
*wingo nod
<wingo>still, do look into gerritt and see what you think, i understand the concerns and we should investigate if this specific solution addresses the concerns
<civodul>i too wouldn't like to have to use the browser, but like you write, there are other options that seem to work well
<civodul>so i think it's reasonable to give it a try
<civodul>(says the person who hasn't committed anything in a while :-))
<wingo>:)
<wingo>but thing is, pull requests can be a nice way to stay in development for those times when you're not committing :)
<wingo>i would love it if we could move to a workflow where my work also goes under PR's
<civodul>is it?
<civodul>my impression is that PRs are optimized for one-off contributions, but not so much for someone who wants to follow development
<civodul>though i guess there are tools and they can be customized to send notifications appropriately
<daviid>like emails ... :):)
<civodul>well, email is rather all or nothing :-)
<dsmith-work>Tuesday Greetings, Guilers
<civodul>howdy, dsmith-work!
<daviid>another problem is that these tools asks to create an account, and then they install cookes and start to track you ...
<dsmith-work>wingo: What are you working on in firefox?
<wingo>civodul: yes you can get notifications, like "send me a mail when there's a new PR or activity on a PR". it can be a bit overwhelming tho
<wingo>dsmith-work: currently, webassembly stuff. specifically https://github.com/WebAssembly/multi-value
<civodul>wingo: yeah i had that on gitlab.com and gitlab.inria.fr and it wasn't so great actually ;-)
<wingo>right :)
<daviid>wingo: i just did read about it, the presentation (60+ slides) and it seems it is not possible to maintain a gerrit WF and the 'old' WF as we have now (?) gerrit uses git, but it adds 'tons of things' and 'imposes' its workflow, so once our repos will be moved, it seems we won't be able to contribute 'the old (good :)) way' anymore, or am I wrong maybe?
<wingo>you can certainly do a normal email and git push
<wingo>there are differing degrees of how much you buy into gerritt
<wingo>like one is, "only gerrit"
<wingo>which probably isn't what we'd go for
<wingo>to be clear the current process is, to a first order, "andy pushes to git without review" :)
<daviid>well, that's the ultimate step :), you probably first did commit, locally, send a patch for review ... (i know you know ... but for the sake of our 'conversation', and compare both approach ...)
<daviid>anyway, i prefer the email wf, so i'm not being impartial here i guess :) ...
<wingo>i am not going to email all my patches, sorry :)
<daviid>i understand, but when we contribute ...
<daviid>if we could just try, but it seems already quite a lot of work just to try ...
<daviid>anyway, back to hack, g-golf idle functions leak mem, a tiny bit but steadily ... oh well, oh well
<wingo>emailed patches are as welcome as they have always been :-)
<wingo>(which is to say, very welcome, but i am bad at email :P)
<daviid>i'll look at emacs-magit-gerrit, may it solves 'everything' :)
<dsmith-work>What about patchwork?
<roptat>reading https://www.gnu.org/software/guile/docs/master/guile.html/Using-Other-Languages.html#Using-Other-Languages
<roptat>I'm wondering, can I implement my own language that way?
<roptat>well, not really a language, but I'd like to use the repl to send commands to my app
<roptat>maybe my question is about "meta-commands" for which I can't find documentation...
<roptat>to be more concrete, I'm trying to work again on my guile-torrent thing :) it uses fibers to download torrents, and I'd like to start a server and give it commands like this: ,start-torrent-server then (start-torrent "something.torrent") (pause-torrent "something.torrent") etc
<roptat>I think I can't just have start-torrent and pause-torrent be scheme procedures, because at the REPL, I'm outside of the function called by run-fiber
<roptat>actually, I can create a channel and send messages to it outside of the run-fibers call, so I think I don't need that
<roptat>but I'm still curious :)
<nly>hi roptat
<roptat>hey :)
<nly>i have used meta commands and custom repls, incidentally also in a torrent lib, inspired from yours :)
<nly>let me dig the source
<roptat>oh, so you have it working?
<roptat>I mean, you have a working guile torrent library?
<nly>nope, i am quite a ways off
<nly>i'll pick up the slack soon
<nly> https://github.com/o-nly/torrent/blob/master/torrent/repl.scm
<roptat>thanks!
<nly>this seems weirdly incomplete, i wonder where did i put the example
<nly>roptat here an example meta command https://github.com/o-nly/torrent/blob/master/torrent/bencode-reader.scm#L118
<nly>this should work like this:
<nly>at Guile repl
<nly>,bencode-reader
<nly>d4:word3:heye RET
<nly>-> (dict (str "word") (str "hey"))
<nly>i imagine you could use custom repl as in guix-monad-repl to avoid specifying the connection to the running app
<nly>meta commands can be convenient to enter such 'custom repls' at your whim
<roptat>Thanks
<roptat>That will help me a lot
<nly>:)
<nly>the documentation on the torrent lib is lacking
<nly>it has become a bencode-> s-expression thing
<nly>roptat https://o-nly.github.io/posts/torrent/
<amz3>o/
<amz3>hey, I intend to continue my work on the project that used to be called guile-r7rs.
<amz3>Do you think it will be best to change the name to something else?
<amz3>the project is a set of libraries from R7RS-large libraries.
<amz3>but since guile-3 has R7RS-small, it might lead to a confusion. I was thinking about renaming it, guile-seven.
<amz3> https://git.sr.ht/%7Eamz3/guile-r7rs
<jcowan>guile-seven-large perhaps?
<jcowan>But has R7RS-small definitely in Guile 3.0? The status page says it's being considered.
<amz3>There is this minor patch http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=2cca09126e8416e4b5d4be2b1edd0c9f15e0bffa
<amz3>also I stumbled upon conversation to include akku-r7rs-small AFAIU in guile 3
<amz3>I don't know about the define-library form tho
<amz3>also there is work to implement r7rs raise
<amz3>IIUC
<amz3>(which I still don't fully understand how they work ;)
<jcowan>By intention R6RS and R7RS exception system (as opposed to conditions) is exactly the same, and raise and raise-continuable are expressed in the same words.
<jcowan>Except that R7RS doesn't give specific condition types.
<amz3>a condition type can be any scheme object?
<amz3>s/type//
<amz3>What i know, is that they are condition predicates. Is that correct?
<amz3>in R7RS-small for port related procedures
<jcowan>Two, yes.
<jcowan>And yes a condition type can be any object in both R6 and R7RS
<amz3>sorry, to take your precious time, but what does error procedure raise as a condition?
<jcowan>Something that satisfies error?, is all we can say.
<amz3>oh ok
<amz3>by the whay, inheritance of Exception class, is the only inhertiance I do in Python code nowadays.
<amz3>s/whay/way/
<jcowan>Similarly, file-error? is basically &i/o-error-filename? and read-error? is basically &lexical?.
<amz3>so the predicate can return #t for multiple conditions?
<amz3>well, it can be, it depends on the condition and the predicate that you use, since the condition can be any scheme object, one can construct it so that it can inherit (somehow) a common error.
<amz3>That makes perfect sens.
***hugh is now known as Guest58802
<jcowan>R7rS-small has no notion of "types of conditions" independent of predicates.
<pinoaffe>is there a way to prevent a module from being loaded, or at least to "undefine" some of the things they export?
<mange>Are you trying to solve a particular issue you're having, pinoaffe?
<pinoaffe>mange: I'm just playing around with church numerals and am annoyed by the fact that the repl gives a bunch of warnings if I include a module that specifies a new definition for +
<mange>You can use something like (use-modules ((your module here) #:prefix p:)) to import things as p:+. There are some other ways to manipulate the names on import specified in the manual "(guile) Using Guile Modules".
<pinoaffe>that's not quite what I'm trying to do, tho - which might very well be impossible
<mange>What are you trying to do?
<pinoaffe>I would like to be able to use procedures with names such as + * by referring to them by those names
<mange>But you can already do that, and the annoying thing is that when you import a module that exports those bindings you get warnings?
<pinoaffe>yup
<mange>According to the manual "(guile) Creating Guile Modules" I think you can do something like (define-module (blah blah) #:use-modules (your module here) #:duplicates (last)), but I've not tried it.