<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>Down to about 12-40K per IRC line instead of about 700K per line. <ijp>I don't know bobot, but this sounds nuts <ijp>so this is a libgc interaction problem <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>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>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. *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 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) <ijp>that said, I did make it crash once <ijp>mark_weaver: the algorithm is stupidly simple, but work surprisingly nicely <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] <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. <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 <ijp>wow, someone actually managed to use 9 different langauges <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. <tupi````>mark_weaver: tx, yes i did imagine that you had done that, but i am thinking to our users <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 <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>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>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. ***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. <nalaginrut>mark_weaver: well~but I thought Guile has no chance to solve 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>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>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. <mark_weaver>well, for the last three years we've had probably the best debian project leader that we've ever had. <ijp>hmm, I may have it, but I'd need to do the working <nalaginrut>the first step, maybe write guildhall with Guile <ijp>no, I don't think I have it <ijp>I was talking about mark's puzzle <dsmith>I think it was already there, with the S <dsmith>That's the mark_weaver summoning device <nalaginrut>ijp: could you remind me that the four ways of optimization? compile/cache...and? *dsmith collects his winnings offline, then heads off to bed <ijp>but dsmith got it right <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" :) <ijp>I just assumed they had reinvented irc <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 <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 <wingo>and i apologize for saying i would handle that and not doing it :/ <wingo>i just didn't want to paper over the problem <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>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... <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 <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. <wingo>i think there is a thread on this somewhere... <civodul>mark_weaver: ah, ok; #:use-module (srfi srfi-6) sounds good then <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. <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. *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>but i think we should still come to conclusion there <wingo>easier to link to when looking back <civodul>i think i said ok for Unicode string ports in master, no? <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 looks for other uses of string ports in stable-2.0 that should use the srfi-6 bindings as well. <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. *civodul discovers unsent messages in his draft folder <civodul>in case you're waiting for an answer, it might be there ;-) <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! *wingo cracks knuckles, sets about writing symbol tables <bubu^>hello, got some (unrelated) issue installing last autogen <bubu^>and i can't build 2.0.7 on this system <bubu^>why not put something like autogen >= 2.0 <bubu^>mark_weaver, I don't remember for 2.0.7 <bubu^>but I don't want to install this one :) <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^>and never had problems for month <bubu^>but now autogen requieres == 2.0 branch <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^>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 :) <bubu^>so yes, i think it's more likely to be related to autogen configure.ac <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 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 ? <mark_weaver>dsmith-work: I disagree. why should autogen disallow 2.2 or above? <mark_weaver>bubu^ has git master installed (2.2), and autogen rejects that <wingo>mark_weaver: fwiw we might disagree here ;) <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 <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 <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>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. <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. <mark_weaver>well, I guess they're probably all covering it by now <davexunit>the marathon finishes basically outside of my office building <davexunit>and not just because I work on boylston street. <davexunit>no I had the day off because of the marathon. <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. <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. <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. ***linas__ is now known as linas_
<fbs>civodul: gnutls: 10002|4 REC[0x901c60]: Decrypted Packet[1] Application Data(23) with length: 150 <fbs>":penguin.omega.org.za NOTICE Auth :*** Looking up your hostname...\\r" <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 - <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 <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