***sneek_ is now known as sneek
<mrf>hi, can anyone give example on using vector-move-right! I cannot get it to work <mrf>I do that and my function fail: <mrf>(let ((v1 #(9 8 7 6)) <mrf> (vector-move-right! v2 0 2 v1 1) <nly>So, i wanna know how you setup a nginx front to a guile server. It's to serve static files. <mrf>what wait, you setup web server with scripting language to serve static files? I don't know specifically how to do that but genreally you forward some proxy port of your guile server to nginx which will convert it to some part of your domain in 80 port or something <lampilelo>mrf: in this example you're creating immutable vectors and then try to mutate one of them, what you need to do is create a vector not with #(1 2 3) syntax but with (vector 1 2 3) <nly>nginx -> static files <nly>guile -> the good stuff <nly>my communications skills -> sucks :) <meo>is it okay to override srfi-9 record constructors? <meo>well it certainly does work <ArneBab>safe as in „you do not have to think about it“ <leoprikler>I think we might want to update guile-wisp with that in mind, but I'll eat now. <ArneBab>as long as they do not remove the copyright header from the wisp.scm and spec.scm file, they are safe. (point in case: a German startup recently got flak because they did that) <ArneBab>Since they use Guile already, this still favors free licensing, but it removes a stumbling step. I conside that as a strategic step, because there are already many proprietary game engines in use. Replacing them by games that use Guile spreads free licensing. <ArneBab>The only risk could be that someone ports wisp to an unfree Scheme implementation, or ports wisp and makes the port proprietary, but having even a single additional game written in wisp using Guile is worth that risk, I think. <daviid>i thought wisp was using the same license as as guile lgpl - <daviid>ArneBab: fwiw, i would not take such a risk <ArneBab>daviid: the original wisp language implementation is the implementation for a SRFI, so it had to be expat-licensed. The changes since then are pretty small. The surrounding files are GPLv3+ (most of my work over the past years was on examples) <ArneBab>daviid: but I well understand not taking that risk, I was also conflicted. <ArneBab>daviid: in the ideal case for me, wisp would be included in Guile as a regular supported language, then it would be LGPL and there would be no issue for games that use Guile. Currently games must either add a second dependency or embed wisp. <ArneBab>daviid: my previous attempts to get wisp included as supported language in Guile sadly failed, making the embedding of wisp as painless as possible is the second best option. <daviid>yeah, i would not have made it srfi in the first place srfi 'forced' license is a problem, not a solution ... but ... <leoprikler>daviid: When we compete against ren'py, I think that fear is probably not warranted. <nly>(use-modules (json)) <nly>scm->json ;; procedurce <sneek>stis, wingo says: tx for report, fixed :) <stis>wingo: Great, this enables quite a speedup in python on guile! <wingo>if you use prompts for non-local control flow like "break" etc there are quite a number of other optimizations that could be made <wingo>like if you can identify an abort for a prompt and it's within the same function, we could wire the abort to the handler <wingo>and if that's the case for all aborts for a prompt, the prompt can be elided <wingo>haven't implemented those passes yet tho <wingo>if we had that and a proper SSA/CPS conversion pass for mutable memory, then we would have a good compiler for more kinds of languages :) <wingo>well, anything with that flavor: js, python, c, etc <stis>wingo: that would be great. I know that with current prompts we get the same speed in math loops as python and significantly faster without let/ec <stis>so we know that those opptimisatoins make a difference for python on guile. Also manumanumanu and I have a tagbody implementation and thiese should be significantly faster with the right optimisatoin pass of the compiler <stis>The final step towards getting native scheme speed would be to enable good optimisatoin of boxed variables in some way (python is littered with set! semantics) <mwette>imperitive languages are going to hammer on escapes and set! a lot; in nyacc I have a generic module for language translation that is littered with "(primcall make-prompt-tag (const ,tag) ... (prompt #t ,tag ,body ,hdlr) <manumanumanu>Well, stis says I have a tagbody implementation, but what he really means is I have a bit of steaming hot mess I wrote when I was still a puppy. I tried it back when we talked about it and it fails on nested tagbodies. ***DadeBonetti1 is now known as DadeBonetti