<dustyweb>guess I can answer my own question by testing it :P <dustyweb>set-port-encoding! doesn't seem to have a significant cost. <daviid>ot: just noticed using tor browser that github is actually tracking any visitor in a much worse way then I initially thought! I hope the all world will cancel their github acoount <daviid>it's trying to identify your computer based on html5 canvas and mouse movements <daviid>dustyweb: just try ... you'll see the tor browser alert by yourself <dustyweb>ACTION wishes tor browser bundle was packaged for guix :< <daviid>i wish epiphany would offer similar protection, i really like epiphany, but more nd more I'm thinking to ony use tor <daviid>except for local pages (like verifying guile-cv html doc ...) I've noticed almost all sites I access looking at HN are tracking my computer ... this world is disaster <daviid>davexunit: I know you are the author of sxml->html, but do we have an html->sxxx tool? (if that is possible, no very knowledgeable in that area)? <mwette>daviid: html->sxml, in htmlprag.scm, is in guile-lib on savannah <ryanwatkins>How might one pass a TLS-encrypted I/O port to http-get? <ecraven>is there a way to introspect which bindings an environment has? like (module-bindings (interaction-environment))? <ecraven>module-for-each seems good for this ;) <amz3>ArneBab: I tried closure-compiler-js (the javascript version) and it failed, I will try later with the native java version <amz3>the javascript version is compiled java->javascript <FalconPilot>using (ice-9 match), how can I match a number that's bound to an identifier? <FalconPilot>I'd like to do something like (match ch ((KEY_LEFT ... <amz3>FalconPilot: remove the extra paren ( in the match rule you pasted and it should work as expected <amz3>the rule you pasted is trying to match (list KEY_LEFT) <FalconPilot>it seems to match anything with the first pattern, binding any input to foo <FalconPilot>from the guile manual on Pattern Matching, this seems to be correct: <ArneBab>amz3: closure-compiler reduced the size of main.js to 3.6 MiB for me. <FalconPilot>I suppose I can clean that up a bit with: (define (id x) (lambda (a) (eq? a x))) <ArneBab>amz3: the tco function did not suffice to avoid hitting the recursion limits. I fear I may have used it the wrong way. <ArneBab>amz3: at least I now have a 18 MiB main.js with proper indentation <amz3>ArneBab: cool, I will try it later <amz3>ArneBab: that said, closure-compiler is for production build, right now the next issue I need to tackle is the jslink step which takes too much time <amz3>ArneBab: what are you interested in doing using guile-js? <ArneBab>amz3: I’d like to see whether I can get text-rpgs to work in the browser <ArneBab>and then combine wisp with js, because that would give me wisp for the browser. <amz3>ArneBab: btw, I did not chime in wisp conversation, but my point of view is that guile maintainer should only accept modules they are confortable with maintaining, so it's their decision and I can not weight in this conversation <amz3>ArneBab: that said, I think maintainer should make it easy to use wisp <amz3>stis proposal about making it easy to specify compilation source, is in the step in the right direction i think <amz3>IIRC, wisp does not require the compilation tower to kick in, does it? <djcb>scheme@(guile-user)> (assoc "foo" '(("foo" . "bar"))) <djcb>scheme@(guile-user)> (assoc-ref "foo" '(("foo" . "bar"))) <djcb>hmmm.... am I misunderstanding `assoc-ref'? <ArneBab>amz3: wisp just hands compilation over to scheme, but what’s missing is a way to specify "(import (from-language (package module) wisp)" <amz3>djcb: assoc-ref takes the assoc as first argument <ArneBab>amz3: this is to make it easy to just install stuff with wisp. <ArneBab>amz3: I already have workarounds to make wisp easy, but every workaround is a hurdle <amz3>ArneBab: and other languages? <ArneBab>amz3: yes, other languages, too: I use shell indirection <ArneBab>but I cannot as of now tell it *easily* to search by extension <ArneBab>(though I’ll try to document how to do it) <ArneBab>once I pre-compile all files, everything works <ArneBab>amz3: the next step is the guix-recipe for using wisp in a program (I’ll try to get that going) <djcb>amz3: oh, of course! thanks! <ArneBab>amz3: having to pre-compile the files means that I have to either add a build system or a pre-compilation step in the shell indirection header. Both duplicates the information in the file itself (the import statement), that’s why I’d like to have something more powerful. <amz3`>ArneBab: you'd rather add a build system, that's what do JavaScript people, it works well ;) <amz3`>pilling up build system is the way to go :sarcasm: <dsmith-work>amz3`: Used to be everyone wrote their own editor. Now it's a "builder". <ArneBab>amz3: it’s not like I dislike build systems. It’s just that I know how much easier it can be to start if you can simply call ./duel.w <ArneBab>amz3: building js from guile (and wisp) would be awesome, because it would give the things I create the lowest possible barrier of entry: I could just put them on websites and give people links. But they could still install it locally to get the real usability (like easy shell scripting) <benq>hi arnebab: I saw you by accident, there is something I'd like to tell a long time ago: I was never able to build wisp without errors. If i recall correctly some of the path where not compatible. And then another problem with an m4 macro @GUILE@ which was not recognized. yay something less to think about :-) <ArneBab>benq: that sounds like it’s missing autotools stuff :( — did you run ./configure ; make from a distribution tarball? <benq>arnebab: yes I've tried multiple machines, multilple wisp versions, multiple autotools versions (update). I did the autoreconfigure stuff <ArneBab>could you send me a build log by email? <ArneBab>this is something I should get fixed <benq>its some time ago but I'll have a look <ArneBab>benq: maybe I’m missing some m4 stuff which does not show up in Gentoo because Gentoo includes all the -dev stuff be default <daviid>ArneBab: these errors are a symptom of a bad ACLOCAL (and friends) config on the user computer, or that guile is not installed (unlikely). I recommend you to add an m4 dir, copy the guile.m4 file there and update yur configure.ac so it' uses this m4 directory ... my 2c (it is the most recurrent I hear from users unable to install (extra) guile projects/packages <benq>fighting with some stuff .. meanwhile why WHY even use autotools at all? <ArneBab>benq: because autotools has make distcheck. <ArneBab>benq: and I had the experience that everything else became worse <benq>premature optimization :-) <daviid>benq: autotools is the best ... but this is OT anyway <ArneBab>everything else includes waf, scons and cmake <benq>or your own perl script that checks some boring stuff that 99% of all users use <ArneBab>except that I tend to belong to the 1% which gets bitten :) <benq>what I want to say: I use a lot of software and wisp is one of the most difficult to build. <daviid>ArneBab: the above suggestion will also cover the situation where guile has not been installed yet (it happens, more then you think ...) <ArneBab>benq: wisp actually bootstraps itself completely when you build it <benq>but I think generations of developer have argued over this <ArneBab>but it shouldn’t be complicated (it should just be ./configure ; make <benq>but I agree with something: autotools is the worst build system except everything else <ArneBab>daviid: how to I add the m4/ dir cleanly? <daviid>ArneBab: you do that on your tree, once for all ... <benq>ok, I try to build from source and I think I can reproduce it, ./configure: line 1886: syntax error near unexpected token `2.2' / ./configure: line 1886: `GUILE_PKG(2.2 2.0 1.8)' <ArneBab>benq: and autotools has some of the worst documentation — often complete, but lacking best practices like actually telling me what I really need to do so everything works) <ArneBab>benq: that looks like GUILE_PKG does not know about Guile 2.2 <benq>which guile: /usr/local/bin/guile <benq>guile --version: guile (GNU Guile) 2.2.2 <benq>just fyi: I once did mess with that too. You would be ashamed if you'd know how much time I've wasted with wisp ;-( <ArneBab>benq: I’ll try to make up for it by getting this fixed <benq>on the other side, it aligns with the shitty day I had. Messing with auto tools describes absolutely my mess in real live. <daviid>benq: this you are facing has nothing to do with the autotool chain, which is by far the best tool for us, developers ... don't blame the autotool chain, it would be unfair <benq>m4 the best? I'm not sure. <ArneBab>in fairness: it is easy to get caught in autotools. Most of the time I lost wasn’t due to implementation in autotools, though, but due to documentation issues. <dsmith-work>m4 is what it is, a macro processor. Kind of like a stream editor, but different. <daviid>benq: not just 'm4', the autotool chain ... and please note that your are blaming a tool that has nothing to do with the problem you report, hence your are being unfair ... and try to disqualify a fantastic tool based on your wrong assumptions ... but hey, let ArneBab solve this for you, just be a little patient, and thanks for reporting this here ... <ArneBab>benq: yes, thank you for reporting! I would otherwise have been oblivious of lots of potential users who didn’t get it to build ***dsmith-work is now known as dsmith-old-codge
***dsmith-old-codge is now known as dsmith-oldcodger
***dsmith-oldcodger is now known as dsmith-work
<pebftab>sorry to interrupt, not trying to piss anybody off ... but has anyone heard about the 'ERROR: In procedure load-thunk-from-memory: incorrectly aligned base' thing ? I can't seem to find anything about it <benq>At least I know now that guile probably never will get rid of autotools. And guile is besides wisp one of the most fragile software to install. <daviid>pebftab: this is a (possible) symptom you have more then one guile installed, and wrong PATH, GUILE_LOAD_PATH, LD_LIBRARY_PATH ... <daviid>benq: guile installation is very robust, wisp is not guile, wisp is an external module ... <ArneBab>benq: where are you trying to install Guile? <ArneBab>benq: you could actually get most of wisp by simply copying three files: language/wisp/spec.scm wisp.scm and wisp-scheme.scm <benq>no, I work on different machines and different OS. Guile installation is a constant source of pain, that's why I switch to other schemes (gauche) which are far more reliable to build. <benq>I don't want to offend anyone. But I spend far to much time with finicky adjustments. I think I'm allowed to express my experiences. <pebftab>daviid: %load-path and %load-compiled-path seem to be fine ... although something definitely seems to be wrong with my installation, i had to manually create the directory /usr/share/guile/site/2.2 , because the REPL was complaining about a missing directory in a similar error ... <dsmith-work>benq: Really? Unreliable? Iv'e not seen that. For releases. Takes a LONG time to build, but that's not a reliability thing. <ArneBab>benq: I’ve been bitten myself by not having the right GUILE_LOAD_PATH and such <ArneBab>when installing Guile from git in ~/.local <dsmith-work>pebftab: As usual in these cases, some usage of strace might reveal something. <benq>I think the way GIT uses autotools makes sense. It is very focused on the important stuff, not just throwing bloat on the source code base. <ArneBab>I never had to fiddle with installing git myself — my distro takes care of that. <daviid>pebftab: I recommend you to uninstall (like 'apt-get purge ...' if you're on debian, or what ever purge if other dostro), untill there is no guile installed, then install the latest arch package (iirc you're on arch), the try a repl again ... (and you should _not_ create dir in /usr manually ... ) <benq>just to report this: I had some errors with the extract: tar: copyfile unpack (wisp-0.9.3/examples/-examples-doctests--doctests-extract-from-string--mytest.log) failed: No such file or directory <ArneBab>that’s strange. the file should be wisp-0.9.3/examples/._-examples-doctests--doctests-extract-from-string--mytest.log <ArneBab>(mind the ._: ._-examples instead of -examples) <ArneBab>… and I just saw that it packed up the ._site/ dir which does not belong there … <benq>No Guile development packages were found <benq>I have a sense that this could have something to do with pkg-config. I think that was it in the past.. <benq>FIY: I'm working on macOS sierra. I could try it also on (l)ubuntu <ArneBab>ah, macOS … is it possible that you’re not using GNU make but some other make? <mwette>When I `tar xf wisp-0.9.2.tar.gz' I get lots of errors. I think my tar does not like files that begin with `-'. What is that all about anyway? <benq>what do you suggest: messing with $PKG_CONFIG_PATH <ArneBab>mwette: these are hidden log files which don’t actually need to be included <benq>my shell is fish and bash <ArneBab>then the OSX tar has problems with the format <mwette>benq: are you using MacPorts or Fink? <stis_>yeeha, the list functionality is in place, python lists are now growable vectors and tuples are guile cons lists <ArneBab>benq: you *could* try something along these lines: ./configure PKG_CONFIG_PATH=$HOME/.local/lib/pkgconfig/ && make PKG_CONFIG_PATH=$HOME/.local/lib/pkgconfig/ <ArneBab>that’s what I’m doing to test against the locally installed wisp <benq>what do you have in pkgconfig? <ArneBab>benq: do you also get these problems under *buntu? If not then the pain you’re feeling might be from departures MacOSX took <benq>I'm not 100% sure but I think yes <benq>ah sorry, I want to say I have that in /usr/local/lib/pkgconfig/guile-2.2.pc <benq>It seems like ./configure PKG_CONFIG_PATH=/usr/local/lib/pkgconfig make the error go away <mwette>ArneBab: wisp `make check' is failing on macOS due to no `realpath' <ArneBab>mwette: do you know what the shell on OSX has instead of realpath? <benq>arnebab: do you modify your config or do you mention it in the README <ArneBab>I already mention the PKG_CONFIG_PATH in the readme <benq>'make check' went fine. I would suggest to put a realpath script somewhere under /scripts <mwette>MacPorts has realpath -- just installed <benq>my Guile is not installed in my home, and I think my guile.pc was at a pretty standard location. <mwette>and `make check' works now -- I need to make a Portfile to get it in <mwette>Why do you install wisp in share/guile/2.2/language instead of share/guile/site/2.2/language? I suggest the latter. <ArneBab>I’m not sure whether I had problems with site/ or just didn’t know better at the time I wrote it