IRC channel logs

2021-04-23.log

back to list of logs

<leoprikler>does Guile not explicitly state, that it only guarantees that the application doesn't crash, but doesn't guarantee garbage-freeness?
<ArneBab>leoprikler: If you want to make it easier for people to use tsukundere with wisp, you can simply include the parsed language/wisp.scm and language/wisp/spec.scm in the game. That’s what I do for dryads-wake: https://hg.sr.ht/~arnebab/dryads-wake/browse/language
<leoprikler>I'm somewhat opposed to bundling, but this raises an interesting question.
<ArneBab>(I only now saw the spring lisp game jam, and there’s nothing new from me except that dryads-wake now has fully working auto-saves)
<leoprikler>IIRC, Wisp itself is GPL3+, but this implementation seems Expat-licensed. Are there any notable differences between the two?
<ArneBab>yes, wisp under GPL3+ is more robust and supports adding procedure properties via literal arrays. But since I am the only author for the implementation (though jan wedekind improved the makefile), it would be easy to allow using it under LGPL.
<ArneBab>GPL3+ is the project
<ArneBab>the actual parser and reader are lax licensed: https://hg.sr.ht/~arnebab/wisp/browse/wisp-scheme.w?rev=tip
<ArneBab> https://hg.sr.ht/~arnebab/wisp/browse/wisp-reader.w?rev=tip
<ArneBab>(because that’s required for an SRFI)
<leoprikler>Hmm, so where exactly does the GPL apply?
<ArneBab>(I’ll have to doublecheck the reader-file, but since the readable stuff is mostly under MIT that should be unproblematic, too)
<ArneBab>in everything that does not have its own license header
<ArneBab>currently that’s the reader, but that is more of an oversight on my part
<leoprikler>oof, normally the GPL wants you to make that explicit by adding the header
<leoprikler>(hence why most everything in Tsukundere carries one)
<ArneBab>yes — in this case the wisp-scheme.w file came from the SRFI-implementation, and expat is GPL-compatible
<leoprikler>also I'm not sure if that's source hut, but isn't the language/ code missing?
<ArneBab>the examples are GPL, too
<ArneBab>the language/ code is generated by the bootstrap.sh script
<ArneBab>from wisp-scheme.w and wisp-reader.w
<leoprikler>Ahh, I see
<ArneBab>wisp-reader.w becomes language/wisp/spec.scm and wisp-scheme.w becomes language/wisp.scm
<ArneBab>there’s also wisp.scm (from wisp-guile.w) that can convert wisp files to regular scheme files
<leoprikler>apropos wisp.scm, I think there might be some problems with that
<ArneBab>wisp-guile.w uses string-parsing for that, though, and it has at least two known bugs, one with character literals and comments (i.e. #\;) and another one with comments.
<ArneBab>how so?
<ArneBab>(there are two wisp.scm: one in the repo-toplevel and one in language/wisp.scm)
<leoprikler>I've had source files (I can't recreate them on the top of my head, sorry), that would work fine with the wisp reader, but when asked to translate to scheme, it would be garbage in some way.
<leoprikler>ah, well, that'd be wisp2lisp, not wisp
<leoprikler>wisp is just a lazy guile wrapper :P
<ArneBab>yes, there are some edge cases I never got solved with the string-parsing approach (I wouldn’t have thought that parsing scheme is so hard). It’s why I switched to the reader.
<ArneBab>yes: it got so much easier when I decided to simply call (read) on any construct that’s not needed for specialized treatment :-)
<ArneBab>(people had told me to try for months and when I tried I found they were right)
<ArneBab>wisp2lisp has some edge-cases — it can happen that paren-adding ceases at some point. Typically there’s a character-literal at that point. I tend to work around those by replacing it with (string-ref "<character>" 0)
<ArneBab>that’s very annoying to me, but I did not manage to fix it
<ArneBab>(I wish I could get wisp2lisp fully equivalent to wisp-scheme.w, but I already failed twice at getting rid of the last few edge cases)
<leoprikler>Joke's on you, even compiling down to Tree-IL and back doesn't save you.
<ArneBab>yes: using the reader I lose the comments
<ArneBab>so I cannot replace wisp2lisp by language/wisp.scm
<leoprikler>Well, comments are one thing, but I mean in terms of actual code.
<ArneBab>do you mean there’s a bug in the read-using implementation?
<ArneBab>If you can give me a test-case (wisp-code and scheme-code that should both become the same tree-il), that would be great!
<leoprikler>no, I mean much more, that it's possible to write Scheme, that can be "compiled to Tree-IL and back" and make perfect sense, but can't be compiled directly to bytecode
<ArneBab>do you have an example?
<leoprikler>I once stumbled on such a case when I debugged some funky macro with macroexpand.
<ArneBab>can that Scheme-code actually work? Is it valid Scheme?
<leoprikler>I think it's valid Scheme, but I vaguely recall it does weird things with identifiers.
<ArneBab>that sounds nasty :-)
<ArneBab>(and fun)
<leoprikler>I think the bug was, that Tree-IL correctly sees them as two different literals, but when compiled back to Scheme, they are one again (because that version of Guile undid the gensyms)
<leoprikler>If you compile that code again, there is no longer any macro expansion, so it just eats that.
<ArneBab>yikes! That means wisp2lisp will always have to stay a string-transformation implementation.
<ArneBab>So I might have to try my hand at fixing its remaining edge-cases again.
<leoprikler>I don't think that this is unsolvable per se, but the Tree-IL→Scheme back transformation certainly has its own edge cases to deal with.
<leoprikler>If you can live with gensyms, I think 3.0.5 might be fine.
<leoprikler>The Tree-IL I saw from that is a little on the verbose side
<ArneBab>wisp actually doesn’t do much in terms of complex processing: It just turns indentation-based code into the structure that repeated (read) would get from the equivalent scheme file.
<ArneBab>that’s also what’s checked in the tests: https://hg.sr.ht/~arnebab/wisp/browse/tests?rev=tip
<ArneBab>https://hg.sr.ht/~arnebab/wisp/browse/tests/runtests-scheme-reader.sh?rev=tip
<leoprikler>okay, nope, no fancy identifiers in that
<ArneBab>I try to keep as simple and stupid as possible :-)
<ArneBab>(keep wisp as simple and stupid)
<leoprikler>btw. can wisp handle stuff like receive?
<ArneBab>here’s what wisp wants to guarantee: https://hg.sr.ht/~arnebab/wisp/browse/testrunner.w?rev=tip#L26
<leoprikler>e.g. I'd want
<leoprikler>receive
<leoprikler>____ proc
<leoprikler>__ body body* ...
<ArneBab>how do you call it in scheme? (with imports)
<leoprikler>it's inside (ice-9 receive), but I'm talking about the syntax here
<ArneBab>can you give a minimal example in Scheme?
<ArneBab>(with parens)
<leoprikler>(receive (car cdr) (car+cdr '(car . cdr) car)
<leoprikler>so it'd be receive : formal formal* ... actually
<leoprikler>ehh, paren closing
<leoprikler>(receive (car cdr) (car+cdr '(car . cdr)) car)
<ArneBab>my guile just complained :-)
<ArneBab>with Guile I get bad lambda in form car cdr: syntax error
<ArneBab>with
<ArneBab>ah, I closed the wrong paren
<leoprikler>(ice-9 receive) (srfi srfi-1)
<ArneBab>what should that give?
<leoprikler>the symbol 'car
<ArneBab>so this:
<ArneBab>(import (ice-9 receive) (srfi srfi-1))
<ArneBab>(write (receive (car cdr) (car+cdr '(car . cdr)) car))
<leoprikler>I tend not to like write in the repl, but yeah
<leoprikler>but the special trick here, is that the first 2 forms require extra indentation if they're not on the same line
<ArneBab>import (ice-9 receive) (srfi srfi-1)
<ArneBab>write
<ArneBab> receive : car cdr
<ArneBab> car+cdr '(car . cdr)
<ArneBab> . car
<leoprikler>so what I'd like to have is something, where I could indent car a bit less
<leoprikler>similarly:
<ArneBab>Wisp uses the prefix-dot to reach the same goal.
<leoprikler>I don't think you understand me correctly, I would want the dot with less indentation.
<ArneBab>I think I do, but while it might actually work, it’s not how wisp is specified
<leoprikler>fair enough
<ArneBab>You can actually do this:
<ArneBab>write
<ArneBab>_ receive : car cdr
<ArneBab>___ car+cdr '(car . cdr)
<ArneBab>__ . car
<ArneBab>but it’s not guaranteed that it will keep working (since it’s not in the spec)
<ArneBab>and gives you this warning:
<ArneBab>;;; WARNING:5: used lower but undefined indentation level (line 4 of the current chunk: (REPR-DOT-e749c73d-c826-47e2-a798-c16c13cb89dd car)). This makes refactoring much more error-prone, therefore it might become an error in a later version of Wisp.
<leoprikler>another case, where it might make sense to think about this though is define-public
<leoprikler>because functions with many arguments typically split them
<leoprikler>but doing so makes refactoring much more error-prone :)
<ArneBab>:-)
<ArneBab>with many arguments, I use
<ArneBab>define
<ArneBab> fun arg1 arg2 arg3
<ArneBab> . arg4 arg5
<ArneBab> . arg3 arg7
<ArneBab> . #f
<leoprikler>yeah, but you can no longer define : fun
<ArneBab>yepp — that’s the limit of the inline-colon syntax
<leoprikler>That being said, I still feel like a genius for using arguments as initialization.
<ArneBab>the colon is intentionally limited: the reason why the colon exists as special syntax is that it can be used alone on a line: https://www.draketo.de/software/wisp#sec-4-2
<ArneBab>can you give an example of that?
<ArneBab>(I’ve been looking at tsukundere but missed examples)
<leoprikler> https://gitlab.com/leoprikler/tsukundere-shitsumon/-/blob/master/shitsumon.w#L99-104 <- this function is only ever called without arguments
<ArneBab>wow, that looks awesome!
<ArneBab>and I seriously have to link it on the wisp-page (if you don’t mind)
<ArneBab>Do you already have a dedicated website I could link to?
<ArneBab>(I need to get to bed — I’ll see your reply tomorrow, if you can’t reply before I need to get AFK)
<leoprikler>For Tsukundere? I only generate docs, sadly.
<leoprikler>I think linking Shitsumon as-is *should* be fine, but it doesn't have a release mainly because I haven't yet coded the fancy main loop with credits stuff.
<leoprikler>That said proper credits should at least exist in the README
<ArneBab>I’ll think of a way tomorrow (when I’m not as dead-tired as right now — it’s half past one in the morning here :-) )
<leoprikler>Oh yeah, my super exciting web page: https://leoprikler.gitlab.io/tsukundere/
<rlb>leoprikler: if you were addressing my string questions, then right, I think we *might* be within the letter of the law, but if so, was still wondering about whether the difference was actually OK before I spend a lot more time on some of the function conversions.
<sneek>rlb, you have 1 message!
<sneek>rlb, zzappie says: not useful at this point of time but hey, I didn't know about lokke
<ArneBab>I already found that one — it could really benefit from a screenshot :-) (and yes, despite the smiley I really mean that — every game-website is stronger with a screenshot)
<leoprikler>Oh, sure, I just haven't written enough free games with it.
<leoprikler>It also needs a logo, of course.
<ArneBab>that’s my problem with enter-three-witches, too :-) — dryads-wake is the first that I hope to get actually playable
<leoprikler>Which means that next month I'll have some AI generate more anime faces.
<leoprikler>If we dedicated all our crypto mining GPUs to generating anime portraits, we'd still have the same emissions, but at least it'd be worth it.
<leoprikler>How do we solve this issue? By inventing a crypto currency with an anime portrait based proof of work scheme.
<ArneBab>do you mean something like this? https://www.thisfursonadoesnotexist.com/
<ArneBab> https://thisanimedoesnotexist.ai/
<ArneBab>https://thisanimedoesnotexist.ai/downloads.html
<ArneBab>not to forget: https://www.thiswaifudoesnotexist.net/
<leoprikler>needs to have a torrent option imo
<ArneBab>(I knew it would one day come in handy to keep these bookmarks around :-) )
<ArneBab>⇒ upload to a torrent tracker? It sounds like it’s legal.
<ArneBab> https://www.thiswaifudoesnotexist.net/
<ArneBab>(wrong copy buffer — this one: https://www.obormot.net/demos/these-waifus-do-not-exist-v2-alt )
<ArneBab>now I really need to sleep — I hope these help you!
<leoprikler>btw. I was originally referring to https://www.artbreeder.com/ since it comes with the clear restriction, that all images generated from it must be cc0
<leoprikler>good night :)
<ArneBab>same to you!
<wingo>rlb: hooo good question (re: racing writes on shared mutable strings). i guess in general i don't mind making string-set! arbitrarily slow, but we should do all we can for string-ref -- requiring locks would be unfortunate!
<wingo>rlb: what happens to concurrent string-ref when string-set! needs to expand the stringbuf because the codepoint takes a different number of bytes?
<wingo>in the non-shared case
<rlb>The way I have things right now, strings only contain their char count and offset into the stringbuf, and the pointer to the stringbuf. stringbufs never resize in place (so byte offsets don't change for other internal operations). Given that, if it's mutable, and we're replacing chars of the same size, we may mutate them in place (as we used to), but otherwise we create a new stringbuf, copy the contents (while making the relevant
<rlb>changes), and then do a simple assignment to swap the stringbuf pointer in the shared string. No locks.
<rlb>So as per our docs, unrestricted concurrency could cause weirdness, but shouldn't crash anything (in theory).
<rlb>But it does mean that two operations can race to create the new adjusted stringbufs and "last one (swapped in) wins".
<rlb>Hence two competing string-set! operations on a shared mutable string could result in one of the updates being lost.
<rlb>(for example)
<rlb>string-ref is lockless too, and it's one index lookup followed by a search of up to "stride" chars to find the exact location. The stride depends on the string length, right now 16, 32, 64, or 128 (as an upper limit if the string is larger than 4GB).
<rlb>But don't spend too much time worrying about this unless you just want to. What I have now is unfinished, and has grown to be a good bit more work than I'd initially imagined. I do seem to keep working on it, but no idea if I'll actually finish it up well enough to have something worth proposing.
<rlb>(As mentioned mostly just wanted to make sure I wasn't doing something that already seemed clearly unacceptable.)
***apteryx is now known as Guest50260
***apteryx_ is now known as apteryx
<lampilelo>if a user is calling string-set! on a shared string from different threads without any synchronization he's asking for trouble
<wingo>rlb: races for unlocked operations sound fine to me. (famous last words?)
<nly>is reactjs fine from a free software perspective?
<jlicht>nly: afaik, it seems to be perfectly fine free software
<jlicht>nly: I advise you to look into the patent situation, as I recall there being some potential issues
<nly>thanks
***zap1 is now known as zzappie
<dsmith-work>Happy Friday, Guilers!!
<mwette>hey all!
<zzappie>hellou
<rlb>wingo: ok, thanks, and of course I suspect in most cases, if we make this switch, string-set! and (bulk string-refs) will be best avoided (i.e. in favor of string-map/tabulate/for-each/etc.).
<rlb>(Internally, those won't use string-ref, etc. anymore.)
<lampilelo>rlb: is your wip code published somewhere?
<Noisytoot>What's the difference between use-modules and import?
<RhodiumToad>import is from RnRS, use-modules I believe is a guile-ism
<RhodiumToad>otherwise they should be compatible in the sense that any given module should be importable either way
<RhodiumToad>though I do recall some breakage with import from a while back
<RhodiumToad>oh yeah, it's (library) rather than (define-module) which is the issue, (library) was losing all source location info
<dsmith-work>import is more along the lines of C #include I think. It basically inserts the forms from the file at the point you call import.
<dsmith-work>use-modules is more like load. Happens at top level. But it also does a bunch of binding management.
<dsmith-work>(I've seen that use-modules calls load deep under the hood)
<RhodiumToad>last I looked, import was just syntax for use-modules
<dsmith-work>Oh!
<dsmith-work>was thinking of include, not import !
<alextee[m]>is there a roadmap for the next guile release somewhere?
***sneek_ is now known as sneek