IRC channel logs

2017-05-03.log

back to list of logs

***logicmoo is now known as dmiles
<nalaginrut>nikita1: fixed one, but the shrink issue still have no idea
<nikita1>nalaginrut: I'm still investigating it... I've generated a long sxml template (>1mb) and it was loaded completely. May be existence of db communications is important for reproducibility.
<nalaginrut>nikita1: is the db access necessary for reproducing?
<nikita1>nalaginrut: may be. I'm trying to get the smallest code which reproduces the bug
<nalaginrut>nikita1: I can reproduce it now
<nalaginrut>has to be reproduce it with a dynamically generated page
<nikita1>cool!
<nikita1>I was trying (tpl->response `(html (body ,@(map (lambda (r) `(p (format #f "This is a long para ~d" r))) (iota 20000)))))
<nikita1>but it doesn't reproduce the bug.
<nikita1>but, when i get data from database query result --> here it is.
<nikita1>nalaginrut: how did you managed to get it?
<nalaginrut>nikita1: just find a big html file, and (get "/test" (lambda (rc) (call-with-input-file "file.html" get-string-all)))
<nalaginrut>you need to import (rnrs)
<nalaginrut>it always shrink at the same position for me
<nikita1>yes, position is always the same
<nikita1>try it behind nginx -- it will work
<nikita1>which is very strange
<nalaginrut>nikita1: could you count the position? I wonder if it's the same number with me
<nikita1>for different files are different
<nalaginrut>hmm
<nikita1>6113 and 3751
<nalaginrut>and how about the rest bytes?
<nalaginrut>maybe they're same
<nikita1>no, different...
<nalaginrut>ok
<nalaginrut>the content-length is correct
<nalaginrut>nikita1: I found the problem, the content-length should be counted as bytevector rather than string
<nalaginrut>since it's utf-8 indefault
<nalaginrut>in default
<nalaginrut>and the rest bytes are the same with the difference, I've checked
<nikita1>great(!) I've just check my test generator with international symbols!
<nikita1>nginx doens't rely on you content-length ;)
<nalaginrut>yes, when it's redirected to nginx, it's recountered
<nalaginrut>nikita1: the interesting point is that I've found another 2 bugs could cause the similar problem by close connection improperly, but this one is the case. I think I got some reward from debug ;-P
<nikita1>nalaginrut: definitely!
<nalaginrut>amz3: when Artanis is ready, I'll write a blog engine with you git binding, I really need a new blog system. Is it ready now?
<nalaginrut>I have to use git as db backend for my old post
<wingo>nalaginrut: please attach a test case to your backtrace report
<nalaginrut>wingo: I have to try to make one, since it appears while I'm debugging Artanis, and it uses delimited-continuations
<wingo>i can't help you there, you need to reduce a test case from what you have
<wingo>as it is your bug doesn't have enough info
<wingo>needless to say, it's not my experience anyway
<nalaginrut>wingo: ok I'll try
<amz3>later tell nalaginrut we did not do a release yet, but issues are welcome
<amz3>sneek: later tell nalaginrut we did not do a release yet, but issues are welcome
<sneek>Will do.
<jackhill>What's the status of GnuTLS support for Guile. I'm on Debian Stretch, and notice that the guild-gnutls package is no longer available. This line in the Debian changelog concerns me: Drop guile-gnutls package, testsuite errors have stayed unfixed too long. Closes: #821457, #805863
<davexunit>jackhill: I believe that guile has gnutls support built-in now.
<jackhill>davexunit: oh cool, thanks!
<davexunit>I haven't used it though so I don't know how it works. this requires guile 2.2 I think.
<wingo>it's not quite built-in
<wingo>you still need a guile-gnutls package i think
<davexunit>oh darn
<davexunit>:( sorry for wrong info
<jackhill>no worries
<jackhill>but given the the Debian packager didn't think guile support in gnutls was maintained enough, were they correct?
<wingo>hard to say... i don't know how much they were interacting with upstream, it could have been arch-specific and the guile-gnutls people didn't use that arch, almost certainly a different os, etc etc
<wingo>so "maybe" in summary :)
<davexunit>I don't remember ludo ever mentioning that debian was going to remove guile-gnutls
<jackhill>hmm, okay. I'm just getting into guile, but I definitely want TLS support, so I'll poke around more. Thanks
<jackhill>It also seems to be gone from el7.
<davexunit>jackhill: you can install guix and use that for all of your guile stuff.
<davexunit>that will get you the most up-to-date guile and an easy way to install gnutls bindings
<wingo>we have it in guix and run its tests regularly on the few architectures guix supports (x86_64, i686, something army), but that's not debian-level arch diversity
<wingo>anyway we do rely on it there fwiw
<davexunit>debian probably doesn't have guile 2.2 and that is the recommended version to be using now.
<wingo>afaiu guile-gnutls works even with 1.8, no?
<jackhill>davexunit, wingo: okay, I'll probably do that. I guess I'll use the guix binary distribution instead of building from source since guix depends on guile-gnutls ☺ (at least for some features)
<wingo>jackhill: that is certainly the easiest way :)
<wingo>#guix can help with any installation problem or whatever
***ozzloy_ is now known as ozzloy
<amz3>again I have an issue with my mails I can't retrieve all my mails for some reason
<amz3>let's try webmail
<amz3>ACTION using the google mail to look up and find the mail...
<amz3>re tls issue, it works.
<amz3>Someone asked a question on another channel, a somewhat terrible question
<amz3>how to store forms results in a database and do some computation over it...
<amz3>the solution proposed the same person was to use a third party service to build the form (in html format) and gather the result in a csv file and import that csv file in google docs
<amz3>all this can be done in Guile \\o/ without third party services, I will try to explain it in a post
<amz3>I will make it a multi post because I am tired :p
<daviid>not having a separate package for guile-gnutls is a big problem for users who do not want the guile package from the distro... as a result, i can't have guile-gnutls, neither can i compile guix... unless I manually install gnutls, which is already the latest, even on debian stetch :):) i wonder what other guilers on debian do?
<daviid>configure: error: The Guile bindings of GnuTLS are missing; please install them.
<daviid>from where? the debian package depends on guile 2.0.13 , and i don't want guile from the distro anyway, I have it m anually installed ...
<daviid>actually there is no guile-gnutls anymore :), which is the problem, the only rapid solution is to install gnutls twice then I guess, from the source so it finds the manually installed guile ... then copy the bindings, remove gnutls and manually installed the copied binding files
<amz3>daviid: I used the binary installation of guix on top of Ubuntu
<amz3>fwiw
<amz3>wingo: the work you've done on guile-potluck is awesome
<daviid>amz3: i'm trying to compile guix master on debian, and anyway, i want guil-gnutls in /opt2
<amz3>wingo: can a potluck package depends on another potluck package?
<amz3>wingo: I did not understand how recipes ends up online at https://guix-potluck.org/
<civodul>daviid: https://packages.debian.org/search?keywords=guile-gnutls
<daviid>civodul: it is not in styretch anymore, and as i said, it would install guile 2.0.13, so i decided to clone gnutls and will cook from there :), thanks
<daviid>*stretch
<daviid>civodul: i know you made this choice for the best, but practically, it does not work well (for users manually installing guile)
<daviid>make bootstrat is cloning openssl?
<daviid>civodul: make bootstrap hangs for ever here, is this expected or is this the symptom of a problem here? it says Cloning into '/usr/local/src/gnutls/git/devel/openssl'... but it seems it has cloned fine then hangs, the touch time of devel/openssl is a few minutes ago ?
<daviid>ok, it finalize this step, let's configure...
<daviid>oh, make fails: verify.c:40:28: fatal error: supported_exts.h: No such file or directory #include "supported_exts.h"
<daviid>this gnutls master
<daviid>the gnutls stable branch fails as well: priority.c:885:30: fatal error: priority_options.h: No such file or directory
<daviid> #include <priority_options.h>
<daviid>
<daviid>and cd guile make fails as well ... this is a dead end problem, i think i'm going to package guile-gnutls separately :)
<daviid>have to leave, bbl
<civodul>daviid: https://packages.debian.org/search?keywords=guile-gnutls says it's in unstable no?
<civodul>at any rate, it's not a matter of packaging *the source* of guile-gnutls separately
<civodul>the problem is unrelated to that to me
<janneke>hey civodul, thanks for your changes to the mes package!
<civodul>hey janneke, yw!
<civodul>i found it pretty exciting to watch the build log already :-)
<civodul>gave me a feeling of how far this has gone
<janneke>very good to hear :-)