IRC channel logs

2020-12-21.log

back to list of logs

<fnstudio>is there a more compact version of list-index that does this? `(list-index (lambda (x) (equal? x 2)) '(0 1 2))`
<fnstudio>should have said... a more compact way of using it
<dsmith>SOoo. looks like SISC is MPL and/or? GPL. But the sarahbot code is under "contrib". Still looking.
<chrislck>fnstudio: find
<chrislck>oops list-index if you need the index
<fnstudio>chrislck: yes, i need the index in this particular case
<lampilelo>fnstudio: if you want it to be less verbose you could use cut from srfi-26, instead of the lambda you'd have (cut equal? 2 <>)
<lampilelo>saves you whole 8 characters, wooo
<leoprikler>lampilelo: it may just be 8 characters, but it saves you the trouble of naming 1 argument!
<chrislck>(list-index (cut = <> 2) test-list) if you're 100% certain the list has numbers only.
<fnstudio>lampilelo leoprikler: excellent, that's definitely an improvement, tx
*daviid xross his fingers so that dsmith finds the time to solve, if possible, this bot code 'problem' and publish the bot code ...
<dsmith>daviid: Looks like the original code is GPL. Currently writing a README and getting ready to put it in git somewhere.
<daviid>tohoyn: i have nothing special to say, i'm happy you did produce a debian package for g-golf 'in the first place' of course, and I am glad you did find my suggestion to upload it, rather then send it by email, a good suggestion ...
<daviid>tohoyn: it should help debian users - that are afraid or do not want to src install - to try and possibly really use g-golf ...
<daviid>tohoyn: I would, however, as I already mentioned in my email to you, explain why you (had to) do that, and add some (extreme) caution notivce , both the debiaj package and g-golf itlsef are still experimental, and explain that g-golf itlsef isnt even released ...
<daviid>tohoyn: finally, I would not use a date as a debian release package name, but something like g-golf-0.1.0-pre-alpha-1.deb, then g-golf-0.1.0-pre-alpha-2.deb ... till I start to release of course ... my 2c do as you wish of course
<daviid>sneek: later tell civodul that define-method creates a generic if it does not exist is part of the (clos) protocol, changing that would be a very serious break (in the protocol) - also note that it is an error to redefine a generic, and unfortunately guile did break the protocol wrt that, guile does not raise an exception if one redefines a generic (very unfortunately, I have no idea why it breaks that fundamental part of the protocol)
<daviid>- the combination of the later with the change you proposed will lead to 'explosive' bugs, I mean bugs that are nearly impossible to debug, imo
<sneek>Okay.
<daviid>wingo: I don't believe you when you say are not a goops user :), you even wrote guile-gnome - which is the most advanced piece of goops code 'we have out there', that uses up to details of the mop that only few understand ... it seems to me, but i only had a quick superficial look, that the (language ecmascript function) imports (language ecmascript base) which defines the generic and so the compiler should add the method to that
<daviid>generic and not raise a warning
<sneek>Ooo! Look at this: https://gitlab.com/dalepsmith/sneek
<daviid>wingo: the (language ecmascript array) module import both, and so depending on 'implementation details' (I mean implementation details of the module system in guile, like does it resolve the import first so array only sees one generic, or not ..) ) you might (have to) add #:duplicates (merge-generics replace warn-override-core warn last) - I definetaly would do that, add #:duplicates (merge-generics ...) as a precaution anyway, in
<daviid>every module that uses goops andnimport other 'goops' modules ... unless there would be a good reason not to (a good reason by someone who so much know what they are doing, like you or a few others on the planet ... everybody else should rely on the protocol and merge generics
***wxie1 is now known as wxie
<daviid>wingo: that define-class redefines (merge) class(es) (definitions) is also part of the protocol, fwiw, although I thought guile did break that protocol as well, I never tried that (never had to ...)
<daviid>dsmith: great, thanks!
<dsmith>So. I don't really know much about goops and CLOS, but CL and Guile have very different module and naming systems. I suspect that originally goops tried really hard to be as close to CLOS as possible. All these magic redefintions and macros doing things behind your back don't seem very Schemey.
<dsmith>To me.
<dsmith>But as I said, I really don't know much here.
<daviid>dsmith: as I already had the oportunity to say a long time ago, goops is clos, and should not break the protocol, without a very good reason
<daviid>'not scheme' is not even a reasom, imo
<dsmith>There are already differences. Scheme is a lisp-1 and CL is a lisp-2. The namespace in CL is different than the modular system in Guile.
<dsmith>I need to learn CL.
<daviid>dsmith: they should be no interference of the module (or package system in CL) and clos/goops - that is described (and explained in detail) in the protocol itself - which is why guile (has to have) 'offers' to merge-generics ... but anyway, it is very 'dangerous' to break that protocol, unless you are so knowledgeagble that you could have been part of the protocol desiogner board
<daviid>dsmith: those who do not 'like' clos/goops, just have to not use it :) - that is easy enough I think :)
<dsmith>Yeah, I never had a need.
<dsmith>Never did "get" the whole OO craze either.
<daviid>i think that it's like football, politics and religion, use it if you like it, but let's not discuss it - not using clos, for me, is like telling me you'd rather cross the ocean by swimming, cool, i'd rather take a plane ... :)
<daviid>and I'd rather avoid to 'discuss the protocol' as well, unless you (as in the person who speaks, not you personally) know as much as the protocol designers - otherwise we end-up re explaing the basics, and why it is not 'message passing' (oh my god!), not about encapsulation (oh my god!), not about (module) protection (oh my god!) ... all this is in the protocol, and well explained in tons of papers, the fruit of 20 to 30y of research
<daviid>and designed by the best s/w engineers the planet has ever had ...
<tohoyn>daviid: I updated the debian package, see http://tohoyn.fi/g-golf-debian/
<tohoyn>daviid: I use versions of the form 0.1.0v<VERSION>-<DEBIAN REVISION> because I'm not sure if dashes are allowed in the upstream package name.
<leoprikler>daviid: "You know nothing, John Snow. We don't talk about the protocol." feels like a weird excuse tho, imo.
<leoprikler>Like, I get that similarity to CLOS is a selling point from people, who come from that, but in my personal opinion, integrating well into the language is of a higher priority.
<leoprikler>s/from people/for people/
<leoprikler>And people prefer records over GOOPS features all the time, sadly.
<tohoyn>are you planning to integrate GOOPS into the Scheme standard?
***wxie1 is now known as wxie
<ArneBab>wingo: did you get to update the compiler tasks article? https://wingolog.org/archives/2016/02/04/guile-compiler-tasks
<ruffni>is there any tutorial for guile sdl2? the example works just fine, but how do i for example set the background to a solid color and draw some lines/rects? i found the according functions, but when i don't render-copy the bitmap it's all black on black.... thankful for any advice i can get!
<lampilelo>there is an info manual but it's just a reference, not a tutorial
<Noisytoot>dsmith: The sneek source code contains references to your home directory several times (search for "/home/dsmith"), you should change that, because people are unlikely to have exactly the same files as you do
<Noisytoot>dsmith: (specifically: "/home/dsmith/.bobotpp/logs/log2.log" at scripts/log2.scm line 7, "/home/dsmith/.bobotpp/scripts" at scripts/sneek line 6, and "/home/dsmith/sarah.db" at scripts/bot/sql.scm line 20)
<dsmith>Yep. It's just a dump of what I have.
*spk121 wonders why, after bootstrap, (language value spec) is the first to compile
<leoprikler>ruffni: set-render-draw-color, render-draw-line, render-draw-rect(s)
<leoprikler>In 0.5 at least
<leoprikler>0.6 IIRC simlifies the latter to draw-line and draw-rect(s) while the former becomes set-renderer-draw-color!
<remby>running at the repl, `(use-modules (ice-9 textual-ports))` errors with `ERROR: no code for module (ice-9 textual-ports)`
<remby>what am I doing wrong?
<mwette>remby: what version of guile? does not exist in 2.0
<remby>yeah 2.0.14
<remby>ok, I see there is also a guile22
<remby>in my repos
<iv-so>Guys, should Guile 3.0.4 work with musl?
<spk121>iv-so: I don't know if the maintainers have committed to musl as a dedicated target, but, it probably works with musl or is very close to building with musl. The only c libraries I know it gets built with regularly is GNU libc and Cygwin Newlib.
<iv-so>I built it for musl, but a lot of tests fail
<iv-so>encoding-escapes, encoding-iso88597, i18n, iconv and some other
<dsmith>I *think* I tried building 3.0.x with musl on buildroot once. IIRC it didn't work out too well.
<iv-so>Thanks for the answer. I expected some failures because of musl localeless, but there are just too many.
<spk121>iv-so: that is to be expected, with regards to the encoding. musl only handles one encoding, which is UTF-8
<spk121>latin1 will fail. iso885987 (greek) will fail. Any Guile built with musl just can't do those obscure encodings, because musl can't do them
<spk121>But the test suite could be improved to mark those SKIP or XFAIL, I guess
<iv-so>Ok
<iv-so>I forgot that UTF-8 includes ASCII, but not Latin-1
<iv-so>spk121: how can I mark tests as XFAIL?
<spk121>in the test suite, if a test quits early by (throw 'unresolved) or (throw 'unsupported) or (throw 'xfail), it'll show up as SKIP or XFAIL during make check
<spk121>I don't know if there is a way to do it without actually modifying the tests, though. Maybe there is.
<spk121>oops, throwing xfail doesn't work, the other ones do
<iv-so>It's fine, I will modify them anyway
<dsmith>So what is the advantage of musl? Small size?
<mwette>apt info musl says "musl is lightweight, fast, simple, free and [...]"
<dsmith>Looks like a re-implementation, but aims to be compatible.
<spk121>dsmith: musl is usually quicker to be standard's compliant. For example, it picked up C11 threads much quicker than other implementations
<spk121>but in general for most people, no real advantage other than avoiding 'vendor lock in' I guess
<dsmith>Interesting. https://wiki.musl-libc.org/functional-differences-from-glibc.html
***karlosz_ is now known as karlosz
<civodul>oooh
<civodul>gnutls uses nettle, which uses gmp
<civodul>but guile changes gmp's allocation functions to use libgc
<civodul>crap
<spk121>civodul: I never got around to trying Guile with minigmp, but, you could make a special build of either nettle or of guile to use minigmp so that they're not stepping on one another ?
<civodul>yeah