IRC channel logs

2020-02-06.log

back to list of logs

<rekado>hey there, I’m still cleaning up the GWL code that deals with Wisp
<rekado>I’m trying to use LOAD with the Wisp reader, but I’m getting the error “definition in expression context, where definitions are not allowed”
<rekado>that’s with Guile 2.2.6
<rekado>(load "/tmp/test.w" wisp-scheme-read-chunk)
<rekado>the file contains just one definition: define hello "hello"
<rekado>(load "/tmp/test.scm" read) obviously works fine, where “test.scm” contains (define hello "hello")
<rekado>looks like wisp-scheme-read-chunk is just not the right kind of procedure for this task.
<rekado>wisp itself defines a private read-one-wisp-sexp procedure that wraps wisp-scheme-read-chunk — and that seems to work
***daviid is now known as Guest84229
***Guest84229 is now known as daviid
<rlb>Do procedures with setters have a usable goops class? i.e. they don't appear to be subclassed from <generic> or <procedure> I may be able to work around the issue, but it'd be convenient for them to work smoothly with goops.
<rlb>In 3.0 at least they do satisfy procedure?, but appear via class-of to have a generic class or something.
<rlb>(or that's just how structs always appear via class-of)
<wingo>moin :)
***apteryx_ is now known as apteryx
<fnstudio>hi, is there a default pattern for modifying a list element and returning that list?
<fnstudio>i know there's `list-set!` but i'm wondering if there's anything similar that doesn't change the list in place
<fnstudio>otoh, i'd be curious to know why the provided built-in is the `!` (in-place modification) version
<fnstudio>i suppose that one can create a copy of the original list, apply `list-set!` to the copy and finally return it (hence without modifying the original version)
<fnstudio>would that be a good pattern? anything i'm missing?
<lloda>racket has that fnstudio, it's called list-set
<lloda> you only need to copy the list up to i, not all the list
<lloda>e.g. https://paste.debian.net/1129397/ ?
<lloda>you should do this walking the list once but i'm lazy
<lloda>I think it's a good function and we should have it in guile fwiw
***lavaflow_ is now known as lavaflow
<lloda>why the provided version is ! I guess it's because it doesn't copy anything. But if you use that a lot you need a vector instead.
***w2gz is now known as w1gz
<fnstudio>hey lloda, thanks so much! vvv helpful
<lloda>yw
***nly is now known as nlyy
***nlyy is now known as nly
<wingo>did anyone implement https://html.spec.whatwg.org/multipage/parsing.html ?
<mwette>wish I'd seen that long ago when I tried html5 from the spec, but gave up: https://paste.debian.net/1129432/
<mwette>I used http://www.w3.org/TR/html5/syntax.html
<dsmith-work>Thursday Greetings, Guilers
<mwette>wingo: same thing -- so the incomplete work I generated is against the spec;o There was some discussion on one of the email lists back then
<dsmith-work>What about htmlprag?
<dsmith-work>In guile-lib: https://www.nongnu.org/guile-lib/doc/ref/htmlprag/
<mwette>wingo: https://lists.gnu.org/archive/html/guile-user/2016-07/msg00035.html
<mwette>dsmith-work: I've used that. It chokes sometimes, but otherwise has been useful.
<mwette>.
<wingo>dsmith-work: i think htmlprag should be considered to be obsolete. the whole notion of "pragmatic" vs "strict" is one from the xhtml days
<wingo>i think the specified parser is a real step forward
<dsmith-work>Agreed!
<jcowan>There's still a difference between correct and incorrect HTML5, though.
<ManDay>Why does (iota count start step) not work despite the docs of guile about srfi-1 ?
<ManDay>only (iota count) works
<lloda>ManDay: (iota count start step) works if you (import (srfi :1)) first
<lloda>that was fixed in 3.0 btw
<ManDay>oh, there is guile-3? lol
<ManDay>good to know, thanks for the info ^^
<ManDay>thanks for the answer, too
<lloda>np
<lloda>this was the fix
<lloda> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=2b6083865a69c44c09ac493cb4a1d65fffb83d81
<jcowan>It should be documented somewhere that you can say (import (only (guile) foo bar baz ...) to get Guile-specific identifiers into R6RS programs. I found that out by guessing it.
***dftxbs3e_ is now known as dftxbs3e