*KREYREN read the Regular Expression page in guile manual and is confused <flatwhatson>KREYREN: better to use a proper URI library than do ad-hoc regex parsing <flatwhatson>guile provides the (web uri) module with functions like string->uri and build-uri that would be useful in your example <KREYREN>flatwhatson: where do i get the source code of `web` to check? *KREYREN is a noob in guile <KREYREN>ehh.. i have no idea how to figure out what to use from web uri and what is the usage of it <KREYREN>the `string->uri` in manual just says that it parses string into a URI object and i have no idea what URI object is <flatwhatson>it is a thing which you can call eg. (uri-host my-uri) on, to get the host part as a string <flatwhatson>reading that whole manual page will probably give you a better indication <KREYREN>I can't use GNU Guile code on like Chez Scheme right? So akku should be more portable and flexible then GNU Guile while running on GNU Guile as well? <flatwhatson>writing non-trivial scheme code that runs properly on multiple implimentations is not really easy <KREYREN>The code on akku seems to be non-complicated though <flatwhatson>better to just pick an implementation which you like, focus on building something that works, and come back to making it portable later if you really need to <KREYREN>And like lisp 2.0 is heavily invested in making code that is implementation independent.. so seems sane to try to pursue this in scheme too? <flatwhatson>the idea of portability is a good one, but in practice the portability situation in scheme today is poor <KREYREN>So whenever i can make my scheme code to work on akku then i should? <flatwhatson>you've already mentioned being new to guile, presumably new to scheme. trying to write portable scheme will be more difficult than just targeting guile and not worrying about portability <flatwhatson>you're less likely to get support in here for akku libraries than stuff that ships with guile <KREYREN>new to scheme, but not new to common lisp and elisp so trying to figure out the best practices O.o <KREYREN>since my common-lisp brain is always screaming at me MAKE IT PORTABLE <flatwhatson>but then in practice you only run it on sbcl, right? <KREYREN>nope i test my common-lisp against as many implementations as possible <KREYREN>there is like whole coding style and management to make sure it remains implementation independent <flatwhatson>ok, sure. that is what i'm getting at with saying it's more effort. the portability situation in scheme is worse than common lisp <KREYREN>and library very similar to how akku works <KREYREN>if i can do more effort then using akku will make for more portable and thus functional code right? <flatwhatson>with all respect, i'm not here to argue, i've answered your question already <flatwhatson>guile has r6rs and r7rs modes, but most people don't use them. if you write an interesting library that works on guile, you can very likely "port" it to some portable standard code later <flatwhatson>if you try to do that up-front, while learning scheme, you're making your life difficult for little benefit <KREYREN><flatwhatson> "if you try to do that up-front..." <- like akku seems to be just replacing `(use-modules` with more functional management and then adapting coding style <KREYREN>... and seems to have significantly more libraries then guile ***NullPointerErro1 is now known as NullPointerError
***NullPointerErro1 is now known as NullPointerError
<sneek>I've been running for one month and 15 days <sneek>This system has been up 6 weeks, 3 days, 9 hours, 15 minutes <jpoiret>has anyone adapted a polling repl server to guile fibers? would that be doable without diving too much into guile internals? ***NullPointerErro1 is now known as NullPointerError
<alextee[m]>trying to build latest guile release with --disable-shared --enable-static and I get this: <alextee[m]>. /tmp/ccMevSFF.ltrans6.ltrans.o: In function `scm_tmpnam': <alextee[m]><artificial>:(.text+0x44ec): warning: the use of `tmpnam' is dangerous, better use `mkstemp' <alextee[m]>/tmp/ccMevSFF.ltrans0.ltrans.o:(.data.rel.local+0x3e0): undefined reference to `.L1' <alextee[m]>looks like this VM can't handle lto, works after disabling lto <alextee[m]>is there a way to speed up compilation of the bootstrapping phase? <alextee[m]>not sure why it doesn't do the bootstrapping in parallel, it produces .go files one by one even though i'm running with `make -j8` <mwette>alextee[m]: you could add --disable-tmpnam <mwette>that error message about tmpnam is issued by the linker