IRC channel logs

2021-05-31.log

back to list of logs

***Noisytoot is now known as noisytoot[x]
***noisytoot[x] is now known as Noisytoot
***RhodiumToad_ is now known as AndroidToad
***AndroidToad is now known as RhodiumToad_
<tohoyn>sneek: botsnack
<sneek>:)
<RhodiumToad>moo
<taylan>sneek: botsnack
<sneek>:)
***apteryx_ is now known as apteryx
<ManDay>No macros involved, I get this error 'In procedure car: Wrong type argument in position 1 (expecting pair): #f' on a line which reads merely '(complete-branches pd-branches completion)'. If that's not weird enough, if I make that line read '(complete-branches pd-branches (identity completion))' the error is suddenly marked on the line before (which reads '(if (or (dep.eq? branch (car parent-cp))
<ManDay>(member branch downstream dep.eq?))')
<ManDay>Anyone mind to make sense of this?
<ManDay>btw: same happens if I put the (identity) around pd-branches.
<ManDay>well, apparently <parent-cp> in the (car) on the line before is #f
<ManDay>Which explains the problem, but not this weird as hell error message
<taylan>ManDay: which Guile version is this?
<ManDay>3.0.4
<ManDay>uh oh, lemme guess, i'm direly outdated?
<taylan>no that's very recent :)
<ManDay>oof
<taylan>so if I understand correctly, the line number of the error is reported wrong? I would file a bug report, ideally after producing a minified self-contained example that showcases the bug.
<ManDay>ok, fair answer. I was afraid I'd get some intricate explanation why despite all odds reporting weird lines actually made sense :D
<ManDay>i'll try to strip that down when I have some downtime
<dsmith>ManDay: Might want to try it on git (or at least 3.0.7). Just to make sure it hasn't been fixed already.
<ManDay>yeah that's true, i'm sorry you have to point it out ;-/
<ManDay>i'll try it first
<iwan>hello
*dsmith waves
<iwan>anyone interested in Guile-Elisp here?
<drakonis>sure why not
<drakonis>getting guile on emacs, is it?
<iwan>hmm, more like emacs on guile
<iwan>I recently submitted two Elisp reader bugs, but no one replied yet :^(
<drakonis>oh i see
<lispmacs[work]>hi, I'm trying to create a child process and get textual ports to its input and output. however, with the open-pipe command, it seems that you instead run the process and it inherits your current i/o ports. So, if I keep separate my guile program std i/o from the child process i/o, I guess I need to create some ports first and make them the current i/o ports. But I'm not sure how to go about that
<iwan>set-current-input/output-ports I guess
<lispmacs[work]>iwan: that seems like about half the puzzle. but I would need to create i/o ports first...?
<lispmacs[work]>some string ports...?
<iwan>maybe file ports? smth in /tmp or /log
<dsmith>iwan: How manye years have you waited? ;^}
<lispmacs[work]>iwan: if the process is reading from a file in /tmp, will I have a problem with the process getting an eof when I am not feeding data to the tmp file?
<iwan>dsmith: for what?
<lispmacs[work]>i would need to create a FIFO file...?
<dsmith>iwan: elisp reader bugs you mentioned.
<dsmith>Often it takes a while before the guile devs get to bugs. Even with patches.
<dsmith>Usually it's just before a release, there is a flurry of patches applied.
<iwan>they are pretty easy tho
<iwan>bugs, not patches
<dsmith>Just sayin, don't be surprised if no response for days or weeks (or months or..)
<lispmacs[work]>seems like there must be a better way to do it, but I see now I could create some FIFO files with mkfifo, open them as files, and then open the processes with those set as default ports
<iwan>can you give a more detailed example?
<lispmacs[work]>I don't think so
<pyveteran>Hi
<iwan>hi!
<pyveteran>Why should I learn Guile?
<lispmacs[work]>it seems kind of funny that guile has a built-in function for generator random coordinates for the surface of a sphere. Is there an interesting story behind that...?
<mfiano>also volume of a sphere
<lispmacs[work]>is there an easy way to convert a number to a hex string?
<drakonis>pyveteran: why not
<lispmacs[work]>built-in?
<iwan>yep
<drakonis>also that's a terrible question
<drakonis>i've seen it a hundred times
<iwan>(format #f "~x" ...)
<lispmacs[work]>iwan: thanks!
<pyveteran>drakonis: ok thanks, I'll try to figure out by myself.
<dsmith>lispmacs[work]: There is also number->string
<dsmith>The second arg is the base.
<lispmacs[work]>dsmith: okay, thanks, I didn't know that one had a radix parameter
<dsmith>But if you want more control, format
<lispmacs[work]>MORE CONTROL!!!!
<apteryx>uh; (mkstemp! "/tmp/dbus-send-output-XXXXXXX") -> string is read-only: "/tmp/dbus-send-output-XXXXXXX". Am I using it wrong?
***lispmacs[work] is now known as forthmacs[work]
<forthmacs[work]>wha HA HA!
***forthmacs[work] is now known as lispmacs[work]
<dsmith>apteryx: Yes. A string literal is read-only.
<drakonis>pyveteran: to be fair, its such a common question that people expect to be answered by simply waltzing into a channel and hoping for a satisfying answer
<apteryx>dsmith: according to http://osr507doc.sco.com/cgi-bin/info2html?(guile.info.gz)File%2520System&lang=en, mkstemp! takes a TMPL, which should be a string
<apteryx>ah, perhaps mutable string objects are a thing, I've never used those.
<dsmith>scheme@(guile-user)> (mkstemp! (string-copy "/tmp/dbus-send-output-XXXXXXX"))
<dsmith>$2 = #<input-output: /tmp/dbus-send-output-XMmrrVl 13>
<apteryx>I see! Thanks.
<dsmith>apteryx: A string literal is immutable. (or should be!)
<iwan>@dsmith have you ever contributed to emacs or guile?
<dsmith>I've submitted a few small patches over the years. Long ago, contributed a patch to dos emacs so it could use the windows clipboard.
<iwan>your nickname seems familiar, but I can't remember where I saw it
<dsmith>Well, "smith" is a *very* common name.
<iwan>yeah, I know, maybe I just remembering time when #guile was on freenode
<dsmith>Been there a while. I started when there was about 6 people in the channel. I remember how cool it was to see it double to 12!
<taylan>heh :)
<taylan>iwan: I responded to a few Elisp reports recently, dunno if yours was under them
<iwan>a-ha, your name is the same as nick
<taylan>iwan: oh, I see you sent a patch earlier today. well I've sent some patches two weeks ago and am still waiting, so better to be patient :P
<iwan>nice to meet you, Taylan
<iwan>I was hoping to meet you or Maxime Devos here
*holomorph checks to see how long the wip-elisp branch has been dormant
<dsmith>There has been some recent activity. bipt has a new nick (can't remember right now) and was on here a few days ago.
<dsmith>sneek: seen bipt?
<sneek>bipt was last seen in (here?) 9 months ago, saying: i saw that your guile-emacs package made it into a guix release :).
<taylan>iwan: happy to hear from another person who's interested in Guile-Elisp. sadly progress is slow, as everyone's quite busy
<ManDay>Sorry to come back with more traceback trouble, but I can't fathom how guile can simply not mention stackframes. This for example http://dpaste.com/HAR22QBAH drives me mad to have to deal with this all the time.
<taylan>bipt's new nick is robin, alternatively terpri
<dsmith>taylan: Ahh yes. Thanks
<dsmith>sneek: seen terpri?
<sneek>terpri?, pretty sure was seen in #guix 10 days ago, saying: so far, it's great.
<dsmith>sneek: seen robin?
<sneek>Not as far as I can remember.
<taylan>dsmith: robin is in the channel :D
<ManDay>How am I supposed to find that error with that kind of debugging information?!
<ManDay>I'm at a total loss!
<taylan>ManDay: 'map' takes two arguments. since the (lambda ...) will certainly not be #f, it must be 'pivots'
<ManDay>taylan: Yes, I realize that <pivots> has the wrong type. But how am I supposed to find the error?!
<ManDay>pivot->strings is called all over the place in my code
<iwan>dude, I have had exceptions during printing stacktrace
<ManDay>so have I
<ManDay>(but that was fixed)
<taylan>ManDay: from the fact that it points at idg.scm line 61, and that this line is the start of the 'map' call, which has two arguments, one of which is evidently #f as the error message says
<ManDay>taylan: idg.scm line 61 IS that map. that's what I marked in the paste
<ManDay>but where is pivots->string called from!?
<ManDay>i can't belive I have to ask that question. are you not familar with stacktraces from normal compilers?
<taylan>ManDay: isn't it in idg.test.ss line 27?
<ManDay>taylan: no. line 27 in idg.test.ss calls idg.recurse
<taylan>is idg.recurse a macro?
<ManDay>no
<taylan>oh nevermind, idg.recurse is in the stack trace
<taylan>ManDay: well the pivots->string call ought to be somewhere in the body of idg.recurse then?
<ManDay>many many times
<dsmith>ManDay: How about move that lambda into it's own define. From a repl (or geiser) try feeding it with what you expect the arg to be.
<ManDay>dsmith that function (pivots->string) is fine.
<dsmith>There has been a *lot* of work on the compiler lately. Bound to be some bugs.
<dsmith>AH
<ManDay>ok, i'll try the master version anyway (tomorrow)
<ManDay>maybe that'll help it
<ManDay>dsmith what is geiser?
<dsmith>Emacs interface to Guile (and some other Schemes)
<dsmith>It's nice to be able to C-x C-e to evaluate an expression.
<taylan>not sure if updating from 3.0.4 to 3.0.7 will make much of a difference
<ManDay>i rather have working stacktraces ;-/
<dsmith>Yeah.
<dsmith>Hmm.
<taylan>ManDay: is the code uploaded somewhere?
<ManDay>nah
<ManDay>there is a macro involved, though
<taylan>I'd like to understand better what's going on...
<dsmith>I wonder if using less optimization would provide better backtraces?
<ManDay>it encapsulates the entire body of idg.recurse
<ManDay>dsmith I've written that thing, I ll try it : http://dpaste.com/ELNB5TP3T
<ManDay>Not sure what else I can do to prevent optimization
<taylan>could you paste the entirety of idg.scm and idg.test.ss?
<ManDay>ironically, the macro which encapsulates the body is there to help me debug...
<ManDay>taylan: you mean in a state that you can run it? or just look at it?
<taylan>just look at it
<ManDay>ok, one sec
<taylan>the state that produced that error would be ideal of course :)
<ManDay>idg.test.ss is really nothing though
<dsmith>There is a way to pass an -O1 or -O2 to guild compile. Not sure if there is a way to do that within a repl.
<ManDay>can't one upload file to github gists?
<ManDay>dsmith I'm not using the repl.
<taylan>gist works, any pastebin works just as well IMO
<iwan>termbin.com is my favorite
<ManDay>i want the paste to disappear after a while
<dsmith>sneek: paste?
<sneek>Someone once said paste is https://paste.debian.net
<dsmith>I think that one goes away after a while.
<iwan>it'll disappear after one month
<ManDay>i set it to 1 h
<ManDay> https://paste.debian.net/hidden/7dffd798/
<ManDay>by then we'll have that figured out either way :-P
<ManDay>see the dbg-* macro at the beginning
<ManDay>that's the only non-functional or macro thing there is
<ManDay>idg.test.ss coming right up
<taylan>this is not the state of the file when that stack trace was produced though, right?
<ManDay> https://paste.debian.net/hidden/4aedcfb8/
<ManDay>taylan: yeah, line numbers don't match
<ManDay>l61 -> l31
<taylan>did you mean 37?
<ManDay>ah yeah, my eyes...
<taylan>no problem. so, I think pivots->string might be getting inlined or something...
<taylan>it's certainly a crappy stack trace, no argument there
<ManDay>thanks ^^
<ManDay>i just wish I could turn off all those optimizations
<ManDay>so I guess I'll have to try guild manually
<ManDay>gosh, I wish `guile` could simply pass -O0 to guild
<taylan>you could also see what the interpreter does, by executing the file like 'guile --no-auto-compile foo.scm' after deleting the cached .go file
<ManDay>since compiling it isn't as easy as `guild compile idg.scm` I think I'll postpone this entire operation to tomorrow (which starts in about half an hour anyway)
<taylan>ManDay: it should be as easy as that, actually
<taylan>possibly with an -L thrown in there, just like when executing the file with 'guile'
<ManDay>ah yeah -L was needed
<ManDay>ty
<taylan>and you might want to add a check for the 'pivots' argument to the beginning of pivots->string to give a marginally better error
<ManDay>ooooh
<ManDay>that's much better now!
<ManDay> 142:2 3 (idg.recurse ((#<procedure 7f90818c8100 at ice-9…> . #)) …)
<taylan>like (when (not pivots) (error "pivots->string called on #f"))
<ManDay> 148:46 2 (vary-conjunctions -1 #f)
<ManDay> 61:2 1 (pivots->string #f)
<taylan>yeah I guess a lot was being optimized out there!
<ManDay>i'll file a bug for guile to accept -O0, this seems awefully important
<ManDay>thanks a lot!
<ManDay>i had tried to disable optimizations in the case of messy stacktraces in the paste but it had not helped
<taylan>there might be an environment variable for that, lemme check...
<ManDay>i didn't expect improvement this time
<ManDay>*in the past
<taylan>hmm I think there was just an env var to force fresh recompilation
<ManDay>yes, i have also searched for any method to pass -O and didn't find any
<ManDay>everything works now. many thanks!!!
<taylan>can't even find that now, maybe I was dreaming. anyway, I guess an option to 'guile' and/or an env var to determine the optimization level might be good.
<taylan>yw!
<ManDay>gn
<dsmith>ManDay: What made it work? Disableing optimizations?
<dsmith>Ah, left
***iwan is now known as ubah
***ubah is now known as iwan
***iwan is now known as ubah
***ubah is now known as iwan
<mattrw>sneek later tell ManDay I used to effectively set -O0 in guile using https://paste.debian.net/1199535/ and running (noopt) but I think that broke recently (3.0.X, X > 2 ??)
<sneek>Okay.