***Fuuzetsu is now known as Guest53387
***Guest53387 is now known as Fuuzetsu`
***Fuuzetsu` is now known as Fuuzetsu
<ArneBab>Fuuzetsu: when forced to use git, I use gitorious, and it works quite well. <Fuuzetsu>ArneBab: Sure, it works, but as I said, exposition <ArneBab>Fuuzetsu: I find the interface of gitorious to be more pleasing than the one from github: They do not try to force javascript transitions upon me… <ArneBab>Fuuzetsu: (use-modules ((foo bar) #:select ((baz . bar-baz) moo) ; and then you can also add prefixes and such) <ArneBab>(I was still in the backlog till now ☺) <ArneBab>Fuuzetsu: You could just have a gitorious repo as default repo and add a clone to github. <ArneBab>Simply keep it synced with a cron-job and you won’t have to worry about it. <nalaginrut>now I think it's ready to work for daily blogging <nalaginrut>I don't know if it's proper to format patch to tekuti upstream, but this one contains my personal taste ;-D <civodul>hey wingo, great post as usual, and neat tool that you wrote! <wingo>the tool is in guile-charting, fwiw <wingo>which is a really hacky library, but oh well <ArneBab>nalaginrut: can tekuti parse to static HTML? <ArneBab>nalaginrut: ah, you mean sxml for the templates? <nalaginrut>but I don't think there's static-page emit in the original tekuti <nalaginrut>to me, it's not any problem, because tekuti is behind nginx, and all the static pages handled by nginx <ArneBab>that’s the main requirement I have for the new way to write I’m searching for… <ArneBab>(but I think I need more automation) <nalaginrut>ArneBab: well, you don't have to use tekuti if you just need org-mode <ArneBab>nalaginrut: org-mode misses some automation as well as a way to edit pages remotely without SSH access. <ArneBab>I run my sites on a basic LAMP hoster. <nalaginrut>oh, you need the blog-engine to render the org file? <ArneBab>I would need something like the ikiwiki of the Hurd wiki: An edit-link which goes to my local machine, which then parses the changed file, creates a new version of the static site and uploads it. <Fuuzetsu>ArneBab: In that case I could as well just stick to GitHub. Having a repo at both is just cumbersome. <ArneBab>Fuuzetsu: why is that cumbersome? (it’s just a cron-job) <Fuuzetsu>because then I have to deal with two issue trackers, commit hooks on both etc. etc. <ArneBab>echo 'cd ~/your-repo; su YOU -c "git push <github-repo>"' > /etc/cron.daily/10-sync-github-clone.cron <ArneBab>can’t you just disable the github issue tracker and such? <nalaginrut>ArneBab: tekuti based on git, so I think you have a chance to implement it <Fuuzetsu>ArneBab: And then require everyone to file issues on Gitorious? No thanks. The matter of fact is that a lot more people have GitHub accounts and if exposure is what you need, you want to be where people are. <ArneBab>nalaginrut: “have a chance to implement it” ← not what I am searching for ☺ (otherwise I could just write me a small web-interface to the org-mode files with a Makefile which evokes org-publish) <ArneBab>Fuuzetsu: depends on your goal. Sometimes you have to make a pact with the devil to get something else forward. <Fuuzetsu>The only reason I'd like to move to Gitorious is that it's FOSS and if my own software suffers because of the move then I'll just deal with it on GitHub <nalaginrut>ArneBab: well, I think you need a static page generator? just like Hyde/Jekyll? <ArneBab>nalaginrut: maybe I’ll write an org-mode editing web-interface when I have time… <nalaginrut>with a tool to generate pages then upload in a row ;-) <Fuuzetsu>BitBucket doesn't have the commit hooks I'd like and I dislike the interface <Fuuzetsu>+ nearly all the projects I write for are on GH anyway <ArneBab>Fuuzetsu: I generally use Mercurial instead of Git, so GH wouldn’t be an option anyway. But if I used Git, I’d use gitorious. <ArneBab>wingo: your ELF visualizer fails at my tiny elf ☺ <ArneBab>wingo: but my tiny elf is just defined as “works on Linux”, not as “adheres to standards” <ArneBab>wingo: does master hold your new code? <wingo>if your elf file has no section table, the thing will fail :) <wingo>most of the code for that little demo is not in guile <wingo>but the article describes guile master, yes <ArneBab>wingo: I meant the CPL work you did - because the runtime for my test function decreased from 4 minutes to 1.5 minutes when going from stable-2.0 to master <wingo>you could probably remove the text section actually <ArneBab>I can actually go down to 260 bytes (this then adds stuff to the ELF header), but when I go the next step to 91 bytes, I only get a blank page ☺ <ArneBab>(this is not my work, by the way. I just put the steps into a repository and tested them one by one so I could check and understand them more easily) <nalaginrut>only about/projects has pages, others are missing, I haven't write it ;- <ArneBab>no problems - I guessed that that was the reason ☺ <ArneBab>wingo: now I understand your confusion - it’s CPS language, not CPL. Sorry… <nalaginrut>I encountered a strange issue, after I copy all *.go to the correct cache dir during installation, Guile still compile the files <ArneBab>the benchmark suite says “benchmark-suite/lib.scm:310:4: Throw to key `unresolved' with args `()'.” <ArneBab>I guess that the problem is that I did not enable french locale in /etc/locale.gen… <nalaginrut>oh! unfortunately, %load-fallback-path is set in the initialization of Guile, seems no way to regenerate it dynamically <civodul>wingo: how does your server cope with the requests? :-) <wingo>civodul: load average: 0.00, 0.01, 0.05 <wingo>actually generating a graph takes about 0.2 seconds or so, and there aren't many people doing that <wingo>most of the time is spent in doing the .so upload, which isn't cpu intensive <wingo>i haven't taken a look at the memory though <wingo>it's a denial-of-service vector, as i don't have a limit on the upload file size <nalaginrut>wingo: is there anyway to get FALLBACK-PATH only? in scheme code? <wingo>nalaginrut: %compile-fallback-path <nalaginrut>wingo: but when I use sudo, the path is for root <wingo>the uploaded file doesn't go to disk though, so if the web server falls over it just gets restarted and no worries *wingo finally reading olin shivers's dissertation <wingo>i think the next step in guile's compiler and runtime is using a VM that separates type predicates from accessors <wingo>and which runs a type recovery pass to elide predicates as needed <wingo>and which can use unboxed accessors <wingo>from there you could generate quite optimized native code <wingo>e.g. inlining (car x) as (if (pair? x) (%car x) (%error)) <wingo>or (begin (%assert-pair x) (%car x)) <wingo>that could yield a slower vm though :) <wingo>i guess we could proceed in that direction by adding unboxed / raw primops to the vm, and using them when type recovery allows us to do so <ArneBab>wingo: do you have your own benchmarks of the speed difference between 2.0 and 2.2? <ArneBab>wingo: running the working parts of the benchmark suite goes down from 1:13 to 0:50 <wingo>the benchmark suite is kinda silly <ArneBab>but the ackermann-code I tested got a much stronger speed increas <wingo>would be nice to have a better one <wingo>yes it varies from nothing to 300%, pretty much <ArneBab>300% is pretty much: 2.0 is already on-par with python3, after all. <ArneBab>so at least some workloads should be quite a bit faster than python now <wingo>yeah, dunno; for me the competitors are javascript, haskell, rust, go, racket, ... <wingo>and pypy and lua of course :) <ArneBab>wingo: a real testsuite could reuse the racket-programs from the benchmarksgame <wingo>they would need some adaptation <ArneBab>there’s a bit of incompatibility in the syntax <wingo>i have previous engagements at home <ArneBab>wingo: you’re right - the racket scripts need a bit of work to adapt… <ArneBab>it took me 15 minutes to adapt nbody… <wingo>jemarch: indeed, and i missed it last year too <ArneBab>only one which already works: nbody. <davexunit>I have a procedure whose parameter list runs over 80 characters. is there an appropriate place to break the line? <davexunit>(define* (spawn-coop-repl-server #:optional (server-socket (make-tcp-server-socket))) ...) <nalaginrut>nowadays wide-screen LCD is very popular, I'm considering to drop the 80 chars principle... <davexunit>I like the 80 chars rule because it means that I can view many files at once side by side without scrolling. <davexunit>my thinkpad has 1366 pixels of horizontal space, so I can only split 2 files. <davexunit>but I also have a monitor with 2560 pixels of horizontal space. <nalaginrut>hmm...but it's not so easy to limit the length of name in lisp code *davexunit is fixing up the coop repl patch. <davexunit>supporting multiple servers was something that I didn't consider, hmm. <nalaginrut>I find myself dislike abbreviated naming, say, scheme-function ==> scm-func <mark_weaver>wow, that's obnoxious. someone I don't know added me to a google group without asking me, and the helpful "unsubscribe" link provided by Google apparently doesn't work unless I run their non-free javascript code. <mark_weaver>well, it's possible that it worked, but all I see is an error about lack of javascript. <dsmith-work>Wow. Other people can add you to group without your consent. <mark_weaver>I don't even know the language of this group. I had to use a translation service to even find out what the group is about. <mark_weaver>in other news, it seems that all of the clang builds for guile on hydra are now failing, with segfaults the first time guile is run. <mark_weaver>davexunit: oh, I forgot to mention in my review: why does the prompt name 'coop-coop-repl-prompt' have two 'coop's in it? <davexunit>mark_weaver: find/replace mishap. I saw that this morning. d'oh. <davexunit>working on removing the global mvar now. then to fix that bug with stopping all clients. that's going to be a tough one, I think. <mark_weaver>davexunit: also, don't forget to add 2014 to the copyright dates of any files you modify. <mark_weaver>davexunit: regarding 'stop-server-and-clients!', I see that all it does it close all the sockets. when all the code using the sockets are in other threads, I guess this just kills those threads. in your case, the REPLs are in the main thread, so this causes problems for the main thread. <mark_weaver>fixing this might be as simple as catching (and ignoring) exceptions that happen within poll-coop-repl-server. <mark_weaver>and it might also not be in quite the right place, given the prompts. *mark_weaver looks at the code <mark_weaver>davexunit: I think 'start-coop-repl' might be a good place to catch the error. <davexunit>mark_weaver: have to go afk (and just was afk). I'll read this over shortly. thanks for the help. <mark_weaver>davexunit: you might also need to wrap the 'close-socket!' at the end of 'start-repl-client' with 'false-if-exception' <mark_weaver>alternatively, 'stop-server-and-clients!' could be made to work in a different way. that would probably be better than ignoring exceptions. <cky>mark_weaver: Hey, before I post this on-list, do you think anybody would be interested in an implementation of Clojure's #(...) reader macro? (In Guile I've used ##(...) since #(...) is used for vectors.) In a nutshell: (cut foo <> bar <> baz <...>) => ##(foo %1 bar %2 baz %&) <cky>By "interested", I mean as an in-tree module (maybe in ice-9, maybe elsewhere). <cky>Nice thing about this over cut is that you can write a hypot function like this: ##(sqrt (+ (* %1 %1) (* %2 %2))) <davexunit>mark_weaver: perhaps I could catch a specific type of exception rather than swallowing up any exception that may occur? <cky>Also, in writing the above, I had a recollection that in Guile, gensyms are interned. It seems an odd choice to me, seeing as in both Racket and Common Lisp, gensyms are uninterned. <mark_weaver>cky: well, gensyms end up as literals in macro transformers, which then have to be serialized. not sure how racket deals with that. <mark_weaver>cky: regarding the reader macro, it doesn't look very appealing to me, but I'm just one data point. feel free to post about it! <mark_weaver>IMO, I like the solution of using a shorter name for lambda, like λ or ^ <mark_weaver>and then using plain lambdas is not nearly so painful. <mark_weaver>Gauche also has macros like (^x ...) which is short for (λ(x) ...) <mark_weaver>one could easily imagine adding a few macros like (^xy ...) meaning (λ(x y) ...), which would then allow (^xy (sqrt (+ (* x x) (* y y)))) <mark_weaver>davexunit: well, unfortunately the error you can into was "wrong argument type", because 'char-ready?' wanted an open port, but got only a port (closed). <davexunit>yeah, you're right. guess there's not much I can do there. <davexunit>I'm about to get to dealing with that now that I'm back from playing some riveting games of "go fish". :P <mark_weaver>davexunit: one other thing to test, when you get it basically working: try calling 'stop-server-and-clients!' while something is running in one of those REPLs.. e.g. something that loops printing to the output port every second or so. just to make sure that's handled nicely. <davexunit>and children that want to play games with us. :) <davexunit>mark_weaver: I do not, but my girlfriend has one. <mark_weaver>ah, nice! I also live with an almost 3-year-old, so I know what it's like :) <davexunit>I try to squeeze in hacking time whenever I can. :P <mark_weaver>it can be difficult with a 3-year-old in the house, I know that all too well! :) <cky>mark_weaver: Ah, makes sense (re Gauche's ^a, ..., ^z, ^_ macros). <cky>mark_weaver: Also, thanks for clarifying about serialising, not sure what Racket does there either. :-) <cky>mark_weaver: As for two-letter ^ variants, we can probably only do a small subset like ^xy and ^ab. Trying to do all letter combinations would be overkill. ;-) <dje42>Hmmm, with a recent git build (port-conversion-strategy #f) is complaining "expecting open port" <mark_weaver>dje42: indeed, that's a bug, given that the docs say it accepts #f. can you email bug-guile@gnu.org about it? <dje42>Sure. Still digging ... the code looks fine - weird. <mark_weaver>dje42: the "SCM_VALIDATE_OPPORT (1, port)" at ports.c:1301 is the problem. it validates the 'port' is an open port. <mark_weaver>that line should simply be removed. the one that's needed is already on line 1309. <mark_weaver>the bug was introduced in 19b8d12b165a11d963507e0ed35307f4e719e653 <mark_weaver>I'll just go ahead and fix it, I guess. is there a bug report to link to? if not, no biggie. <dje42>Naw, hadn't gotten that far yet. Thanks! <dje42>I did a "make check" of my guile extension language patch for gdb and tripped over it. <davexunit>mark_weaver: for catching exceptions I know of 'catch'. is there another procedure that I should consider using for this? <davexunit>and by this I mean the REPL socket exception. <mark_weaver>(not sure if it's appropriate here or not, off hand) 