IRC channel logs


back to list of logs

<dsmith>Well, the good news is, sneek seems to be less leaky than he was, and so I've changed his kill-restart cron job to every 4 hours instead of every hour.
<dsmith>Still leaks though.
<dsmith>Down to about 12-40K per IRC line instead of about 700K per line.
<ijp>I don't know bobot, but this sounds nuts
<dsmith>Did NOT leak with guile 1.8
<ijp>so this is a libgc interaction problem
<dsmith>Sound like it.
<mark_weaver>well, not necessarily.
<dsmith>THere were some changes I needed to make that helped when I first started using 2.0
<mark_weaver>the way that code is compiled or interpreted has a lot to do with how long data is held.
<mark_weaver>that doesn't mean it's a guile bug.
<mark_weaver>there's also the fact that libgc is scanning a lot more thoroughly for pointers.
<mark_weaver>something is probably keeping a pointer that it shouldn't keep, but the old Guile GC didn't see that pointer.
*dsmith points the Finger of Accusation at... Botbo++
<mark_weaver>What functionality does bobot give you?
<mark_weaver>(that you're using)
<mark_weaver>it seems like it should be pretty easy to make an irc bot in pure scheme.
<ijp>indeed, I think at least 5 people on here are doing it :/
<dsmith>Yes, I started one a while back. sneek2
<dsmith>I think the main thing that's nice about bobot++ is message throttling.
<dsmith>So you don't get kicked
*tupi```` feels stupid because he doesn't know anything about irc bot
<dsmith>MOST of it doesn't apply. It's mainly a channel bot for giving ops and stuff like that.
<mark_weaver>though that doesn't sound too hard to rewrite.
*mark_weaver really wants a bot here with a modern guile repl.
<dsmith>Yes. But that's too scary for me. Need some really nice sandboxing.
<dsmith>sneek does have an eval interface, but it's disabled.
<ijp>that's the really nice thing about rudybot
*tupi```` thinks the all world should be written in guile with nice repl(s)
<mark_weaver>rudybot bot is also fairly clever at making banter.
<ijp>that said, I did make it crash once
<ijp>mark_weaver: the algorithm is stupidly simple, but work surprisingly nicely
<ijp>kind of like eliza
<ijp>not as clever as eliza though
<dsmith>If only I didn't have Real Work to do. So many fun things to play with.
<tupi````>yes, if only ... I could write so much more interesting thing in guile [and gule-clutter]
<mark_weaver>the codejam contest analyses are posted.
<dsmith>Any Debian devs in here? I know rlb and rotty.
<mark_weaver>they don't say anything about the pattern I noticed in the large fair-and-square numbers. well, it seemed to work well enough for the contest anyway :)
<tupi````>dsmith: like a debian official maintainer ? i'm not, but i work on debian, if i can be of any help...
<dsmith>tupi````, Just wondering if I can appeal to anyone to push newer guile a little harder.
<dsmith>nmu uploads or whatever
<tupi````>that wold be nice indeed, but i don't know
<ijp>mark_weaver: by google, or 3rd party?
<tupi````>i'm using git for the all guile* [and still will have problems to get the latest, didn't get it yet, because of libgc-dev does not even exists in experimental as 7.2x
<mark_weaver>ijp: by google
<ijp>wow, someone actually managed to use 9 different langauges
<ijp>mark_weaver: ty
<dsmith>tupi````, Yes, need to get 7.2d going too.
<tupi````>dsmith: that is probably 'our' major debian prob for now, then comes clutter, important to me, stuck in 1.10 for some reason that i am not aware of...
<mark_weaver>tupi````: fwiw, I just downloaded the upstream source for gc-7.2d, did a standard "./configure && make && make check && sudo make install" (to /usr/local) and it has been working perfectly on all my debian machines.
<mark_weaver>sneek: libgc?
<sneek>Someone once said libgc is
<ijp>bah, silly tabs
<tupi````>mark_weaver: tx, yes i did imagine that you had done that, but i am thinking to our users
<mark_weaver>ijp: how did you find this out?
<mark_weaver>tupi````: *nod* I agree it is a problem.
<tupi````>i can do that too of course
<mark_weaver>tupi````: we need to get some of these things into backports.
<ijp>mark_weaver: go hero has 2013 now
<mark_weaver>oh, it's up! I thought I checked just a few minutes ago and it wasn't yet.
<ijp>maybe some stale cache somewhere
<tupi````>right now, it is almost impossible to ask people to install kisĂȘ by themsleves [it did happen recently, the user lost interest] it would be nice to get some more work done on these major distro, i think
<tupi````>get guildhall to handle any dependency, that will be my dream :)
<dsmith>And then there is the issue of apps that currently depend on 1.8 and need help porting to 2.0
<tupi````>i mean guild
<tupi````>dsmith: yes
<dsmith>I think having 2.0 available in more distros (especially Debian) would help with that.
<tupi````>i think that it would make a difference yes, debian is important
<mark_weaver>there's a chicken-and-egg problem here.
<mark_weaver>distros aren't motivated to make guile 2.0 packages when much of the big-name guile-using-software doesn't even work with 2.0.
<mark_weaver>and the big name guile-using-software is not particularly motivated to work on upgrading when 2.0 isn't available on many important distros.
<tupi````>mark_weaver: i agree, let's hope that dak comes with lily in guile 2.0 soon [2.18 I think]
<mark_weaver>though really, the projects like lilypond and texmacs and gnucash probably need some help upgrading.
<mark_weaver>well, they definitely do.
<mark_weaver>although I know that texmacs and gnucash are fairly unhappy with us at this point, and are looking to switch to another language.
*tupi```` wish he could help, that is too bad
<dsmith>The only thing that helps is that guile2 is parrallel installable, so there can be a transition where some apps use 1.8 while other move to 2.0.
<mark_weaver>well, it's okay. there's also lots of new activity and excitement around 2.0.
<dsmith>IF there is a decent 2.0 available.
<mark_weaver>the upgrade from 1.8 to 2.0 will be the most painful. 2.2 should be a lot easier.
*dsmith looks at xapt and pbuilder
<ijp>at least aislerot upgraded :P
<mark_weaver>well, guile 2.0.7 is in fedora rawhide anyway, and so should be in fedora 19. that's progress.
<dsmith>Yeah, that's cool
***adu_ is now known as adu
*nalaginrut is reading mark_weaver
*nalaginrut is reading mark_weaver 's C3
<mark_weaver>It seems to work, at least up to 10^100, but I can't explain why.
<mark_weaver>and google's analysis of the problem doesn't shed any light on whether my method worked.
<mark_weaver>s/worked/is valid/
<nalaginrut>mark_weaver: well~but I thought Guile has no chance to solve it
<mark_weaver>nah, it's plenty fast enough for this.
<nalaginrut>I'm glad you prove it
<mark_weaver>if you don't have a good enough algorithm, then C won't be fast enough either.
<mark_weaver>if you have a good algorithm, then Guile is fast enough.
<mark_weaver>that's generally the case with these problems.
<mark_weaver>nalaginrut: I didn't prove it. I don't know why it works.
<mark_weaver>maybe it doesn't work. maybe it would miss something in the numbers greater than 10^100 for all I know.
<ijp>well, run guile a bit longer and check :P
<mark_weaver>how do I check, if I don't have a fast enough algorithm to generate the full list of fair-and-square numbers?
<ijp>well, it was a joke about checking an infinite number of cases. but on reflection, we haven't proved that is the case either
<mark_weaver>there are definitely an infinite number of them. the square of every number of the form 10000000....000000001 is also a palindrome.
<ijp>hmm, good point
<ijp>I'm not surprised you can prove it, I just realised I hadn't even considered it, "because it was obvious"
<ijp>but obvious gets you in trouble
<ijp>I was reminded earlier that we still have no proof of whether or not there are infinitely many perfect numbers.
<nalaginrut>hmm...debian has a new leader
<tupi````>nalaginrut: is that good news ?
<mark_weaver>well, for the last three years we've had probably the best debian project leader that we've ever had.
<mark_weaver>he finally stopped running for the position.
<mark_weaver>I don't know much about the new guy.
<nalaginrut>tupi````: I don't know
<mark_weaver>anyone feel like a logic puzzle?
<ijp>hmm, I may have it, but I'd need to do the working
<mark_weaver>don't give the answer or hints on channel please
<nalaginrut>mark_weaver: so it's a programming problem?
<mark_weaver>just a logic problem
<nalaginrut>how I wish savannah rewritten with Guile ;-P
<mark_weaver>yeah, that would be nice
<nalaginrut>but the web-framework is not so complete
<nalaginrut>maybe next year
<nalaginrut>the first step, maybe write guildhall with Guile
<ijp>no, I don't think I have it
<nalaginrut>ijp: I mean
<ijp>I was talking about mark's puzzle
<nalaginrut>sneek: log
<nalaginrut>hmm...where's irc log?
<nalaginrut>sneek: log is
<sneek>I'll keep that in mind.
<dsmith>sneek, logs?
<sneek>Someone once said logs is
<dsmith>I think it was already there, with the S
<dsmith>That's the mark_weaver summoning device
<dsmith>IT seems to work for wingo !
<nalaginrut>ijp: could you remind me that the four ways of optimization? compile/cache...and?
<nalaginrut>dsmith: thanks
<dsmith>Do I win?
<nalaginrut>I checked the log to find it, but you win
*dsmith collects his winnings offline, then heads off to bed
<ijp> (number 21)
<ijp>but dsmith got it right
<cky>ijp: Speaking of Eliza, Stack Overflow had an April Fool's this year starring Adviza:
<ijp>ah, that was an april fool
<ijp>I never clicked on the link
<mark_weaver>ah, I remember seeing that box pop up. I said "no thanks, go away" :)
<mark_weaver>now I wish I'd clicked.
<ijp>I just assumed they had reinvented irc
<mark_weaver>good morning wingo! you are an early riser.
<wingo>moin :)
<wingo>trying to be an early riser, with mixed success ;)
<mark_weaver>wingo: the sxml.simple.test failures in master were solved very simply: just import SRFI-6 from sxml/simple.scm, so that we get string ports that actually work properly.
<wingo>mark_weaver: i disagree with that solution fwiw
<wingo>that code was correct when oleg wrote it
<mark_weaver>I haven't pushed it yet.
<mark_weaver>we should just fix string ports in master, right?
<wingo>yes, i think so
<mark_weaver>me too, absolutely.
<mark_weaver>we have to convince civodul.
<mark_weaver>well, actually...
<mark_weaver>importing srfi-6 is the right thing to do anyway.
<wingo>i think we've worn him down by now ;)
<mark_weaver>in portable code, you can't count on those bindings even existing without importing srfi-6
<mark_weaver>but I agree with you nonetheless.
<wingo>and i apologize for saying i would handle that and not doing it :/
<mark_weaver>no worries. you didn't say when :)
<wingo>i just didn't want to paper over the problem
<wingo>hehe ;)
<mark_weaver>that's a good policy.
<mark_weaver>well, I want to add the srfi-6 import to sxml.simple.test in stable-2.0 anyway. any objection to that?
<mark_weaver>civodul's timing is impeccable.
<mark_weaver>we still have a problem that advice has been given several times on IRC and on the mailing list, to use the clever Guile string ports to do iconv conversions and the like.
<wingo>mark_weaver: in sxml.simple.test, sure...
<civodul>Hello Guilers!
<mark_weaver>wingo: but if we don't import it to sxml/simple.scm, then it won't work properly outside of the test code.
<wingo>mark_weaver: i have no problem with doing encoding conversion using string ports, but using set-port-encoding! / #:encoding and not the value from the locale
<mark_weaver>hi civodul.
<wingo>mark_weaver: ah i see what you mean
<wingo>i thought the problem was in (sxml ssax) and not (sxml simple) ?
<mark_weaver>civodul: I discovered that the sxml.simple.test failures we've been seeing in master for a while are due to the fact that string ports can't encode all characters by default.
<nalaginrut>ijp: ah~thanks~
<wingo>i think there is a thread on this somewhere...
<mark_weaver>wingo: (sxml ssax) doesn't create string ports.
<civodul>mark_weaver: ah, ok; #:use-module (srfi srfi-6) sounds good then
<civodul>as a short-term solution
<wingo>you sure?
<civodul>well, dunno :-)
<mark_weaver>wingo: well, it doesn't contain the string "string-port" in the file anyway.
<mark_weaver>nor input-string or output-string, which I guess are more relevant.
<wingo>in upstream/SSAX.scm
<mark_weaver>ah yes, you're right.
<mark_weaver>civodul: basically, the way string ports work is breaking Oleg's code, and we all know that Oleg is infallible :)
<mark_weaver>wingo and I think that string ports in master should handle all characters by default, regardless of the default port encoding.
<mark_weaver>what do you think?
*wingo thinks the ML is a better forum for deciding these things
<mark_weaver>Okay. I've already written several emails on this subject to the ML.
<wingo>yes i have too
<wingo>but i think we should still come to conclusion there
<wingo>easier to link to when looking back
<civodul>didn't we reach one?
<civodul>i think i said ok for Unicode string ports in master, no?
<wingo>yes i thought we did
<mark_weaver>ah, okay. maybe we did. if so, good :)
<civodul>it will break compatibility, so that's a tradeoff
<civodul>then AutoGen will no longer work and we'll all cry
<mark_weaver>well, in any case, I think that the sxml modules should import SRFI-6, right?
<mark_weaver>I think we need that in stable-2.0.
<mark_weaver>I'll take care of it.
*mark_weaver looks for other uses of string ports in stable-2.0 that should use the srfi-6 bindings as well.
<mark_weaver>really, I think almost all of them should.
<mark_weaver>there are quite a few.
<mark_weaver>hmm.. srfi-6 exports fixed versions of 'open-input-string' and 'open-output-string', but not fixed versions of 'call-with-*-string'
<mark_weaver>I see now that importing SRFI-6 does *not* fix the problem, because call-with-*-string is still broken. I only thought it fixed it because ./check-guile sxml.simple.test always works. it only fails in "make check" because some earlier test file set the default encoding to something different.
<mark_weaver>I also see that there are probably lots of other bugs in stable-2.0 related to this.
<mark_weaver>well, I need to sleep. I'll look at this later.
*mark_weaver --> zzz
*civodul discovers unsent messages in his draft folder
<civodul>in case you're waiting for an answer, it might be there ;-)
<mark_weaver>cky: hey, congrats on being #3 from NZ :)
<mark_weaver>(and the only one to use a decent language :)
<mark_weaver>well, I take that last line back. it was an exaggeration.
<_1126>mark_weaver: did I tell you that I got Guile installed on my Debian? Your help was good, thanks!
<mark_weaver>excellent! :)
<wingo>good evening!
*wingo cracks knuckles, sets about writing symbol tables
<bubu^>hello, got some (unrelated) issue installing last autogen
<bubu^>it requieres 2.0
<bubu^>but i have git installed
<bubu^>and i can't build 2.0.7 on this system
<bubu^>why not put something like autogen >= 2.0
<mark_weaver>bubu^: what goes wrong?
<bubu^>mark_weaver, I don't remember for 2.0.7
<bubu^>but I don't want to install this one :)
<mark_weaver>also, why build 2.0.7 when 2.0.9 is out now?
<bubu^>mark_weaver, because gentoo is outdated regarding guile
<bubu^>I was surprised they added 2.0.7
<bubu^>as 2.0.0 was masked for years
<bubu^>because of GC issues
<bubu^>so I took the git version
<bubu^>and never had problems for month
<bubu^>but now autogen requieres == 2.0 branch
<bubu^>so I can't update autogen
<mark_weaver>the latest autogen requires guile 2.0? really?
<mark_weaver>anyway, if you have guile from git, what prevents you from upgrading autogen. I'm very confused.
<bubu^>(or maybe they really failed their ebuild)
<bubu^>mark_weaver, because ./configure fails for autogen
<bubu^>it requieres guile == 2.0
<bubu^>not >= 2.0
<bubu^>and guile from git is tagged as 2.2
<wingo>you want the stable-2.0 branch
<wingo>it's a little confusing, but master is the dev branch
<bubu^>no, i want autogen to update :)
<wingo>hehe ;)
<bubu^>and keep guile dev
<mark_weaver>file a bug report on autogen.
<bubu^>so yes, i think it's more likely to be related to autogen
<wingo>bubu^: and link to the newer guile.m4 which allows packages to choose the versions of guile they might be interested in (see NEWS for details)
<mark_weaver>but frankly, we're doing most of our development these days on the stable-2.0 branch.
<bubu^>(i didn't make the ebuild)
<mark_weaver>master tends to lag behind a bit
<bubu^>i think it's just pull the master
<bubu^>git made the world a tough place to live :)
<dsmith-work>So autogen depends on exactly guile 2.0 intead of 2.0.x ?
<bubu^>dsmith, 2.0 branch
<dsmith-work>Well that's right and proper and good.
<bubu^>why not >= 2.0 branch ?
<mark_weaver>dsmith-work: I disagree. why should autogen disallow 2.2 or above?
<dsmith-work>Oh, I didn't mean that.
<dsmith-work>I meant it's good it desn't require master.
<mark_weaver>bubu^ has git master installed (2.2), and autogen rejects that
<wingo>mark_weaver: fwiw we might disagree here ;)
<dsmith-work>But it actually doesn ALLOW it.
<wingo>2.0 and 2.2 are parallel installable
<wingo>there's no reason for autogen to fail to build if 2.2 is installed
<wingo>and imo perfectly fine for them to update when they feel like it
*dsmith-work shuts up and goes back to work, apologizing for the noise.
<wingo>dunno, it's confusing and good to talk about :)
<Fulax>wingo: oh, good to gere that 2.0 and 2.2 are parallel instable, it didn't worked last time I tested, maybe one year ago
<wingo>Fulax: i think the binary names still collide
<wingo>but everything else is separate
<Fulax>using --program-suffix=2.2 should be sufficient then
<Fulax>no conflict on guile.m4 ?
<bubu^>I can install 1.8 and 2.0 in parallel, not yet 2.2 and git master is named as 2.2
<wingo>Fulax: probably there is a conflict there; though the intention is to install only one copy
<bubu^>could be nice also not to end like for python, have 3 versions installed, one for each software...
<wingo>bubu^: if installing 2.0 and 2.2 in parallel doesn't work, that's probably a bug
<bubu^>wingo, that's how the distribution handles it for now
<bubu^>guile-git is in the 2.0 branch
<wingo>the python-like situation is not ideal, but forcing people to upgrade isn't ideal either
<wingo>people get mad if their program stops compiling (with good reason)
<bubu^>if 2.0 programs can be run on 2.2 ?
<Fulax>bubu^: if this is a gentoo issue, the guile guys can't do anything. but you can discuss the issue in #gentoo-lisp
<wingo>and parallel installation allows us to actually remove deprecated instances
<bubu^>where is the problem ?
<wingo>bubu^: scheme programs should still run, C extensions might need adaptation
<wingo>though of course we try to minimize differences
<bubu^>Fulax, the thing is, for me it's an autogen issue, but not everyone agrees as you see :)
<bubu^>so you can tag the problem at 3 different spots :)
<wingo>^ that is the intention
<wingo>if guile is not doing the right thing, file a bug with guile
<mark_weaver>Fucking A. Two explosions near the finish line of the Boston Marathon. Just what we need.
<wingo>that's terrible!
<bubu^>what do you mean ?
<bubu^>bombs ?
<mark_weaver>I don't know. Maybe.
<bubu^>it's always good for buisness
<bubu^>to sell more assault rifles :)
<mark_weaver>it's always good for those who want to take our freedoms away.
<davexunit>mark_weaver: whoa really?
*davexunit checks news
<mark_weaver>well, I guess they're probably all covering it by now
<davexunit>the marathon finishes basically outside of my office building
<davexunit>thanks for the links mark_weaver
<davexunit>this is scary.
<davexunit>and not just because I work on boylston street.
<davexunit>but that certainly makes it a bit scarier.
<mark_weaver>are you there now?
<davexunit>no I had the day off because of the marathon.
<mark_weaver>oh, right, day off today no doubt.
<mark_weaver>I guess the fact that there were two explosions, so close together in time but in slightly different places, points quite strongly to the idea that these were in fact bombs, and quite intentional. :-(
*mark_weaver wonders if this was the act of some stupid idiot, or if it was done by those who want to create a pretext to crack down more on our already tattered civil liberties.
<bubu^>might be from some idiots and it will serve as a pretext for the men in black to take your liberty :)
<mark_weaver>yes, there's no doubt that those who want to create a police state will take advantage of this. I'm not sure why you keep smiling about it though.
<bubu^>because it's stupid :/
<mark_weaver>it's not stupid if it was done by those who want a police state. unconscionable, but not stupid.
<davexunit>I think we'll find out very quickly that they were bombs.
<davexunit>and that there were deaths.
<Nafai>2 confirmed deaths :(
<tupi>this is terrible! i hope it is an accident [i didn't read the news yet]
<mark_weaver>I don't see how this could be an accident. Two explosions just 10-20 seconds apart, a couple of blocks away from each other.
<bubu^>gaz pipe :)
<mark_weaver>images and video here:
***linas__ is now known as linas_
<fbs>civodul: :o
<fbs>civodul: gnutls: 10002|4 REC[0x901c60]: Decrypted Packet[1] Application Data(23) with length: 150
<fbs>" NOTICE Auth :*** Looking up your hostname...\\r"
<fbs>looks like it works
<civodul>fbs: aah, good news!
<civodul>are you able to exchange data over the session record port?
<fbs>its quite a mess atm but it looks like its connection to the irc server (local)
<fbs>socat openssl-listen:8000,reuseaddr,cert=cert.pem,verify=0 -
<fbs>that also works
<civodul>fbs: note that you're supposed to use "priority strings" nowadays, instead of the set-*-priority! things
<fbs>I just glued some manual/example code together, glad I finally got everything working
<civodul>so it's an IRC client?
<fbs>Atm its just some test code, but i want to glue it into my old irc lib. Most of the servers im on are ssl only
***ijp` is now known as ijp