IRC channel logs

2022-11-30.log

back to list of logs

<old>whereiseveryone: Should I learn CL?
<old>I heard it's all powerful and it's like Scheme on steroid
<old>But there's thing that turn me off. Like the `-p` predicate convention instead of `?` ..
<old>dsmith-work: Ehh the Xilinx toolchain are the worst
<RhodiumToad>learning new languages is rarely harmful
<old>Everything TCL is not that bad. It's actually better than working with their awful Vivado
<old>RhodiumToad: Agree. It does take a fair amount of energy though
<old>Just looking at the advanement of cow_2001 the past days, I don't feel I'm ready to do that again for CL. But maybe the learning curve will be less steep this time since I know Scheme?
<RhodiumToad>I've played around to a greater or lesser extent with several lisps over the decades, and I think a lot of the learning carries over
<RhodiumToad>though one does have to be aware of the lisp-1 vs lisp-2 distinction
<RhodiumToad>I do prefer hygenic to non-hygenic macros
<old>lisp-1 vs lisp-2? Could you elaborate?
<RhodiumToad>lisp-1 means that symbols are bound to only one value, lisp-2 means that they have separate bindings to values and procedures
<old>Well I'm fairly used to C macro, so I can live with non-hygenic, but I too prefer the hygenic variant
<RhodiumToad>scheme is a lisp-1
<RhodiumToad>CL is a lisp-2
<old>oh like Elisp is lisp-2?
<old>Becauseo f #'procedure ?
<RhodiumToad>yes
<old>okay. Is there other subtilty like this?
<RhodiumToad>I admit to not knowing CL very well. most of my experience is with elisp and a number of more fringe dialects
<old>okay
<RhodiumToad>on balance I think I prefer lisp-1
<wonko-the-sane>scheme@(guile-user)> (apply = (list 0 0))
<wonko-the-sane>$1 = #t
<wonko-the-sane>scheme@(guile-user)> (apply = (list 0 0 0))
<wonko-the-sane>While compiling expression:
<wonko-the-sane>unbound var #{v 159}# ()
<wonko-the-sane>scheme@(guile-user)> (define list list)
<wonko-the-sane>scheme@(guile-user)> (apply = (list 0 0 0))
<wonko-the-sane>$2 = #t
<wonko-the-sane>seems pretty quirky
<rekado>wonko-the-sane: this looks like a bug
<wonko-the-sane>i dare say
<lloda>that is p bad
<wonko-the-sane> https://paste.rs/AIa
<sneek>Welcome back dsmith
<dsmith>sneek, botsnack
<sneek>:)
<sneek>wb dsmith!!
<mirai>hi, how does (ice-9 match) work for matching against pairs? More specifically, a list of pairs
<mirai>The manual section for it doesn't say anything about pairs.
<rekado>mirai: is there anything in particular you’d like to know?
<mirai> https://paste.centos.org/view/71608611
<mirai>I'd like to write a procedure that would check if a list is an association list
<mirai>I played a bit with the code snippet I pasted above in the repl and maybe I'm misunderstanding "scheme" but I am getting some befuddling results
<rekado>wonko-the-sane: (parameterize ((default-optimization-level 0)) (compile '(apply = (list 1 1 1))))
<rekado>this works
<rekado>going to higher optimization levels fails
<elevenkb>is there a text editor/interactive programming environment scriptable in guile?
<lloda>looks like a bug around primitives.scm:571 and/or peval.scm:1294. I don't understand that well enough to see it
<lloda>please file a bug wonko-the-sane
<spk121>elevenkb: not really. Mostly people use emacs to interact with guile.
<spk121>I mean, there are a couple of projects that sort of count: there was one a port of emacs that used guile
<spk121>And a port of zile that used guile
<spk121>But nothing common and well maintained
<mirai>is the behavior described in the paste above working as intended? (such as a list of 2 elements being a pair)
<spk121>I guess libfive studio is indeed an IDE scriptable in guile, but, it specializes in solid modeling
<lloda>mirai: '(1 2) is the same as '(1 . (2 . ())). Every list is a pair of head and tail
<mirai>lloda: oh right
<mirai>so nothing funny is happening in that part
<mirai>what about the 'free-form-args?' procedure? Is it actually matching lists?
<mirai>How should I get it to match pairs instead?
<lloda>(define not-pair? (compose not pair?))
<lloda>(match '(1 . 2) ((a . (? not-pair? b)) 'ok) (x 'no))
<lloda>?
<lloda>idk maybe there's a better way
<mwette>(match exp ((a . (b . c)) (list-handler)) ((a . b) (pair-handler exp)))
<sneek>dsmith-work: wb :D
<dsmith-work>Hey
<dsmith-work>sneek: botsnack
<sneek>:)
<sneek>wb dsmith-work
<dsmith-work>sneek: botsnack
<sneek>:)
<sneek>Welcome back dalepsmith[m]!!
<sneek>wb dsmith-work
<haugh>Are projects managed with guile-hall considered, I don't know, "community standard?" I was just looking at guile-json and, having no real experience in C, I don't even know where to begin to understand this build tooling.
<haugh>On the surface, hall looks like a dream come true for me, but I'd like experienced opinion
<dsmith-work>The whole "guild" hall thing never really caught on. Seems guix is what all the cool kids do.
<haugh>So if I want code to (eventually) be considered for inclusion, what kind of obligation do I have to understand or interface with the autotools ecosystem?
<dsmith-work>About CL: I'd like learn it too, but it just has this funky feel to it. UPPER CASE. -P for preficates, Lisp-2, etc. Scheme just seems more elegant.
<daviid>dsmith-work: i think haugh is talking about https://gitlab.com/a-sassmannshausen/guile-hall/, which is a excellent option to start a guile project, for pure sceme code 'only' (no C code, and no C lib depenendcies) - dsmith-work maybe you confused this with the 'old' guild hall https://github.com/ijp/guildhall ...
<daviid>haugh: https://gitlab.com/a-sassmannshausen/guile-hall/ ... go for it - it will 'transparently support the GNU build system', which fundamental if you target other distro(s) (then guix)
<dsmith-work>daviid: Yes, I think you are right. Sorry about that.
<daviid>iirc, it is even recommended in the guile manual somwehere, for pure scheme code (no C code, no C lib dependencies)
<daviid>dsmith-work: np!
<haugh>guild is also recommended (4.6, 6.18.5)
<daviid>haugh: guild is part of guile ... nothing to do with hall or any other 'external' project management and building tools ...
<haugh>Okay, that makes more sense
<daviid>anyway, i shimmed in to rescue https://gitlab.com/a-sassmannshausen/guile-hall/, but i have to go afk -
<haugh>* waves
<haugh>dsmith-work, are you aware of any "major" Guile packages managed exclusively with Guix? I also asked this over in #guix but I know a lot of those folks aren't really guilers
<flatwhatson>haugh: what do you mean managed "exclusively" with guix?
<flatwhatson>there are at least a few of us working on guile projects using guix
<flatwhatson>haugh: chickadee is a good example of a guix-first guile package: https://git.dthompson.us/chickadee.git/tree/
<haugh>flatwhatson, I'm not sure exactly. I'm trying to use as little software as possible. I can see that the Guile module system encourages its own project structure (with file path naming, re-export, and friends) such that the whole "autotools ecosystem" might be unnecessary for "pure" use-cases.
<flatwhatson>it is indeed!
<flatwhatson>a minimal setup for me is a .envrc which sets up dependencies with eval $(guix shell ... --search-paths)
<flatwhatson>a more advanced setup is to write a guix.scm to describe the package, and call that from the .envrc
<haugh>Let me try to grok chickadee's guix.scm before I spout off more. dthompson previously linked me here for his inotify lib and it looks to me like an exemplary project overall
<haugh>flatwhatson: okay, very interesting
<flatwhatson>haugh: guile-gemini is a bit more minimal, no autotools, though i wouldn't claim it's a "major" guile package :) https://gitlab.com/flatwhatson/guile-gemini
<haugh>:)
<haugh>Are you involved with guile-haunt? It would be cool if Haunt could export a gemini site
<haugh>oh that's also dthompson, wow
<flatwhatson>guile-gemini implements the network protocol, not the markup side of things
<flatwhatson>i would like to play with that stuff more but it's on the back-burner for now
<haugh>cool!
<haugh>I'll remember to ask you about fibers later
<flatwhatson>sure! happy to help :)
<dthompson>hello :)
<haugh>dthompson, maybe it would be faster to read a list of notable guile projects you _didn't_ write
<haugh>What specifically do you use autotools for? Does it change the structure of your testing?
<dthompson>haugh: autotools handles figuring out what the computer performing the build has available so it can use those things or present an error message if they are missing, it handles compilation via make, and also running tests via make.
<dthompson>on the maintainer side of things, it also builds release tarballs.
<dthompson>in other words, it provides the standard ./configure && make && make install process
<dthompson>(switching networks, might lose connection briefly)
<mwette>flatwhatson: You know fibers? If so, I have a Q. With #:hz 0 and #:install-suspendable-ports? #f, I've been trying to set up a repl-server as a task. I've set the socket to non-blocking (via fcntl magic) and added yield-current-task to before-read-hook. Sound right? Do I need to do something with setvbuf?
<flatwhatson>mwette: i've only used it in combination with suspendable-ports, and haven't tried to integrate with a repl
<flatwhatson>setvbuf is mostly about optimizing reads and writes, it shouldn't make the differnce between working or not
<flatwhatson>if you want it to work nicely, where that task will idle until there's data available, suspendable ports make that easy
<flatwhatson>if that's too intrusive, you could set your port non-blocking and yield on EAGAIN/EWOUDLBLOCK yourself
<flatwhatson>the trick then is scheduling it to wake up once data is available to read
<mwette>I'm using schedule-task-when-fd-readable, hoping that will work. I have another task like that, but things hang. If I use suspendable ports, do I need hz > 0 for that?
<flatwhatson>no, i don't think so. i/o scheduling should be completely separate from pre-emption of tasks
<flatwhatson>schedule-task-when-fd-readable sounds like it should do the job, that's what fibers uses internally for its suspendable ports read waiter
<flatwhatson>mwette: you might be able to just steal these: https://github.com/wingo/fibers/blob/master/fibers.scm#L61
<old>haugh: I do have a configure script entirely written in Guile
<old>It support export of confiuration to C and Makefile. It also generate template file *.in
<haugh>dthompson, this fits with the rest of what I know. You access the GNU Build System with Guix. I guess I'm wondering if Guix has evolved enough to allow me to completely avoid it.
<haugh>old, oh yeah, hook that up!
<haugh>old, btw I've got a good idea of how to factor the heredoc module but it's currently in shambles as I'm learning SRFI-64 testing, the new exception objects, and the different ways people structure guile projects
<flatwhatson>haugh: there is also guile-build-system, you don't need gnu-build-system for pure scheme projects
<haugh>ohohohoho this is new
<dthompson>yes, that is an option.
<flatwhatson>see the guile-gemini/guix.scm ;)
<haugh>FANTASTIC, this is the W solution to my XY problem :)
<dthompson>I use the autotools because most people who are used to compiling stuff from source are used to it and despite how awful it is, it's still better than everything else, somehow.
<flatwhatson>i think when you have texinfo manuals and unit tests and want to produce tarballs, it starts to make sense
<dthompson>yes, definitely.
<dthompson>my more serious projects (for some definition of "serious") have those things so autotools is easy enough once you know the copypasta to make it work
<dthompson>I basically figured out everything by copying things from guix's autotools setup. never would have figured this nonsense on my own.
<haugh>dthompson I'm glad to hear someone experienced admit that. It's horrifying to me, though I understand that in my ways the hairier parts are automated away.
<haugh>s/my/many
<dthompson>I would argue that almost no one understands everything that's going on with it. it's a giant mess.
<dthompson>there are build systems with much better developer interfaces, but they all lack crucial features imo
<haugh>All I really want to do is run SRFI-64 tests post-installation with some kind of hook on failure. My end goal is to deliver my clients a system that can auto-update with rollback if any tests fail.
<haugh>I understand this might be getting offtopic for #guile tho
<old>there's probably more fingers on my hand than there are people that understand autotools internal inthe world
<flatwhatson>we just need to Rewrite It In Guile
<old>I'm kind of doing something like that ..
<flatwhatson>riig something up ;)
<old>It's a part time project, but I do have things figured out
<old>Build system are complex beasts though
<flatwhatson>putting it mildly
<old>haugh: https://git.sr.ht/~old/libpatch/tree/master/item/configure
<old>This is the configure script of my main project, libpatch
<old>I use GOOPS + some syntax sugar to define configuration option
<old>I need to implement a option -> long-opt for nicer CLI arguments. Right now it's a hack
<old>But the idea is that this configuration script can be copy/paste in other projects. No need of support from the distro, expect for Guile itself
<old>I also try to follow the configure convention
<flatwhatson>this is pretty neat!
<old>There's also ofc custom value for libpatch in there. But that's the downside of having this file copy/paste
<flatwhatson>copying a file between projects becomes a pain for maintenance. IMO it would be better to have something like autoconf which compiles this configure script from the "authoritative" sources
<flatwhatson>so keep it as a dev dependency. i guess this is the idea of something like guile-hall
<old>Sure. But my fear is that other distros are not Guile friendly
<old>Look at fedora .. you have gnutls and Guile. That's is it
<old>So I try to keep the Guile's library dependcy at minimal
<old>But it would be possible to have a bootstrap script I guess
<old>that fetch the configuration script yes
<old>Is that what you meant?
<flatwhatson>or assemble it, so it can be maintined in a more conventional project structure
<old>Ah yes that would be the best
<flatwhatson>this is common for some header-only C++ libs, for example
<flatwhatson>they produce that one monsterous header by concatenation
<cow_2001>learned of #guile-steel
<cow_2001>good(er) things are on the horizon!
<flatwhatson>over the horizon, perhaps :)
<daviid>sneek later tell tohoyn I switched proxy instances memory management to use toggle references, this is a major step (on the devel branch, but I shall merge 'eveything' to master very soon), so please pull, run the make danse ... happy g-golf :)
<sneek>Will do.
<spk121>ACTION made an msix of guile. lol
<wingo>moo
<lloda>hi wingo
<lloda>did you see the bug with (apply = (list 0 0 0))
<wingo>o/
<wingo>no i did not see that bug, link?
<lloda>wonko-the-sane reported it on irc yesterday, but didn't file a bug
<wingo>i get a compile-time error
<lloda>yeah
<wingo>appears to be a peval bug
<lloda>i tried to figure it out yesterday but it was over my head
<wingo>i am doing constructive procrastination about something so i would be happy to look at it ;)
<lloda>:)
<wingo>the problem is that the transformation of (apply = (list 0 0 0)) to (= 0 0 0) happens in peval, which then calls out to primitives.scm which expands it to (let ((t (= 0 0))) (if t t (= 0 0)))
<wingo>but, peval wants to know about all lexical variables in the source program before it does anything, and requires that any lexicals introduced by the peval be explicitly added
<wingo>and the lexical t added by expand-primitives isn't introduced in that way.
<wingo>er
<wingo>flubbed the expansion, but anyway you know what i mean
<wingo>annoying
<lloda>is that what with-lexicals is supposed to do? I went as far as expand-eq but i was just looking for some obvious thing like a missing argument or something
<wingo>yes with-lexicals will expand to a tree-il <let> with fresh lexicals
<wingo>i think peval probably needs to revisit the result of expand-primcall to record any freshly introduced lexicals
<wingo>a call to build-var-table i guess...
<wingo>interestingly that particular primcall expansion is bogus :)
<wingo>scheme@(guile-user)> (= 0 1 (error "hey"))
<wingo>$1 = #f
<wingo>hilarious
<lloda>oof
<wingo>lloda, wonko-the-sane: fixed
<lloda>thx a lot wingo
<civodul>hey comrades, any objection to removing https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref ?
<civodul>no? ok
<civodul>:-)
<civodul>seriously, i'm leaving a lil'bit more time
<civodul>but i feel we should remove it because people keep stumbling upon them
<lloda>iirc there are still some people who depend on that. But I'd add a big fat warning to the pages saying This Is Not Current Guile
<civodul>we're always going to break someone's workflow
<civodul>but we're going to fix the workflow of a large number of people
<civodul>*larger
<lloda>i like how cmake doc does it. You're always aware of the version. I understand texinfo isn't set up for that. I agree on the whole you're probably right
<ekaitz>civodul: leaving a warning an a link to the current docs might be best
<ekaitz>civodul: but speaking of my experience, the older guile docs have a better ranking in the search engines than the newer ones and I always reach the wrong one
<lloda>yeah i think that's the problem right there
<ekaitz>having a link to the correct page of the newer docs might help, but idk if that's easy to do
<spk121>I say get rid of it since GnuCash and LilyPond have both moved on to Guile 2.x.
<spk121>Though 1.8 was the easiest Guile to debug. I rather miss that.
<civodul>if GnuCash and LilyPond have moved away from it, that's another argument
<civodul>1.8 has been unmaintained for 15 years or so anyway
<civodul>i agree that links to the current version would be nice, but we'd need to postprocess the HTML or something
<civodul>so... not for today
<spk121>civodul: to be fair, the fact that it unmaintained was an intentional choice you yourself made, since TTN was willing to step up and maintain it and you told him not to
<spk121>but it is ancient, so get rid of it
<civodul>spk121: i think ttn offered to step up long after we had moved on though
<civodul>but anyway, i don't mind being designated as the culprit
<civodul>lemme remove the dust off CVS so i can delete those pages
<civodul>this is referenced from https://www.gnu.org/software/guile/learn/
<civodul>even 1.6 :-)
<lloda>there are also lots of old clones of the doc on various sites that google loves to show to you before the official site
<civodul>terrible
<civodul>i ended up adding a warning: https://www.gnu.org/software/guile/docs/docs-2.0/guile-ref/Introduction.html
<civodul>low tech
<dsmith-work>UGT Greetings, Guilers
<dsmith-work>This is probably a better link https://courses.cs.washington.edu/courses/cse341/99su/lectures/scheme/index.htm
<civodul>"Your browser does not support frames. Try Internet Explorer 3.0 or later or Netscape Navigator 2.0 or later."
<dsmith-work>For the Greg Badros link near the bottom of https://www.gnu.org/software/guile/learn/
<civodul>sure, i'll try
<civodul>uh
<dsmith-work>YEah, very 90's
<civodul>what was the name of that tool we used for slides?
<civodul>mg?
<civodul>something like that
<civodul>should we keep this link?
<civodul>the contents look good, but the form might give a bad impression
<civodul>dunno
<daviid>civodul: fwiw, I'd remove that link and point to https://scheme.com/tspl4/ instead
<civodul>daviid: good idea, done!
<dsmith-work>Ooo! That's online now? (I have a paper copy)
<dsmith-work>Learned a lot from that book.
<dthompson>dsmith-work: same! cool that it's online now. it came in handy when I wanted to know how to implement letrec in a simple way recently.
<dsmith-work>sneek: botsnack
<sneek>:)
<daviid>civodul: I just noticed, the learn page misses a 'Revised 6 Report on the Algorithmic Language Scheme', is this intentional?
<daviid>oh, my bad, it preceedes te other entries, forget this 'noise' :)
<daviid>*preceeds
<daviid>civodul: I'g get rid of the word 'recent' in the The Revised6 Report on the Algorithmic Language Scheme entry: 'A recent Scheme standard supported by Guile...'
<cow_2001>hmm... okay, so what i wanted to do before starting this scheme escapade was to ask some web api about something simple and then use that to run a bunch of command line ish proesses with that data
<cow_2001>let's see if i can actually do even part of the thing
<haugh>cow_2001, I just wanted rollbacks and now I'm reading the source code for the reification of quasi-dependent build systems
<haugh>be careful out there
<cow_2001>these rabbit holes feel hyperbolic, like in Hyper Rogue
<cow_2001>infinite and infinitely splitting and joining
<cow_2001>"format" is does more than formatting ~_~
<flatwhatson>does it?
<flatwhatson>i guess it has a built-in with-output-to-string feature for convenience
<flatwhatson>otherwise it's just a port function with an archaic interface
<cow_2001>i was expecting it to do just string formatting, due to its name, but it also does IO.
<cow_2001>was expecting it to behave something like rustlang's format!, or maybe sprintf
<flatwhatson>it does string formatting to a port, which might optionally be collected into a single string buffer
<cow_2001>or maybe it was fmt!?
<flatwhatson>but ports are the more fundamental thing to work with. using format directly to an output port should be more efficient than formatting to an intermediate string, then sending that string to the output port
<cow_2001>yes, sorry. it's alright. i'm using it it now, but it was a bit confusing first, feeding it a template and its inputs and then finding it complaining about.. something
<cow_2001>was using it like (format "~a" 1)
<cow_2001>not like (format #f "~a" 1)
<cow_2001>now everything is 100%
<flatwhatson>it's definitely archaic, it's very similar Common Lisps's format and not particularly "schemey"
<cow_2001>is there a better way?
<cow_2001>it's alright as it is. i am just testing to see if i get the functions right.
<cow_2001>right now all i have is something that makes a list of urls "some.url/~a" with a sequence of page numbers 1 to n ~_~
<cow_2001>now i get to see if i can feed these into the client api
<flatwhatson>srfi-28 gives you a (format template args ...) function instead, but it's not idiomatic guile
<cow_2001>hmm. i'll just use idiomatic stuff.
<flatwhatson>SRFI-48 has a format function with an optional port argument, but it's not in guile
<flatwhatson>SRFI-166 describes a more modern approach to formatting, that might be a direction for the future
<cow_2001>oh, of course there is a list of all SRFIs in the manual
<cow_2001>(use-modules (srfi srfi-NUMBER))
<flatwhatson>supported SRFIs are in the manual, published SRFIs are on https://srfi.schemers.org/
<cow_2001>woop! there is the iota function!
<cow_2001>why am i manually counting backwards in this recursive function when i can just map on an iota ~_~
<cow_2001>flatwhatson: thank you!
<flatwhatson>if you're on guix, there are some guile-srfi-xyz packages providing extras, though i can't vouch for any of them
<cow_2001>on some debian descendant
<cow_2001>hmm... gnutls-not-available. i have a bad feeling i would have to compile stuff for myself.
<cow_2001>the guile-gnutls debian package is installed
<RhodiumToad>mapping on an iota isn't necessarily efficient
<cow_2001>it looks nicer, though
<old>It allocates at lot though
<old>Use unfold instead if generating X things
<cow_2001>hmm.
<cow_2001>that's an srfi-1 stuff
<cow_2001>reading
<cow_2001>okay, stop condition, mapping, next step, start, stop value
<cow_2001>woop! you can of course have an infinite loop in there
<RhodiumToad>well
<cow_2001>nice
<RhodiumToad>to avoid stack usage, unfold is implemented with a reverse
<RhodiumToad>but it will cons for each loop, so an infinite loop will consume all memory
<cow_2001>hmm
<RhodiumToad>you can try that with (unfold (const #f) identity 1+ 0)
<cow_2001>i did something like (unfold (lambda (i) #f) (lambda (i) (display i)) 1+ 1)
<cow_2001>that's a lot of memory
<cow_2001>http-get complains about gnutls not being installed.
<cow_2001>maybe i could just use curl instead
<cow_2001>hmmmmmm if unfold is defined with a reverse after the list is created, then the manual is wrong, no? or at least my manual
<cow_2001>it says: (unfold p f g seed) = (if (p seed) (tail-gen seed) (cons (f seed) (unfold p f g (g seed))))
<cow_2001>this one is not tail call optimised
<cow_2001>no?
<cow_2001>with the cons outside the tail call
<flatwhatson>i guess the wording "is defined as follows" is misleading, and it's just intended to get a quick understanding of how it works
<flatwhatson>(disregarding performance characteristics)
<cow_2001>maybe i should send a rewording patch? maybe something like "semantically equivalent to, but actually implemented with blah blah to avoid stack overflow with tail optimisation"?
<flatwhatson>maybe "could be defined as"?
<flatwhatson>the reader should be able to assume that however it's implemented under the hood, it's efficient
<cow_2001>could i add info about actual implementation? maybe rhodiumtoad's verbatim quote?
<cow_2001>if allowed
<cow_2001>or is it too much?
<cow_2001> https://codeberg.org/yuvallangerontheroad/guile/commit/30be96570e97f607aaf39d94ce8e10cc1d47aa02 and https://codeberg.org/yuvallangerontheroad/guile/commit/78c971c91409be58a77695c2fdf693c83ff1c01c
<old>cow_2001: What are you trying to do with iota or unfold?
<cow_2001>oh, let's say something like the guile equivalent of the python [requests.get(f"https://some.url/{i}") for i in range(1, 50)]
<cow_2001>although somehow gnutls is borked and i need to actually use curl with popen ~_~
<RhodiumToad>just use a (do)
<cow_2001>do... hmm..
<cow_2001>let's do it!
<cow_2001>ACTION reads the documentation
<cow_2001>6.13.4 iteration mechanisms
<RhodiumToad>(do ([i 1 (1+ i)]) ((> i 50)) ...)
<cow_2001>right, i did not get to that part...
<RhodiumToad>it's just syntax around the equivalent of a named-let
<cow_2001>there were a ton of stuff in between
<RhodiumToad>I have been known to do stuff like
<old>(let lp ((i 0)) (unless (= i N) ... (lp (1+ i)))
<RhodiumToad>(define-syntax-rule (numeric-for (var start limit) body ...) (let ([nlimit limit]) (do ([var start (1+ var)]) ((>= var nlimit)) body ...)))
<old> https://paste.sr.ht/~old/df6d3d1588fda8e991f0889984d60d6d266fd5c1
<old>do is really just sugar syntax like the above paste and RhodiumToad example
<RhodiumToad>your version re-evaluates end every time, which may or may not be desirable
<old>You can roll your own
<old>True
<old>this one is better: https://paste.sr.ht/~old/22b8298d0198ce47dee787d938b682436cad23a8
<RhodiumToad>that could go badly if end is inexact, no?
<old>I mean it's expected to pass integer here :p
<RhodiumToad>it does add an extra operation per iteration
<old>sure
<RhodiumToad>my version was done when I was specifically attempting to get a piece of code to be as fast as possible, so I poked a bit into variations
<RhodiumToad>that's partly why it's a macro, because i was trying lots of variants and comparing the performance
<old>that ought to do it: https://paste.sr.ht/~old/0c14309bb3b8021b3fb9e783b5c97f627e1c86de
<RhodiumToad>someone here a couple of years back wanted a fast hex/binary converter, so I did
<RhodiumToad> https://github.com/RhodiumToad/scheme-bits/blob/master/hex/hex.scm
<RhodiumToad>old: that should compile to basically identical code to my version
<old>indeex
<old>s/x/d
<daviid>sneek: later tell civodul one last thing about the learn page, i'd like to suggest to add one entry to the tutorial section - OOP with GNU Guile and GOOPS, https://www.wedesoft.de/software/2014/03/02/oop-with-goops/ -
<sneek>Will do.
<daviid>dsmith-work: do we still have a bot 'pointer' to this goops tutorial?
<dsmith>sneek: where is goops-tutorial?
<dsmith>sneek: what is goops-tutorial?
<sneek>goops-tutorial is https://www.wedesoft.de/software/2014/03/02/oop-with-goops/
<dsmith>daviid: ^^
<daviid>dsmith: ok tx
<daviid>wingo: a few days ago (it's only now i find the time to get a gdb bt ...)i had a crash, playing with the g-golf peg-solitaire.scm game, but it seems it crashed because of guile (?), here is a coredumbctl info/gdb bt - https://paste.debian.net/1262600/ - is this any usefull to you?
<daviid>wingo: just to coplete, my g-golf peg-solitaire game does not call graphene-quaternion-alloc 'on its own', it is being called as the result of the snapshot 'making', here - https://git.savannah.gnu.org/cgit/g-golf.git/tree/examples/gtk-4/peg-solitaire.scm?h=devel lines 88 -> 92
<wingo>good morning
<jonsger>morning
<jonsger>wingo: are there plans for a guile 3.0.9 this year?
<wingo>hoo, good q. i would ask civodul :)
<wingo>i am sure you have seen but fwiw i have been more focused on mid-term refactors than near-term maintenance
<wingo>for better or for worse :P
<jonsger>:)
<civodul>yes, i'd like to release 3.0.9 soonish!
<civodul>but i'd like to get the posix_spawn/open-pipe patches in
<civodul> https://issues.guix.gnu.org/52835
<dsmith-work>Happy Friday, Guilers!!
<civodul>hey dsmith-work, happy Friday!
<cow_2001>okay, noticed something just now about guile. if you use (define) to define functions AND to define variables you might confuse the two by assuming all of your defines are doing nothing while actually you forgot that one of your defines are actually calling previously defined functions while defining a variable.
<cow_2001>~_~
<lilyp>no define does nothing
<cow_2001>(define (f n) …) does nothing (except introducing f while (define x …) potentially does something in addition to introducing x
<cow_2001>err
<cow_2001>(except introducing f)
<cow_2001>okay! i have json in scm form. now i need to figure out how to get the stuff in it. somehow they did not include the info file of guile-json in the distribution ~_~
<lilyp>json->scm or define your own record type
<cow_2001>simple. it's just vectors and alists.
<daviid>rekado: wingo hello! did you see the essage i posted here for you, just before you said 'good morning' :) -
<daviid>rekado: sorry, i meant towrite sometinforyouto, but not mixed it wit my messae to wingo :)
<daviid>rekado: fwiw, te los seems complete, but roupin be date stoped on Novemeber the 30th ...
<daviid>wingo hello! did you see the message i posted here for you, just before you said 'good morning' :) ?
<daviid>*logs
<daviid>my laptop 'g' kb key is working 1/100 ... so my 'h', te spacebar and other... i have an external kb but sometimes put it away to accomplish some other task ...
<dsmith-work>Ya, The logs end on Nov 30. No Dec 2022 logs.
<dsmith-work>rekado: ^^
<cow_2001>what if i don't care about popen input or output? i just want to run it and wait for it to finish its work.
<cow_2001>hmm, system* does that
<wingo>daviid: i saw it but didn't click through, sry :/ i don't really have much of that code paged in at all
<cow_2001> https://0x0.st/okBG.scm is trying to emulate some possibly past version of https://github.com/diracdeltas/tweets/blob/main/follow-everybody.bash
<cow_2001>oh, the naming is wrong. happens when you muck about.
<daviid>wingo: ok thanks - i can't reproduce that bug, i've tried numerous attempts, i fail to reproduce it ... too bad
<cow_2001>turns out you can download and install a scip.info.gz inside your INFOPATH https://www.neilvandyke.org/sicp-texi/
<cow_2001> https://0x0.st/okuK.png
<daviid>rlb: as you are, it seems, deeply involved in rewriting our guile's string stack :), could you look at this backtrace and see if you can point/understand what caused the segfault? - https://paste.debian.net/1262600/
<dsmith-work>daviid: Lines 65,67 u8_lenp=0x0 Suspicious?
<daviid>dsmith-work: ok, but this is set by guile (?) - return (char *) latin1_to_u8 ((uint8_t *) scm_i_string_chars (str), scm_i_string_length (str), NULL, lenp);
<daviid>*set/passed by guile
<daviid>no big deal - at some point i guess i'll be able to reproduce the bug with a bit more context ... random segfault scare me though ...
<spk121>daviid: it is pretty hard to guess, but, it could be the second argument to regexp-exec, which appears to be a string containing "graphene-...." was either GC'd or modified in another thread while the current thread was accessing its characters
<daviid>spk121: ok tx - fwiw, the peg-soltaire game doesn't call regexp-exec nor use threads but i was trrying to understnd if, maybe, i have a g-golf bad result or out argument allocation problem ...
<rlb>daviid: I can look more closely later, but offhand, my first question is often to wonder whether the code might be missing a remember_upto_here. We do pass internal pointers to latin1_to_u8, but that shouldn't be a problem with str as an argument to the enclosing function?
<beanwater>Does anyone have a recommendation for getting better test output in a terminal window? I'm new to Guile but not to programming; wondering if there's a better formatting for `guile -L . some-test-file.scm` output out there before rabbit holing too much.
<daviid>rlb: tx, not sure how to answer your question, none of the bt calls are actualy 'mine' - but don't look more closely, i think spk121 interpretation is right, and i am going to stop trying to find the cause 'in g-golf', i can't reproduce the bug either ...
<cow_2001>scheme often uses whole words for its variables. so why O_RDONLY ;____;
<kori>cow_2001: if I had to bet, that'd be because of C
<kori>(but I don't know the exact reason)
<cow_2001>i would too ~_~
<cow_2001>yes, open(2) of the linux programmer's manual says O_RDONLY
<old>cow_2001: They are literal constant from C yes
<old>It makes sens to expose such low level API, now restricting users
<old>s/now/not
<cow_2001>old: cheesy christmas themed code kata 2022 day one part one! https://0x0.st/okfa.scm
<cow_2001>should i use (define some-local-variable (make-some-value)) or (let ((some-local-variable (make-some-value)) …) inside functions?
<old>it's the same
<old>depend on your style I guess
<old>I often use `define` for generated procedue
<cow_2001>not there! D:<
<old>`(define (make-counter) (let ((counter 0)) (define (the-counter) (let ((c counter)) (set! counter (1+ c)) c)) the-counter))`
<old>instead of using a `letrec` for example
<cow_2001>me |<------ … 1000 * "-" … ----->| macros
<cow_2001>i've written a stupid rustlang macro before, but only with a code example to steal from
<old>I know that the authors of the "Structure and interpretation of computer programs" use define in their procedure a lot for clarity
<cow_2001>you could have used (define counter 0) right before (define (the-counter) …) right?
<cow_2001>they are semantically equivalent, no?
<cow_2001>oh, generated procedure is a procedure you return, nothing to do with macros.
<cow_2001>i could go check. wait a second.
<cow_2001>okay. using vim is no fun for writing scheme. i should have just used emacs + paredit.
<cow_2001>thought it would have been a simple thing, but i had to change indentation and things just smashed into column 0.
<cow_2001>okay, cond might look better than if.
<cow_2001>welp. definition in expression context, where definitions are not allowed.
<cow_2001>somewhere in a cond arm
<clh3>daviid: the g-golf hl-api tests assume gtk3 is available, right? I'm writing a patch for 32-bit support in g-golf. I can get all the tests to pass using gtk3.
<sneek>Welcome back clh3, you have 1 message!
<sneek>clh3, dthompson says: saw your messages on #chickadee. yes, 'arc-to' is trigonometry and vector math to figure out the correct 'arc' call to make. I'm close to the solution.
<clh3>thanks sneek
<daviid>clh3: you mean the test suite, indeed still uses clutter and gtk3, I need to implement similar tests not requiring any deps more then g-golf itself, glib/gobject/gi
<daviid>clh3: all examples require gtk-4+
<daviid>*gtk-4
<daviid>clh3: just to make sure, there is no 'g-golf hl-api tests' module, just a test suite that is in <Tree>/test-suite/tests
<clh3>daviid: ah, I see what you mean. I meant the (tests hl-api) module
<daviid>clh3: ah ok, all tests that currently require or clutter or gtk should desapear
<daviid>*disappear (be re-written)
<clh3>daviid: cool. When I build the patch against gtk4 the only issue I have left is that the peg-solitaire example's grid doesn't get colored and drag-n-drop triggers the debugger. I haven't determined if that's related to the 32-bit patch.
<clh3>the color outlines appear during drag
<daviid>what do you mean ny 'a patch for 32-bit support in g-golf'? g-golf doesn't make any assumption on the architecture yo9u are running, if youn have a 32bits guile available, if glib/gobject/gi are also available on your 32bits architecture, g-golf would just work
<daviid>the grid is not colored
<daviid>*in the peg-soltaire example
<clh3>daviid: g_registered_type_info_get_g_type as written returns int64 rather than unsigned-long.
<daviid>good catch, will fix that
<daviid>clh3: fixed, on the devel branch
<clh3>I should also mention that the following procedures also assume a 64-bit gtype as written: g-golf/gi/common-types.scm (gi-type-tag->bv-acc)
<clh3>g-golf/gobject/signals.scm (decode-param-types)
<clh3>g-golf/gi/utils.scm (gi-gtypes->scm, gi-n-gtype->scm) (scm->gi-n-gtype, scm->gi-gtypes)
<clh3>those are all the ones I know about
<haugh>cow_2001, this is how I learned syntax-rules. Don't be intimidated, it's basically just a very particular kind of pattern matching.
<haugh> http://www.phyast.pitt.edu/~micheles/syntax-rules.pdf
<daviid>clh3: gi-type-tag->bv-acc seems correct to me
<haugh>plaintext: https://hipster.home.xs4all.nl/lib/scheme/gauche/define-syntax-primer.txt
<daviid>so does decode-param-types, looks ok to me
<cow_2001>O_O
<haugh>cow_2001, and as long as I'm spamming links here is the awesome-guile list where I found that https://notabug.org/ZelphirKaltstahl/awesome-guile/src/master/list.md
<haugh>Be not afraid
<clh3>daviid: (gi-type-tag->bv-acc) lines 235-236 use u64vector-ref to access gtypes, which will work fine on 64-bit but on 32-bit the sizes don't match and the build fails.
<cow_2001>"be not afraid" where did i hear that line before ~_~
<cow_2001>when i see list.md i imagine this whole list would be about a linear series of cons
<cow_2001>no, it's just a regular list of things
<clh3>daviid: (decode-param-types) line 161 uses u64vector->list. That also causes a build failure on 32-bit.
<clh3>daviid: oops, I meant test suite failures. The only build failure was the one that you just fixed on devel.
<clh3>so no more build failures :)
<daviid>clh3: hum, my bad - there are definitely quite a few other places 64bits length is assumed for unsigned-long
<cow_2001>haugh: thank you, by the way.
<daviid>and we all have to do this again and again ... i am pretty sure guile checks ans elect appropriate bv makers/accessors ... (?)
<cow_2001>(take lst n) raises an exception if (< (length lst) n)
<daviid>clh3: can you paste one change, so i can look at, thakns
<cow_2001>i wrote another function which just returns an equivalent list to lst. i call it take-whatever-duuuude. bad hippie joke. sorry.
<haugh>cow_2001, yw, I'm new too
<haugh>cow_2001, check out #scheme for less implementation-specific stuff; it's not always easy to tell where the line is but you might get a lot more help depending on the issue
<cow_2001>ah
<clh3>daviid: I'm not aware of any guile macros that handle platform-dependent sizes for uniform bytevectors (although I would be very interested to find them!). So my first change was to write macros to handle unsigned-long uniform bytevectors in support/bytevectors.scm.
<clh3>+(define-syntax define-ul
<clh3>+ (lambda (x)
<clh3>+ (syntax-case x ()
<clh3>+ ((_ ul ul-32 ul-64)
<clh3>+ #'(define-syntax ul
<clh3>+ (identifier-syntax (case (sizeof unsigned-long)
<clh3>+ ((4) ul-32)
<clh3>+ ((8) ul-64))))))))
<clh3>and then
<clh3>+(define-ul make-ulvector
<clh3>+ make-u32vector make-u64vector)
<cow_2001>oh no, even #scheme publicly publishes their logs ~_~
<clh3>the end result (in this example) is a macro 'make-ulvector' that then replaces 'make-u64vector' in other files.
<daviid>clh3: ok, don't spend too much time before i agree, i very reluctant to use macros, but i'll think and work on a patch - thanks for pointing this tremendous lack of g-golf 'natural' support for 32 bits machines ... oh well
<daviid>clh3: is there any other type to be checked for their size, or just unsigned-long? c'ause i'd rather think about 'all this mess' all in once
<daviid>spk121: are you dealing with this in guile-gi? so i can snarf your code ... :)
<clh3>daviid: only unsigned-long (that I'm aware of)
<daviid>spk121: hum, as guile-gi is mostly C, i guess you didn't even have to :)
<daviid>clh3: ok tx
<daviid>clh3: are you effectively running on a 32bits machine or using a vm? just curious
<clh3>daviid: I am running a 32-bit machine.
<clh3>daviid: x86_32
<clh3>daviid: i686
<daviid>clh3: ok, i'll fix this asap, thanks again to report this
<clh3>tx
<old>cow_2001: Yes you can have `counter` and `the-counter` top defined in the procedure
<sonny>I just found out guile compiles to ELF ... can guile share C code without FFI?
<flatwhatson>sonny: it uses ELF as a container format. inside, there's bytecode, not native code
<sneek>Welcome back flatwhatson, you have 1 message!
<sneek>flatwhatson, haugh says: why does guile-gemini/guix.scm need (guix build utils) and (guix gexp)?
<flatwhatson>sonny: https://www.gnu.org/software/guile/manual/html_node/Object-File-Format.html
<sonny>hmmm
<sonny>so close
<flatwhatson>haugh: you can check this yourself by removing those imports and running "guild compile guix.scm" and see the warnings ;)
<flatwhatson>sonny: close to what? what are you trying to achieve? guile has good options already for integration with C
<sonny>nothing, I just wanted to see a [scheme] compiler call C code without ffi
<sonny>its still unreal though because guile has it's own elf loader
<flatwhatson>it also has a jit which produces native code at runtime. i guess "so close" is right :P
<sonny>lol
<sonny>thanks for your help, I'll check the code out later
<daviid>sneek: later tell clh3 I fixed and pushed, on the devel branch, please try and let me know if everything is ok now, tx
<sneek>Okay.
<spk121>daviid: the util funcs for long/int/short lists and vectors are in https://github.com/spk121/guile-gi/blob/master/module/gi/util.scm
<spk121>pretty basic, tho
<chrislck>who is doing aoc2022?
<flatwhatson>chrislck: i've been doing them
<chrislck>nice... 4/4 so far aok