<daviid`>sneek: later tell mistnim actually, I recommend you to keep guix and remove the guile version you have on you debian, then try again ... be sure to purge guile, not just uninstall it: 'aptitude purge guile' <daviid`> sneek: later tell mistnim the guix approach is alot safer i the long run, and worth spend some time to make it work now ... also becuse the team is working on a new release, and that will hold the latest guile stable-2.2, which will boost your guile-cv experience by a couple of order of magnitudes <daviid`>wingo: it would really be cool if you could look at and update/integrate lloda patch so raised exceptions do not try to print very long (to huge) lists, arrays, and srfi srfi-4 bytevectors... <daviid`>wingo: and then to have a parameter, %use-truncated-print or something like that, so users can ask guile to use it, for both the repl and raised exacpetions, wether together or separately... if these too could be in the next release, that would be awesome! <daviid`>till this happen, guile-cv is literally unusable (refering to users, not myself, lloda and other advanced users and/or developers ...) <mwette>wingo: +1 to not printing long bytevectors <dustyweb>is there any way to define an object type that is not itself a procedure, but which can be called as a procedure? <dustyweb>either in GOOPS or srfi-9 or really anything <dustyweb>I thought there was but now I can't recall it <dustyweb>something like python's __call__ special method <davexunit>the manual has something to say about it somewhere <dustyweb>davexunit: there's kind of the inverse I know of, with procedure properties <dustyweb>where a procedure can have properties... and I guess I could construct it from there, but I'd rather do the reverse <dustyweb>have a structure which itself can be a procedure <dustyweb>ok there's an applicable objects thing in here... <dustyweb>seems like that's on the right track though <davexunit>looks like there just isn't a nice high-level interface fo rit <dustyweb>I'm glad GOOPS could give me something to work with <str1ngs>ftknox: http-get should be a goods starting point. is that link still broken for you? <ftknox>str1ngs: So I can make non TLS/SSL requests just fine, but the API I want to interact with is only available over an HTTPS connection <str1ngs>it should inherently use gnu tls if https is requested. If I'm reading this right <ftknox>hmm. Let me try again, maybe I'm just doing something dumb <str1ngs>I think guile-tls is only needed if guile is not built with tls support. I could be reading that wrong though <str1ngs>hmmm or maybe not, I guess it might use ffi <str1ngs>ftknox: does your distro or OS provide a gnutls-guile package? <ftknox>str1ngs: I'm using Debian Jessie. I'll check the repos <str1ngs>debian generally has good guile package support IIRC <ftknox>str1ngs: Yeah, there is a guile-gnutls package that I have already installed <ftknox>str1ngs: no, I get a 400 response from the server of "You're speaking plain HTTP to an SSL-enabled server port.<br />\\n Instead use the HTTPS scheme to access this URL, please." <str1ngs>it should try to use guile tls if you pass https scheme <ftknox>str1ngs: okay, I'll do some more digging. Maybe I've got something misconfigured somewhere <str1ngs>I'm getting similar results as you with guile 2.0 <str1ngs>my distro does not provide 2.2 guile tls package. so hard to test for 2.2 <str1ngs>that could be why. IIRC the docs you linked would be for 2.2 <ftknox>oh geez. Okay, I'll work on getting a newer guile on my machine <ftknox>thanks for all your help strings! <str1ngs>but guile 2.2 might have tls support built in <ftknox>str1ngs: yes. I can see that link, and I get meaningful output from running (gnutls-version) <str1ngs>does not have the same documentation <str1ngs>I suspect, you'll want to use guile 2.2 for https scheme support <ftknox>str1ngs: correct. Thanks for that! Happy hacking! <ftknox>now I really need my kids to go to bed so I can monkey with this :) <str1ngs>I'm not 100% sure though. I may need to build guile tls manually to test this. <ftknox>str1ngs: let me try out guile 2.2 and see if that works, and I'll let you know what I find <str1ngs>where are the source package for gnutls-guile <str1ngs>I think gnutls guile is configured through gnutls <str1ngs>hmmpf gnutls seems to only look for guile-snarf and guile-config. does not find guile-snarf2.2 <wingo>ACTION going to try to make a guile release today <wingo>did you get a chance to see if the recent changes to guile improved guix pull time? <wingo>i measure a 100% speedup at -O1 for that generated test file <civodul>BTW note that python.scm has been shrunk significantly recently <wingo>that's probably a good thing regardless. i am testing tho on that generated allocate-struct / struct-set! case you had tho <wingo>civodul: i am thinking of punting on the gnulib update, wdyt <civodul>yeah it's safer to leave it for later i guess <civodul>and we haven't seen any issue with the current snapshot <civodul>on my emit-bytecode bench (which compiles the big CPS), i get 22s instead of 54s <wingo>is that with -O1 or default options? <civodul>that's with %lightweight-optimizations as in (guix build compile), which corresponds to -O1 AIUI <civodul>which doesn't matter anyway because i'm just looking at emit-bytecode :-) <wingo>hmm, that means you miss out on the cps conversion improvments, no? <wingo>or does your test do cps conversion inside the benchmark <civodul>probably, so i guess i'm only seeing the slot allocation improvements? <wingo>jsut wondering if you were reading in cps from disk, something you transformed before <wingo>if the cps is newly transformed then you are also seeing the benefits there; there should be fewer conts, fewer terms, etc <wingo>that's the real benefit of the cps conversion improvements: the result is a smaller term than before. <civodul>so yeah, this is not a representative bench <wingo>you are reading in some pre-transformed cps from disk? <wingo>curious to see improvements with a newly transformed file :) <civodul>i'm trying "guild compile -O1 python.scm" <wingo>now that python.scm is not as long as it was, it's a less good benchmark, but yeah <wingo>anyway closer to the result we want :) <wingo>note that i just pushed one more incremental improvement an hour ago or so <wingo>should shave off another 5-10% depending on the file <civodul>that goes from 43s to 17s, which is nice :-) <wingo>it is a good improvement, even if not yet nice :) <civodul>i pulled minutes ago so i should have the latest and greatest <wingo>well, maybe this will stave off angry guix users for a while <wingo>any idea about memory for the python.scm compilation? i guess those numbers are harder to get <civodul>yes, that's what i was trying to get <civodul>maxresident reported by time(1) goes from 700M to 326M, and that seems to match what i see in 'top' <civodul>(again "guild compile -O1 python.scm") <civodul>presumably that's largely because the CPS graph has fewer nodes, right? <wingo>also because of not computing SCCs in slot allocation for the big wrapper function <wingo>but mostly because of reduced graph size <civodul>that's the "Avoid generating arity-adapting continuations if not needed" commit, right? <wingo>civodul: that one and the following one, yes <wingo>distcheck is a lot less painful given prebuilt :P <wingo>guile-2.2.3/build-aux/ltmain.sh:#!/gnu/store/58nhnjff2yahyxa1yjh2m8k93fb955z5-bash-4.4.12/bin/sh <wingo>error: store file names embedded in the distribution <wingo>how is still a thing in guix??? <wingo>============================================= <wingo>guile-2.2.3 archives ready for distribution: <wingo>============================================= <wingo>what i don't know is if savannah has my new gpg key <stis>hey wingo: I found a compiler bug I think for 2.2. How do I report it? <wingo>stis: mail to bug-guile@gnu.org <stis>done, a bug that might interest you as it is for 2.2 and is a seams to be a compiler bug if not already fixed <wingo>civodul: just updated my gpg key on savannah, am trying to upload again <wingo>otherwise the web site is updated, i just need to send a mail to the list once the files are there <civodul>wingo: the FTP upload procedure is disconnected from Savannah <civodul>info "(maintain) Automated Upload Registration" <wingo>i thought the gpg keys on savannah were used to verify the uploads? <civodul>"Should you later have to update your GPG key, you'll have to re-submit it to both Savannah and <ftp-upload@gnu.org>, as these systems are not connected." <civodul>hopefully that'll be quick as it's daytime now in Boston ***ftknox_ is now known as ftknox
<wingo>i can put the tarball somewhere if you need to get guix builds going <wingo>i could of course upload using a signature from the revoked key but that would not be good :) <civodul>we can at least upgrade in core-updates <civodul>well we can at least provide the new version in addition to 2.2.2, and update entirely later <wingo>i am in the process of uploading .gz and .lz files to that same place, but i guess guix will just take the .xz <civodul>phase `build' succeeded after 3640.8 seconds <civodul>that's ~1 hours, whereas it used to be ~3 hours on the same laptop i think <civodul>at least according to a comment i left in (gnu packages guile) :-) <wingo>civodul: that sounds promising :) <wingo>oh good the sysadmins are taking care of the key issue <jamesrichardson>Hello, I would like to use sqlite from guile. I see there is a guile-sqlite3 and a guile-dbd-sqlite. Is one or the other considered more stable/feature complete? <civodul>jamesrichardson: i'd suggest guile-sqlite3, which has received more attention i think ***u_l-lap is now known as unknown_lamer
<civodul>there are two uses of %fresh-auto-compile in Guix, and both were lucky that fresh-auto-compilation didn't happen <bavier>how about that patch to update guile's "download" page? <ftknox>str1ngs: So I moved to Debian Sid and guile 2.2, then rebuilt gnutls and now I get a new error from the POC that I shared last night <ftknox>str1ngs: nevermind, I had a dumb typo. tl;dr: moving to guile 2.2 fixed my TLS issue!! <str1ngs>ftknox: that's good to know. I had an issue manually building gnutls with guile 2.2 <str1ngs>autotool find /bin/guile which is 2.0 it won't find guile-snarf2.2 for w/e reason. <ftknox>now I just need to figure out how to add an Authorization header to my request and I'll be all set <str1ngs>I'll need to revisit this guile-snarf issue at some point. Since I have a personal project that has similar issues discovering what guile-snarf to use.