IRC channel logs

2020-04-15.log

back to list of logs

<str1ngs>hello spk121
<rlb>Looks like 3.0.2 survived the buildd gauntlet: https://buildd.debian.org/status/package.php?p=guile-3.0
<mwette>nice work
<rlb>Thanks, though something went wrong with the "arch all" for the new 2.2 release that alongside the new 3.0 supports parallel dev package version installs. Have to fix that soonish: https://buildd.debian.org/status/package.php?p=guile-2.2&suite=sid
<mwette>yea -- I have had issues w/ Ubuntu install of 2.2 which has /usr/bin/guile-2.2 but not /usr/bin/guild-2.2 and I have guile-3.0 under /opt/local so havoc often ensues. GUILE_EFFECTIVE_VERSION sometimes helps. I have changed my install to build guild based on targeted guile.
<rlb>mwette: that might be my fault. Happy to fix it if we need to.
<rlb>(fault indirectly)
<rlb>oh, right, that's directly affected by the recent changes, i.e. you can keep guile-2.2-dev installed (after they're available) independent of anything else.
<mwette>reported on launchpad as #1859033
<mwette>your help is greatly appreciated!
<rlb>mwette: if they haven't changed things too much, and if you don't need the 3.0 packages installed at the same time, then you may already be able to fix your problem via "apt install guile-2.2-dev"?
<rlb>The recent changes just make it so that doing so doesn't conflict with an install of guile-3.0-dev.
<rlb>i.e. guild is in the -dev packages, not the guile-2.2 package.
<mwette>apt install guile-2.2-dev does not do it -- this is 18.04 BTW
<mwette>I've got something working so this is not a priority for me.
<mwette>I also have my own /opt/guile-rel/2.0, 2.2 and 3.0 for testing my nyacc pacakge
<rlb>mwette: might check to see what dpkg --listfiles guile-2.2-dev says...
<rlb>i.e. is guild-2.2 in there?
<rlb>Or did I misunderstand and that's not the problem...
<mwette>dpkg ... | grep guild => /usr/bin/guild
<rlb>Here's what I have:
<rlb>)$ dpkg --listfiles guile-2.2-dev | grep guild
<rlb>/usr/bin/guild-2.2
<rlb>
<rlb>and /usr/bin/guild is provided via update-alternatives
<mwette>so a Ubuntu change? BTW /usr/bin/guile-2.2 is a symlink do ../lib/x86_64-linux-gnu/bin/guile
<mwette>s/do/to/
<rlb>dpkg --version guile-2.2-dev?
<rlb>that symlink is normal, it's the unversioned paths that are managed by update-alternatives
<rlb>$ ls -l /usr/bin/guile
<rlb>lrwxrwxrwx 1 root root 23 Aug 6 2016 /usr/bin/guile -> /etc/alternatives/guile
<rlb>
<mwette>dpkg --version give dpkg version which is 1.19.0.5
<rlb>dpkg --version guile-2.2
<rlb>I meant
<rlb>sorry "dpkg --version guile-2.2-dev"
<mwette>sorry, I did that; it returns the dpkg version apparently
<rlb>sorry, don't know what I was thinking: dpkg --status guile-2.2-dev | grep -i version
<mwette>no problem; => 2.2.3+1-3ubuntu0.1
<rlb>mwette: ahh, that was changed in 2.2.4+1-2
<rlb>I thought those alternatives had been there for longer.
<rlb>So Ubuntu should pick that up whenever they move forward.
<rlb>You might be able to grab a newer debian source package or git tree, and build it yourself (after an apt build-dep guile2.2), but whether that would work without some changes to debian/control might depend on what build deps you have available. Happy to try to help if that ends up seeming useful. Suppose you might also be able to install newer versions from debian (main or snapshot.debian.org), but don't know how well that typically
<rlb>works.
<ATuin>j #lisp
<ATuin>ops
<wingo>moin
<lloda>hi wingo
<wingo>heya!
<ATuin>morning
<lloda>did you see my comment above about bitvector_ref
<wingo>lloda: not yet!
<wingo>where is it
<lloda>oh couple days ago
<wingo>feedback welcome, i have been noodling at bitvectors recently as you can see
<lloda>nvm it was just to mention a branch I started called wip-vector-cleanup
<lloda>I had done some of what you did there re: bitvectors
<lloda>put the arrays above instead of under
<wingo>ah good
<wingo>was yours a 3.0-compatible series or was it 3.1 material?
<lloda>3.1
<wingo>cool
<lloda>I want to change the interface of the 1-array functions so
<wingo>i think i found a way to get most of it in 3.0 -- the names were already quite inconsistent (e.g. bitvector-set! vs bit-set*!) so rationalizing the names is an opportunity to deprecate the old names
<wingo>just from the bitvector POV
<lloda>right
<wingo>i have no plans on the generic array interface so that is still all you
<wingo>when should we branch btw?
<lloda>there are a bunch of functions in bitvectors.c that actually take bit arrays and not bit vectors as arguments
<lloda>so I wanted to move that out
<wingo>yeah. i have deprecated most of them
<wingo>still working on it tho
<lloda>oh I didn't dare do that
<wingo>yes it was quite cheeky of me :)
<lloda>it's good
<wingo>but sometimes that's what's needed, it seemed like a good idea at the time, etc
<lloda>yeah
<lloda>I don't know about branching, afaic the sooner the better
<wingo>can do it any time
<wingo>would like an ok from civodul tho
<lloda>sounds good
<lloda>if you have time to look at wip-vector-cleanup that'd be great
<lloda>if not I'll keep rebasing on top of your patches
***rekado_ is now known as rekado
<wingo>lloda: tx for reminder
***Server sets mode: +nt
<civodul>Guix 1.1.0 is upon us! https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-released/
<mwette>contrat's to the guix team -- lot's of momentum going there it seems
<wingo>mwette: there are few functional modifiers on the bitvector interface as it is; you can bitvector-copy by make-bitvector + bitvector-copy! tho
<mwette>wingo: That's fine, but where is bitvector-copy!? It's not a in the core API.
<wingo>it certainly is!
<wingo>er
<wingo>humm :)
<wingo>good point :)
<wingo>it does exist, but as bit-set*! :-((
<wingo>terrible interface
<mwette>Ah, missed it!
<wingo>in git you would (define (bitvector-copy src) (define dst (make-bitvector (bitvector-length src))) (bitvector-set-bits! dst src) dst)
<wingo>bitvector-set-bits! is like the now deprecated bit-set*! with #t
<mwette>That seems fine to me.
<wingo>i suppose a bitvector-copy can be more efficient than that tho, as it can just memcpy instead of memset to 0 then read both vectors, logior'ing the results and writing them
<mwette>I was doing algebra on regular languages, represented as FSMs, with states represented as bits in a bitvector. When generating synchronous product of FSMs I perform a number of bitvector operations.
<wingo>i can imagine lack of efficient bitvector-copy would be irritating
<mwette>yup
<dsmith-work>wingo! That arm jit patch by icecream95 seems to fix most probelms on arm.
<wingo>most? :)
<dsmith-work>I still get a segfault every now and then.
<dsmith-work>make check passes, but get about 4 failures with JIT_THRESHOLD=0
*wingo nod
<wingo>they are deterministic for you?
<dsmith-work>No. :(
<wingo>uf :(
<wingo>well. already much better then, i should merge the thing
<dsmith-work>It seems to handle all the thumb->arm branch, jump, call with and without veneers.
<dsmith-work>And the 4byte offset alignment thing for BLX
<dsmith-work>I suspect that the segfault is unrelated.
<dsmith-work>That coolistic rr debugger is not available for arm.
<lloda>i'd be in favor of adding bitvector-copy!
<lloda>cf module/system/vm/frame.scm
<lloda>and -copy too
<lloda>i've been frustrated with the lack of regularity of copy/copy!/fill! in the various typed vectors
<manumanumanu>civodul: are there any performance benefits of switching to guile3? I remember there being questions about what it would really bring to have a JIT. I am all for it, of course, since all my programs magically got faster.
<civodul>manumanumanu: for Guix it's on the order of 10% "only" for core operations: https://guix.gnu.org/blog/2020/guile-3-and-guix/
<civodul>but like i wrote there, Guix is i/o- and gc-intensive
<manumanumanu>That's still not bad!
<civodul>it really depends on the workload
<civodul>yes!
<civodul>definitely welcome, & for free
<civodul>in Guix one of the main performance issues is the compiler speed, which hasn't changed noticeably
<civodul>also because it's GC-intensive, i guess
<manumanumanu>Thanks for the explanation!
<manumanumanu>Does guile-parallax work? Looking at the source, I doubt it.
<manumanumanu>I don't understand how it could.
<seepel>Hi Guile! I've been having a lot of fun exploring compiler output by running stuff like (compile my-exp #:to 'cps) at the repl. Now I'm interested in exploring the type inference output.
<seepel>I think I've sorted out that I need to call infer-types from (language cps types), but I'm struggling a bit to understand what the arguments mean and how they relate to each other.
<seepel>Does anyone have any tips for me? Or maybe there is some documentation I missed somewhere?
<manumanumanu>seepel: i can't help you, but if you figure it out, could you write a blog post about it? I would be _thrilled_ to be able to inspect that.
<seepel>manumanumanu: That might be a big _if_ :) But I'll try.
<seepel>Do I assume correctly that it is wingo that would have written this code?
<manumanumanu>I think he wrote the CPS-part of guile, so that would be correct
<manumanumanu>you read the comments in the file i suspect?
<manumanumanu>I like the comments with diagrams, such as at line 1480 :D :D
<seepel>I did, maybe I'll read them again
<seepel>Yes, most of the comments I've read have been along those lines, describing the input bitvectors to the constraint propogation. I think my question is much higher level. Like, how do I actually call the procedure once I have a cps intmap.
<dsmith-work>seepel: There might be some insight at https://wingolog.org/
<dsmith-work>For example: https://wingolog.org/archives/2014/01/12/a-continuation-passing-style-intermediate-language-for-guile
<dsmith-work>Wow. From 6 years ago.
<seepel>Ok, I sorted it out in the end. (infer-types (compile my-exp #:to 'cps) 0) will give me an intmap of vectors where each element in the vector is another intmap which seems to contain the bitfields for the types at the given program point.
<manumanumanu>can you translate that into something immediately useful?
<seepel>Hmmm, I don't think I can _explain_ everything, but I can dump what I have in my repl into a pastebin so there is something concrete to talk to.
<manumanumanu>I have been asking myself that for a while: what if I could get a part of what the compiler cannot infer. Say, as an optimization coach. Just knowing what can and cannot be elided would be cool (which can be understood from the disassembly probably, but I'm too stupid to read that)
<seepel> https://paste.debian.net/1140598/
<seepel>So basically I made a simple function here, and inspecting the output of infer-types has inferred the function parameter `n` to be a number ranging from -inf.0 to +inf.0
<seepel>Because I return the result of applying `+`
<seepel>At least that's what I _think_ it says :)
<seepel>manumanumanu: I have sooo many ideas for this information. One that immediately springs to mind is a much better auto-complete.
<seepel>Optimization coach is also a great idea! I was also thinking of something like that, though I was also wondering if you could build a solid linter. Also very interested in unboxing things.
<manumanumanu>cool!
<manumanumanu>Now: good night
<seepel>Good night!
<wingo>evening
<Aurora_iz_kosmos>What are the pros & cons of Records vs GOOPS objects?
<seepel>Aurora_iz_kosmos: I'd love to hear more answers as well, but one argument for records that I can think of would be that they are portable to other scheme implementations if that is something of concern.
<manumanumanu>Aurora_iz_kosmos: well, you can't do multiple dispatch on records
<manumanumanu>don't use goops records unless you want to use generics
<Aurora_iz_kosmos>Ah, that's definitely one worth considering. One-off datastructures could use either, but reuse would means GOOPS
<seepel>Is there a technical reason why multiple dispatch doesn't work on records? Or has it just not been implemented?
<manumanumanu>I don't know that, but I suspect that would mean complicating already complicated logic. goops isn't exactly trivial
<manumanumanu>I have been planning to implement a predicate-based multiple dispatch library for some time, but I never really got to it
<manumanumanu>(defmethod (add (s string?) (i integer?)) (string-append s (number->string i)))
<manumanumanu>something like that
<seepel>I've been mostly using (ice-9 match) to fill that niche myself, not perfect, but not terrible either.
<manumanumanu>probably faster than using multiple dispatch :D
<seepel>Draw back is that methods can't be dynamically extended, but that has been mostly ok for my purposes so far.
<wingo>Aurora_iz_kosmos: memory-wise they are the same. time-wise goops is a little more expensive but not terribly so. records provide more encapsulation; they aren't inheritable, accessors can be made private
<wingo>culturally records are more from the product type world, goops is more from the OO world
<wingo>also records have nice integration with `match'. that goops integration is less good is not fundamental (we could have a better, extensible match facility) but it's a consideration
<manumanumanu>it bothers me to no end that whenever I need r6rs records, they aren't compatible with match :(
<RhodiumToad>isn't that fixed in 3.0?
<wingo>manumanumanu: they are now!
<manumanumanu>OMG
<wingo>:)
<Aurora_iz_kosmos>wingo: I see.
<manumanumanu>christmas in april!
<seepel>wingo: Since you're here, do you mind if I ask what the main inspiration for the type constraint propogator is? If any?
<wingo>(records can be made inheritable fwiw, but only single inheritance)
<wingo>seepel: the original inspiration was getting a double result out of sqrt
<seepel>I've been looking into the CMUCL/SBCL code base, as well as reading some of Henry Baker's work on the subject (http://home.pipeline.com/~hbaker1/TInference.html) and would love additional resources if available.
<ArneBab>Does someone still have contact to ian? With tail call in Phase 3 of WebAssembly, a retargeting of his work WebAssembly might be doable: https://summerofcode.withgoogle.com/archive/2017/projects/6661485954596864/https://github.com/WebAssembly/proposals
<manumanumanu>there goes all my will to do any kind of work on an extensible pattern matcher
<wingo>seepel: sqrt returns a double iff the operand is a real number >= 0
<wingo>ArneBab: i had a pass at doing tail calls in spidermonkey last year fwiw -- is a little complicated but we are keeping it in the plans
<ArneBab>cool!
<Aurora_iz_kosmos>manumanumanu: oh?
<ArneBab>wingo: what’s the state of tail call for wasm in FF?
<wingo>seepel: type + range inference does allow bounds check elision in some cases. it is not as good as the "ABCD" pass that ssa people do
<wingo>ArneBab: we are taking it into consideration when making abi changes but it's not staffed atm
<manumanumanu>seepel: I have also been looking at the sbcl source! The basic maths stuff are very fast in SBCL, and it is in part because SBCL is amazing, and in part because the functions are very optimized
<manumanumanu>just look at isqrt :D
<ArneBab>wingo: so Phase 3 isn’t "almost there" for wasm?
<wingo>ArneBab: it's waiting for more implementations. & specifically that browser implementors are convinced that fast solutions are possible
<wingo>it could go to phase 4 if jsc and v8 shipped it
<wingo>but there are some politics involved
<seepel>manumanumanu: I'll admit, I haven't gotten _super_ comfortable browsing the source on my own yet. I mostly follow MacLachlan's CMUCL design paper and follow along to the mentioned source files as best I can.
<manumanumanu>seepel: https://github.com/sbcl/sbcl/blob/62abc0aa4be49de4e4296f1de731aa9d03832f57/src/code/numbers.lisp#L1357
<ArneBab>wingo: thank you for the info!
<ArneBab>wingo: but would that help get it in firefox? (that’s what I’m most interested in)
<manumanumanu>seepel: it is public domain, so I thought that I should some time have a go at porting some of these algorithms to see if they are any good in scheme as well
<seepel>I've been thinking exactly the same!
<seepel>But I'm just starting my journey, sounds like you have a head start
<seepel>From Henry Baker's paper the troubling thing is that he calls out specific problems that arise while trying to analyze Lisp-1s. But, on the other hand, it seems that the rules in all implementations I've found are much more ad-hoc than Baker presents, so maybe that would make the difference.
<manumanumanu>seepel: I have no education with computers what so ever: for all but a couple of things I do I am just throwing hours on things until it compiles :D :D
<wingo>fwiw i have found that the journey is long, it is a delight to move fast and quickly discover new things and concentrate and hack out a thing maybe, but it is very long too -- you need a lot of patience and low expectations for yourself
<wingo>otherwise you burn out early because you aren't happy with how fast things are going
<wingo>just my experience fwiw
<seepel>I can second that, I've been studying for about the last year and half just to figure out where I could possibly put some code down. Wrote my first code this week and have already had to throw out two versions.
<manumanumanu>my main benefit is that this is very much my hobby: i still feel an almost insatiable curiosity (even though getting srfi-171 into guile was pretty close to boring labour for the last couple of hours or so).
<manumanumanu>playing bassoon is work, though. Right now that is pretty boring since we are not allowed to have any live audience. Streaming isn't really the same :D
<seepel>manumanumanu: Does that mean playing bassoon is your day job?
<manumanumanu>it does!
<seepel>Oh cool!
<manumanumanu>if i would get 5 swedish krona everytime I get that reaction, I would have about 15 by now!
<RhodiumToad>heh
<seepel>Happy to be lucky number 3 :)
<manumanumanu>do we have a sneek manual somewhere?
<wingo>manumanumanu: that is a question for dsmith-work
<manumanumanu>dsmith-work: is there a sneek manual somewhere?
<manumanumanu>:D
<rlb>manumanumanu: wrt 3.0 performance, Andy's posted some bits about that a few times I think, e.g. https://wingolog.org/archives/2020/02/07/lessons-learned-from-guile-the-ancient-spry
<rlb>and some earlier posts iirc.
<RhodiumToad>I just ran some very crude timings on the little thing I wrote last weekend, and guile3 does seem quite a bit faster than 2.2
<dsmith-work>manumanumanu: send the bot "help"
<RhodiumToad>it's a solver for the countdown number puzzle that I just wrote for practice, I'm actually curious what other people's solutions would look like
<seepel>I've just realized my analysis of the type analysis in my paste bin link was incorrect. What it shows is that the inferred _return type_ of the function is _any_ scheme value between -inf.0 and +inf.0.
<manumanumanu>sneek: help
<manumanumanu>dsmith-work: that help message needs some polish :P
<seepel>In case anyone is trying to follow along at home :)
<dsmith-work>Not much in there is it..
<manumanumanu>it replied in a query
<manumanumanu>but it didn't tell me anything useful :D
<manumanumanu>I want to tell it to tell stis something when he shows up
<RhodiumToad>that's "later tell <person> ..."
<dsmith-work>manumanumanu: <botname>: later tell <nick> whaever you want
<dsmith-work>Well. This is exciting:
<dsmith-work>Unbound variable: for-each
<manumanumanu>sneek: later tell stis Could you help me port 3 seemingly simple syntax-parse things from racket? I am porting parsack to guile, and that is about the only thing left
<sneek>Okay.
<manumanumanu>dsmith-work: someone else had that problem!
<manumanumanu>specifically with for-each
<dsmith-work>There was something very similar that happened when I started running it on 3.0
<dsmith-work>I think I just open-coded whatever it was that somehow went away.
<manumanumanu>maybe that is waht I am thinking about.
<dsmith-work>wingo: Any idea what could possibly make guile forget about "for-each" ?
<dsmith-work>sneek: guile help cons
<wingo>dsmith-work: that does not sound like something i could understand! except maybe you are in a module that #:export (for-each)
<wingo>so it makes a fresh local binding that's unbound
<wingo>or you're in a pure module
<dsmith-work>Hmm. Nothing like that I can see.
<RhodiumToad>would importing a module that accidentally exports an unbound for-each also do it?
<wingo>that could do it, yes
<wingo>dsmith-work: i know you've been doing boot issues recently, i assume it's not before for-each is defined
*wingo zzz now tho
<wingo>à demain
<dsmith-work>No, this code has been running since 3.0
<manumanumanu>me too! stay safe, everyone. wash your hands
<dsmith-work>sneek: uptime
<dsmith-work>!uptime
<sneek> 16:24:42 up 22 days, 4:57, 1 user, load average: 0.00, 0.01, 0.05
<dsmith-work>sneek: version
<sneek>Sneeky bot running on Guile version 3.0.0 using bobot++ 2.3.0-darcs
<dsmith-work>The thing is, for-each is only used in about 3 places. And the same code has been using for-each for years. No redefinitiosn or pure modules.
<dsmith-work>sneek: botsnack
<sneek>:)
<dsmith-work>sneek: seen wingo ?
<sneek>wingo was here Apr 15 at 08:24 pm UTC, saying: à demain.
<dsmith-work>goodbot
<daviid>Aurora_iz_kosmos: adding to what has been said, wrt goops vs records, a record is (just) a datastructure, goops is a language
<dsmith-work>goops has generic methods
<dsmith-work>Or is that generic functions?
<daviid>dsmith-work: is this bot code published somewhere?
<dsmith-work>No. :(
<daviid>dsmith-work: how about uploading it to sourcehut or svannah if you have an account ...
<daviid>or notabug if you don't like sourcehut ...
<dsmith-work>I need to look into license stuff. It's another bot ported to guile and bobot
<dsmith-work>sneek: help
<dsmith-work>Ok! Help is working. Changed a for-each to a named let
<daviid>dsmith-work: scary
<daviid>this for-each not working 'anymore' :) I mean
<dsmith-work>Indeed. I wonder if bobot it hiding it somehow.
<dsmith-work>But it's avalaible in some places..
<dsmith-work>Ahh! Maybe because I am using srfi-1 ?
<dsmith-work>That replaces for-each