IRC channel logs


back to list of logs

<ArneBab>oh shit, it works …
<ArneBab>dthompson: how do you want your patches?
<ArneBab>dthompson: you have an email with a patch
<ArneBab>you can use ./run-example sprite-ecmascript to show the sprite from ecmascript (and also ./run-example sprite-wisp to show it from wisp, but that was really easy to do :-) )
<ArneBab>limitations: ecmascript seems to not support syntax-transformers yet, so all the define-inlineable error out.
<dthompson>ArneBab: thank you!!! I was afk making dinner
<ArneBab>I’ll send you an updated version with a note at the top of the ecmascript file that warns that this is a hack
<dthompson>ArneBab: that's okay. I don't think I'll actually include the ecmascript version since it's such a hack.
<dthompson>but definitely the wisp version
<dthompson>neat to know it's possible though!
<ArneBab>yes :-)
<ArneBab>you have an updated patch now
<ArneBab>Thank you!
<ArneBab>(re wisp)
<singpolyma>ArneBab: can you explain more to me about the syntax-transformers thing. Is that macro related?
<ArneBab>actually if the syntax-transformer issues could be worked out in ecmascript this could be the most lightweight way to write games in javascript.
<singpolyma>(yes, I'm not really a schemer it turns out...)
<ArneBab>singpolyma: I think so. Chickadee uses (define-inlinable ...) to eek out more performance and ecmascript seems to still lack support for that.
<singpolyma>Is define-inlinable guile or part of this thing?
<dthompson>part of guile
<dthompson>hopefully won't be needed much longer now that guile is beginning to do cross-module inlinining automatically
<singpolyma>Cool. I will put that on my mental list to figure out the interop situation
<ArneBab>more up to date:
<singpolyma>This sounds like a more generally interesting use of guile polyglot than guix stuff I've been hacking on
<ArneBab>Yes, and it’s something that would actually also bring value to Javascript hackers
<singpolyma>One game written in a mix of scheme, JS, Lua, python, etc
<ArneBab>because it frees them from the huge runtime of browsers/node without going to a very slow implementation
<singpolyma>Use the library no matter what language it's from!
<dthompson>how does the ecmascript implementation work? does it compile to tree-il?
<ArneBab>You can actually re-use code from any language in any other one by simply byte-compiling it.
<singpolyma>Pretty sure the Lua and python do the same, but I'm less familiar with their internals
<dthompson>that's what I figured but was too lazy to check :)
<ArneBab>And you can byte-compile by loading it with guile --language=<lang> -x .<ext> -e '(<module-name>)'
<dthompson>ArneBab: as for 'chickadee play' I'd like to add a --language flag to mirror guile. that should enable that tool to work with wisp or whatever else.
<ArneBab>singpolyma: does ecmascript in Guile already support creating modules from it?
<ArneBab>dthompson: that would be cool! You’ll also need the -x flag to extend the search for other extensions.
<ArneBab>As in run-example :-)
<dthompson>ah I'll have to see how that works
<singpolyma>Not sure, I usually load from a scheme shim because guix doesn't have --language and guile doesn't have #lang yet
<ArneBab>run-example should give you all the info needed.
<dthompson>I need to see how -x is implemented and do the same
<ArneBab>singpolyma: I’m not sure Guile should get a #lang — that breaks the unix hashbang
<dthompson>chickadee play isn't a bash script that starts guile or anything. it's a guile program.
<dthompson>so it will need to modify current language and whatever -x modifies
<dthompson>ah it's just %load-extensions
<singpolyma>ArneBab: how does it break shebang? Anyway, file extension support would be my preference to #lang but whatever works
<ArneBab>singpolyma: unix specifies that you start files with #!/path/to/executable to run them as scripts. I use for example this (see at the top):
<ArneBab>dthompson: yay!
<singpolyma>ArneBab: yes, I know, but that doesn't affect the ability to have a syntax to specify the language of a file. Shebang is first line, all lines after that can be anything you want
<ArneBab>so you mean #lang as a toggle to switch to another language mid-file?
<singpolyma>And also this mostly matters for modules not scripts you run
<singpolyma>I mostly mean to use file extension to be able to load a .js file using use-modules and have it detect to use the right language etc
<ArneBab>This is for convenience, right? In a project I could already get that as part of the make-step by pre-compiling the files.
<singpolyma>Hmm, maybe, I haven't played with the "pre compile" stuff much
<ArneBab>find . -iname *.js | xargs -I {} guile --language=ecmascript -x .js -s {}
<ArneBab>(though this will require a topological sort of all dependencies …)
<ArneBab>The *.go files are language-independent, so they already go pretty far.
<singpolyma>Right. So if you use guile as a compiler and write a makefile and stuff maybe you can cheat
<ArneBab>even easier: guild compile -f ecmascript examples/sprite-ecmascript.js
<ArneBab>now sprite-ecmascript is available as guile module.
<ArneBab>and any other language can load it
<ArneBab>and this does not require all dependencies compiled beforehand
<ArneBab>Whether this could be automated by extension is something that may need interactive discussion with people who understand the implications of the different possible decisions better than me
<singpolyma>I will have to play with this more
<singpolyma>Also means I could compile out of tree languages in CI and ship .go to people who don't even have that language in their guile install?
<singpolyma>No, because .go aren't portable. Right. Because you have to rebuild when guile version changes
<singpolyma>So only if their system is *very* similar to mine
<ArneBab>Yes, you can do that — you’ll have to do it for different platforms — as Guile does it for releases.
<ArneBab>You can cross-compile.
<singpolyma>Maybe they aren't as brittle as I thought then
<dthompson>ArneBab: do you know to programmatically load a wisp file?
<dthompson>I know I can do (parameterize ((current-language 'wisp)) ...) to set the current language
<dthompson>but I haven't been able to load successfully yet.
<singpolyma>dthompson: you can load with a language using compile
<singpolyma>compile to value
<dthompson>ah okay
<dthompson>ArneBab: I got wisp working with 'chickadee play' :)
<dthompson>singpolyma: thanks again for the tip about compiling
<dthompson>not going to commit anything tonight. need to test stuff out more. but I got the sprite example working.
<ArneBab>sneek: later tell dthompson: awesome! Thank you!
<sneek>Will do.
<Zelphir>Hi! I have questions about (apply ...). (1) Why is it called "on the fly evaluation" in the manual? and (2) I see in the manual, that it is defined up to 3 not spliced list arguments: `(proc, arg1, arg2, arg3, arglst)` and then `(proc, arg, rest)`. Is it impossible to define it for more not spliced arguments in a general way, without adding one definition per 1 argument more?
<Zelphir> ( is the page I am talking about.)
<dthompson>Zelphir: I think you're looking at C functions, which seem defined for convenience to not have to build a list in some cases.
<sneek>Welcome back dthompson, you have 1 message!
<sneek>dthompson, ArneBab says: awesome! Thank you!
<dthompson>I don't actually know what the scheme version of apply is optimized for. it could use case-lambda to optimize a lot more than 3 non-list args.
<dthompson>ArneBab: I pushed a commit to chickadee master that adds non-scheme language support to 'chickdaee play' and adds docs that show how you could use Wisp, specifically.
<Zelphir>dthompson: Ah now I get it. I thought the Scheme function is always using the C function written below it, but actually the text say: `Scheme Procedure: apply proc arg … arglst` so I guess it is already general!
<dthompson>Zelphir: that's right, and under the hood it's probably (haven't looked) optimized for a variety of 'arg ...' lengths
<dthompson>which will allow for calling a procedure without consing
<Zelphir>Recently I did not know about the "special rules" of how apply works and thought: "Ah damn, but I cannot use it, because I have some arguments, which I don't want to be spliced, because they are not a list, and I have a list which I need to be spliced. What only can I do now?!" -- But then I ran geiser and looked at the minibuffer and saw, tried it, and learned, that I _can_ use apply that way. Then I thought: "Ah they thought of everything again! So
<Zelphir>I think it even works with keyword arguments.
<dthompson>Zelphir: yup, it does.
<dthompson>ArneBab: I forgot to mention this yesterday: 'chickadee play' has a --repl command that should start with readline enabled automatically. add that to the error handling and having redefinable game loop event handlers and it's a pretty good prototyping solution.
<ArneBab>dthompson: thank you!
<dthompson>ArneBab: np! thanks for the wisp help!
<ArneBab>very happy to help :-)
<dthompson>ArneBab: I also pushed a commit that updates the game loop error handling to use guile's new exception api. I am quite happy with the results when combined with 'chickadee play --repl'.
<ArneBab>wow — that’s awesome! I’ll have to give it a try. A real full-blown REPL for development is great!
<Zelphir>Is there a way of optionally pattern matching something? I mean, "zero or one times"? I look at, but I do not see a way to do it, other than having 2 match clauses, one matching the form with and one matching the form without the optional part. I was thinking, if there is a way to optionally match something, I could condense my match clauses a bit, into fewer ones.
<Zelphir>(And I cannot use `...`, since I am already matching using `...` on the same level of nesting later in my matched form.)
<Zelphir>Optional matching would probably also mean optionally inserting into the result expression, I guess.
<jpoiret>if you're using ... later in the matched form, it's definitely not possible to have an optional argument
<jpoiret>Zelphir: ^
<jpoiret>otherwise guile won't be able to know what arguments should be where
<lilyp>Zelphir: you can match within a match :)
<Zelphir>I understand, that multiple `...` on the same level are ambiguous. I guess for an optional thing and afterwards `...` it is the same reason. Guile wouldn't know whether the optional part is there or not, because the `...` makes it so that the total number is arbitrary, so not known/knowable.
<Zelphir>What do you mean by "match within a match"? I thought it would not make a difference, but: I actually am trying to write a macro and am pattern matching there. Can I do a match within a match in a macro?
<lilyp>oh, in syntax-case you do have a little more freedom in matching
<lilyp>though i guess for maintainability it'd probably be better to define helpers wherever you can
<Zelphir>I think I cannot properly explain this, without giving an actual code example. So I have this code: and one can look at `lambda*-with-contract` and see, that I have 2 clauses. One with `function-name` and one without `function-name`. Usually `lambda...` wouldn't carry a name, but I need it for error reporting, in case the function's
<Zelphir>contract is violated and the name comes from other macros, when they expand to `lambda*-with-contract`. See for example `define-with-contract` in the same file.
<Zelphir>Now I noticed, that I need to add another feature, because my macros do not match (lambda (bla blub . rest) ...). I've not thought of matching the rest arguments form of a lambda. But this is the second "feature" that I need to distinguish. Every additional feature multiplies the number of clauses by 2.
<Zelphir>So I am searching for a way to collapse clauses. So I thought of "optionally matching" the `function-name`.
<Zelphir>In this specific case, I could indeed simply add more clauses, but maybe I can do something better somehow.
<antipode>Zelphir: You could implement the 'doesn't have name' case in terms of 'doesn't have a name' (by interpreting 'name=#false' as 'no name'
<antipode>(modifying to use only add the 'make-exception-with-origin' when 'function-name' is #false
<antipode>* not #false
<antipode>(The compiler could optimise things out.
<antipode>Also, you aren't using things like 'syntax-case' or 'with-syntax' anywhere, so I expect the syntax->datum to be incorrect, how about 'function-name ?
<antipode>On simplifications: define-with-contract seems simplifiable --
<antipode>... nevermind.
<Zelphir>I am not sure I understand. I understand the idea, that I could give function-name some value, that I use for indicating, that the function name is "not given". But then I could not use the `lambda*-with-contract` on its own any longer, without the user having to know that special value.
<Zelphir>My second question is: Why is `syntax->datum` wrong? Should I be using it with `(quote function-name)` or 'function-name as argument?
<Zelphir>Ah you mean I should be using (quote ...) instead of (syntax->datum ...) ?
<Zelphir>I'll try replacing the `syntax->datum` with `quote`.
<antipode>Zelphir: It's wrong because after expanding, you will get (syntax->datum the-function-name)
<antipode>but the-function-name is a procedure, not syntax, it likely needs to expand to 'the-function-anme instead.
<antipode>(What, exactly, is needed, should become clear after just trying things out).
<antipode>On: But then I could not use the `lambda*-with-contract` on its own any longer, without the user having to know that special value
<antipode>You still can?
<antipode> Just let the user do whatever they were using before.
<antipode>And make your 'lambda*-with-contract' recursive: in the 'no name' case, expand to (lambda*-with-contract #false [other things] ...)
<Zelphir>Ahhh that's clever.
<Zelphir>Adding a case for the user's convenience.
<antipode>Also, I think I see a a problem in 'lambda-with-contract', 'require' is not added to the literals list.
<Zelphir>I just tried with (quote function-name) and that works well, apparently. No idea any longer, why I used syntax->datum there.
<antipode>So (lambda-with-contract (foo) (bar) (baz) whatever whatevr*) will be interpreted as the first case, even though it's bogus.
<Zelphir>OK let me try to understand.
<antipode>It's ‘This will cause syntax-rules to be aware of them as identifiers' that's incorrect.
<antipode>Only adding the identifier 'require', 'ensure', ... to the literals list (currently ()) will do that.
<Zelphir>Ah I think I did that, because they are defined as identifiers above at the top somewhere, so that the user can rename them when importing.
<Zelphir>I think I got that idea from the mailing list.
<antipode>Zelphir: Can you point me to the location where you add them to the literals list?
<Zelphir>Not sure I did it correctly though.
<antipode>(the literals list is the () in (syntax-rules () ...))
<Zelphir>I did not add them to literals, I defined them above as identifiers. I thought that was needed to make them rename-able.
<antipode>It isn't.
<antipode>(define foo ...) is good for renaming, but there's a reason for the literals list.
<antipode>If you don't mention an identifier in the literals list, then it's matched as some kind of variable, not as a literal.
<Zelphir>Should I do both? (define require ...) and adding to literals list?
<antipode>It surely needs to be in the literals list, such that Guile doesn't think that 'foobar' makes for a good 'require'.
<antipode>The (define require ...) + (export ...) is optional, for renamability.
<Zelphir>Ah hm. I understand.
<Zelphir>Somehow I thought, that adding them to the list of literals would mean, that I have to use the name `require` literally when defining a function with contract, and could never rename.
<antipode>IIUC, you use the identifier 'require' literally, but the name of that identifier depends on whether you are renaming things.
<antipode>(name of identifier = symbol)
<antipode>but er, definitions, and I don't think the Guile manual did some kind of formal definition of identifiers vs symbols
<Zelphir>Just tried renaming with having `require` and `ensure` in the list of literals: All works fine!
<Zelphir>OK, using something "literally" then means, that it is exactly using that "thing", but "thing" can still have other names.
<Zelphir>If I understand that correctly.
<antipode>Zelphir: Yes.
<antipode>By default, any symbol in a clause (e.g. function-name) is just a placeholder, to match literally, you need to add it to the literal list. (Or do tricks with syntax->datum + eq? + syntax-case, which can be useful to _not_ allow renaming and _not_ require importing).
<Zelphir>Is there a reason, why you suggested using `#false` for the "no function name" case, instead of something like `no-function-name`? I am guessing, that I have to add `#false` to the list of literals, but how would I check, that `function-name` was given as `#false`?
<Zelphir>I could make an identifier for that as well, which has the value of some symbol, so that I can compare with (eq? ...) or something.
<old>Is there a way to match a variable value such as `AF_INET` and `AF_INET6`?
<Zelphir>I think those are actually integers.
<old>Doing something `(match x ((or AF_INET AF_INET6) ...) (AF_UNIX ...))` will consider the AF_* as pattern variable and bind x to it
<old>But I would like to be able to say if x match the value in either AF_INET or AF_INET6
<old>Kind of like `case' can do
<antipode>Zelphir: Someone could name their function 'no-function-name'.
<Zelphir>If I use an identifier defined inside my module and use it like with `require`, I should be safe, right?
<ArneBab>sneek later tell dthompson: When using chickadee play, I got chickadee/image/png.scm:354:31: ERROR:
<ArneBab> 1. &message: "PNG images using color palettes are not supported"
<ArneBab>In chickadee/graphics/texture.scm:
<ArneBab> 404:20 2 (call-with-loaded-image "walking_dragon-ari.png" #f #t #)
<ArneBab>how can I fix that?
<ArneBab>sneek later tell dthompson: 1. &message: "PNG images using color palettes are not supported" at In chickadee/graphics/texture.scm: 404:20 2 (call-with-loaded-image "walking_dragon-ari.png" #f #t #)
<old>ArneBab: Is there documentation for Sneek?
<ArneBab>sneek help
<ArneBab>sneek: help
<ArneBab>sneek: info
<ArneBab>old: I’m not sure :-)
<ArneBab>yes, there is: sneek: help and sneek msg’s you.
<ArneBab>sneek: help
<old>oh nice
<old>Gotta know that sneek is a bot in the first place
<old>sneek: help
<old>sneek: who is sneek
<sneek>Last time I checked sneek is many things.
<old>sneek: what is Guile
<sneek>I could be wrong, but Guile is an implementation of the Scheme language.
<old>Good bot
<ArneBab>sneek: botsnack
<ArneBab>sneek: later tell dthompson: The way I found to start a script with the lowest possible latency is to define a module and then run it with guile -L . -e '(module name)'
<sneek>Will do.
<old>So I just realized we don't have a guile-smtp. I would have like to be able to send email from guile D:. guile-email seems to only support reading
<antipode> I think we have a reading/sending library ...
<antipode>'mailutils' has Guile bindings.
<old>Only for guile-2.2 :(
<antipode>old: Looking at the package definition of 'mailutils' in Guix, it appears to have guile 3.0 bindings.
<old>you're right!
<antipode>Looking at "guile2.2-mailutils", it appears to be just a variant of "mailutils" for 2.2!
<old>I just check with guix-build and bindings are part of the mailutils
<old>kind of like gnutls
<antipode>OTOH it is bindings to something that's probably C, not pure Scheme code, can be harder to debug and probably doesn't integrate at all with tings like guile-fibers.
<old>Right. But that is fine with me. Only have to send a 2 lines email for students. Just don't want to use Python for that
<ArneBab>sneek: later tell dthompson: Please tell me once you have a new chickadee release so I can link it on the wisp page!
<sneek>Got it.
<ArneBab>sneek: botsnack
<old>sneek: Tell me a joke
<sneek>me, old says: a joke
<antipode>civodul: ‘build-system: Factorize 'strip' flags and directories.’ looks nice
<old>sneek: bad bot
<trevdev>Heya Guilers. I have a script that I have working if I execute it in the shell, or as a mcron service if I invoke it with mcron -d. However, if I instantiate mcron with systemd, it fails. My other mcron scripts work
<trevdev> I am calling notmuch to return a list of mail files but it seems as though (system*) is returning a weird #<eof> object instead of the output of notmuch. I think this is some user environment problem that gets lost in systemd but I am not sure how to clarify it from here.
<two[m]>"no such language scheme"
<trevdev> I am getting a stack trace so it's at least executing the script with guile :/
<two[m]><trevdev> " I am calling notmuch to..." <- i think systemd had a command to get a shell inside a service's env. can't find it tho
<trevdev>I can
<trevdev>I can't get Guile to output some message with display in systemd, as usual, systemd is pissing me off
<trevdev>herd did not seem to have any problems just running a script