<fbs>So I got my irc library, it still seems to work <fbs>I figured I need to add some kind of threading system <fbs>Atm it just parses incomming messages and runs installed handlers on it to handle pings <fbs>But i have no idea what to do, and how <ijp>well, unless your bot is doing significant computation, wouldn't that be fine? <fbs>Its not really a bot, just a 'library' <fbs>So I guess I need access to the parsed messages and add/remove handlers, read errors and stuff <fbs>ijp: what would you do if it has to do a 1 minute computation? <ijp>do the computation in a different thread/future. Put the result somewhere the main can find it <ijp>cky: you doing the code jam this year? <fbs>scheme@(guile-user)> ,use (gnutls) <fbs>fish: Job 1, 'guile' terminated by signal SIGSEGV (Address boundary error) <taylanub>You use the Friendly Interactive Shell ? <fbs>it doesnt seem able to do ./autogen.sh <fbs>The file './autogen.sh' is marked as an executable but could not be run by the operating system. <fbs>yea its works fine with bash/zsh <taylanub>(Although I don't think Bash would allow a +x that way ..) <fbs>autoreconf: Entering directory `.' <taylanub>(I thought maybe sh does magic and executes it with itself.) <taylanub>(But that would totally beat the point of -x.) <fbs>anyway, how do i debug what gnutls is doing? <fbs>its the guile-gnutls in debian <taylanub>Since it's a segfault, I'd say GDB, but I have zero experience .. <fbs>i tried guild compile and that works <fbs>Oh, I think its guile1.8 only <ijp>first one wasn't bad <sneek>civodul was here Apr 12 at 03:48 pm UTC, saying: good. <fbs>is there an easy way to find out if the newest gnutls works with guile 2.0? <ijp>hmph, as is traditional during coding contests, my computer crashed <fbs>guess i could wait for civodul to show up <wigs>that will be at least several hours <wigs>how long to try, minutes? <fbs>Still gives the same segv <wigs>this is gnutls from git? <ijp>I see our friend mark_weaver has entered codejam again this year <fbs>wigs: nope the latest in debian experimental <wigs>fbs: that package is not built against guile-2.0 <wigs>are you building it from source? <wigs>according to gnutls/NEWS, guile-2.0 compatibility is added in 2.9.7. for the debian packaging, you may need to make some adjustments <ozzloy>is there an installer for guile on ms windows? <fbs>wigs: so far not that much success in compiling <wigs>fbs: you know what the issue is? <fbs>newest tags need some libnettle version i dont have, one tag failed during compiling and this one does too <fbs>I might try again when i have time again after the exams <fbs>lets hope the debian people get a decent version in soon <sneek>Sneeky bot running on Guile version 2.0.9 using bobot++ 2.3.0-darcs <wigs>fbs: unlikely due to freeze <fbs>seems weird they still only have 1.8 libs in experimental while 2.0 is over a year old <wigs>there is not yet any guile support tool for packaging in debian <wigs>this makes it difficult to e.g. provide both guile-1.8 and -2.0 libraries <wigs>other runtimes (e.g. python) have nice helpers to support this automatically. having the same for guile is very near the top of my TODO list <sneek>Sneeky bot running on Guile version 2.0.9 using bobot++ 2.3.0-darcs *dsmith just shakes his head <wigs>fbs: you probably can compile if you pull in build-deps from experimental <dsmith>And make sure you are using the correct libgc <wigs>I think if you are using debians guile-2.0, you be alright with the debian libgc <wigs>although, some flakiness! <fbs>I was planning on doing a reinstall when the new debian is released and then compile the latests stuff <dsmith>The 2.0.5 or whatever it is? Yeah, I think that combo works. <wigs>eh, released, not released, its all very much the same at this point <fbs>True, but i dont have time for the next 5 weeks <fbs>debain package build helper I think <wigs>key component for keeping guile modules up-to-date <fbs>I'll check again in 6 months :p <fbs>time for bed, thanks for your help wigs <wigs>fbs: next attempt should work, update your build-deps :-) <wigs>(checked debian/rules, etc. and it looks ok to support guile-2.0) <ijp>gah, the array procedures suck ***adu_ is now known as adu
<wigs>ijp: you spend much effort groking this "sieve" the other day? <wigs>* had to stop at list mutation <ijp>it took me some effort, but I'm not going to claim I got it fully <ijp>okay, I feel like I giant idiot over problem B on code jam <ijp>I had the solution ages ago, convinced myself I was wrong, wrote some hideous array code, went back to my original solution *ijp goes to cry in a corner <ijp>no idea how I can optimise my C further though :/ <wigs>nalaginrut: well its very general, and meant for debugging <nalaginrut>wigs: and number->string and call-with-output-string <wigs>numbers in scheme are a rather broad concept <nalaginrut>when I'm doing profile, the ->string part is the bottleneck <wigs>well some parts are bound to be slower than others <wigs>string conversion generally involves lots of branches <ijp>nalaginrut: problem C? <nalaginrut>and when I'm trying to do it with list rather than string, I found the mem consuming terrible <ijp>Right now, best I've managed is 9m for the large input <ijp>frankly, I don't think Guile has a chance for the even larger input <ijp>wigs: the problem involves testing whether large numbers are palindromes <nalaginrut>ijp: I thought Guile is proper for the very large integer, but the computation is too poor <ijp>well, there is a lot of overhead still to be overcome in the implementation <nalaginrut>anyway, in such an extremely test, we may found the bottleneck of Guile's implementation <nalaginrut>forget about it, I'll try B first, and take a break <ijp>well, I dont think that's entirely true <ijp>it is hard to make number->string fast because scheme has a complex (not in the mathematical sense) number representation <ijp>a more specialised version for only handling integers (written in C) could do much better on this problem <nalaginrut>I think there should be a way to improve integer <ijp>that's easier said than done, I think <wigs>not so quick to convert such bignums <ijp>secondly, if I were going to go down this route, I wouldn't even want to convert to a string <ijp>but that isn't as fast in practice <nalaginrut>string consumes very less mem, but more CPU time <ijp>anyhow, the problem isn't just number->string, but in how you test <nalaginrut>how about R? but I think R is lisp implementation with a new-syntax-coat, maybe no chance too <wigs>nalaginrut: language is not your issue, but algorithm <ijp>there are 4 main ways to speed up a computation according to norvig: compilation, indexing, caching, and delaying evaluation <nalaginrut>ijp: yes, but when I optimized several times test function, I found even the first line data halt at number->string <ijp>I don't understand what that sentence means <ijp>streams suck for this, if that's what you are after <wigs>no, just thinking a loop <wigs>to calculate and compare the most and least significant digits one at a time <nalaginrut>ijp: and the test implementation related to string/list for me now <ijp>anyway, this is mostly academic. You don't get a second shot at the large problem set, and I can see we both timed out on it. And the largest one is just plain out of reach of Guile I think <nalaginrut>I definitely drop the largest one, but I will find a way to solve middle one after the match <ijp>not just that, only 29% of them got it right <nalaginrut>alas, when I wake up at 7:30, there're guys got 100+ , only 30 minutes from start <ijp>there were a couple submissions within the first five minutes <ijp>nah they were wrong, so I don't think they thought it all through <ijp>I think I must have went insane, because apparently I've reduced my time from 9 minutes to 30 seconds <ijp>which I don't believe <ijp>I don't understand it at all <nalaginrut>ijp: just kidding, I was excited for very few time to solve it, but then realize that it's Guile aborted, there's syntax error ;-P <ijp>I'm going to just see how it fairs on the second large result. I don't actually expect it to work, but I've got nothing to lose. <nalaginrut>if it's 30s, I think there's maybe chance for the largest one <ijp>I don't know, the numbers are a lot larger <nalaginrut>I wonder if 10^100 would depend on users' machines <ijp>but for 55 points, I might as well give it a shot <wigs>dont think so, i suspect the algorithm is more important <ijp>nah, ran out of time <ijp>10000002000000100200020020202020021002202012000800021020220012002020202002000200100000020000001 & co, were just too big <ijp>I dunno, ISTR they had a palindrome number problem last year <wigs>did anyone reuse results from earlier test cases? <wigs>avoid recomputing known ranges <ijp>I didn't persist them, no, but that wouldn't have been a terrible idea <wigs>its an interesting problem, how to break up the search space <nalaginrut>I just avoid to persist anything, since I'm afraid of mem consuming <ijp>Anyway, I'm off to go get some sleep. I might give the last one a try when I wake up. <wigs>nalaginrut: persisting the interval+count is not so bad <wigs>particularly since maximum of 10000 test cases <nalaginrut>hmm~I have some chances, it's 15:00 for me, it's nice time <ijp>wigs: well, you need to store all the "fair and square" numbers, since you won't know the ranges till you get the file <wigs>i.e. test #1: 600–1000 = 22 palindromes <wigs>test #2: 100–1000.. can reuse the first result <nalaginrut>hmm...and I'm trying to split the range to four, and take advantage of future <wigs>,time (palindrome? 10000002000000100200020020202020021002202012000800021020220012002020202002000200100000020000001) <wigs>;; 0.027000s real time, 0.003000s run time. 0.000000s spent in GC. <wigs>nalaginrut: how is your palindrome? compare to that <nalaginrut>;; 0.000774s real time, 0.000728s run time. 0.000000s spent in GC. <wigs>is that for the same number? <nalaginrut>scheme@(guile-user)> ,time (is-palindrome? 10000002000000100200020020202020021002202012000800021020220012002020202002000200100000020000001) <nalaginrut>$9 = 10000002000000100200020020202020021002202012000800021020220012002020202002000200100000020000001 <nalaginrut>;; 0.000774s real time, 0.000728s run time. 0.000000s spent in GC. <nalaginrut>wigs: but I think it's no proper to leak the code now, since the match is going on ;-P <nalaginrut>hmm...after using future, the result became wrong... <zxq9>Does guile-dbi work on guile 1.8 and guile 2? <zxq9>Seems like both should be fine. I'm on 1.8 and was praying I wouldn't have to do anything complicated to move to 2. <zxq9>One more silent triumph in my little world... ty :) <nalaginrut>IMO, guile-dbi uses guile1 API, and the current release modify it to Guile2 <nalaginrut>the latest release changed the API yesterday, so I think it may compatible if you use little older version dbi <nalaginrut>wigs: theads+cache for palindrome, it's hopeless... <zxq9>What've got now is DBI 2.1.4 under Guile 1.8 with no problems. I'm hoping I can move some code forward to Guile2 without major surgery wherever I touch the DB. <nalaginrut>zxq9: if your aim is to use guile2, I think it's fine, since I use it under guile-2.0.9 <nalaginrut>the only problem I think is you have to build guile2 first <zxq9>Hrm... I'm rebuilding guile-dbd against postgres9.1, which has its includes and libs (libpq, in particular) in a new place the guile-dbd configure script doesn't know to look for. <zxq9>How do I pass it the new locations when configure doesn't recognize --with-includes or --with-libraries nor check the CXXFLAGS? <nalaginrut>zxq9: when I installed guile-dbd on centOS, I found I have to make link from the 'extension' path to /usr/lib <zxq9>linking to /usr/lib worked out, but it also required changing postgresql/libpq-fe.h to libpq-fe.h in a source file... which was sort of weird, but anyway, I got a clean build of both now. :) <wigs>nalaginrut: hope you arent using a brute force search :-) <wigs>nalaginrut: on palindromes <nalaginrut>wigs: hmm..I did enumerate all the num and check <wigs>nalaginrut: quicker to generate the series of palindromes, and square them <wigs>an interesting problem. how long before we can see solutions? <nalaginrut>wigs: the given number is too big, if I can't eliminate large part numbers between the range, the effort is useless <nalaginrut>wigs: 12 hours later, we may read the code of other guys <nalaginrut>wigs: even I have very fast palindrome checker, 0.0007s cost each time, just think about 1001902982101 times loop <stis>anlginrut: which problem? <stis>I mean what problem are you trying to solve? <wigs>nalaginrut: got to eradicate that much looping <wigs>threads are only a distraction <stis>I would try to use the tools from reasoned schemer to solve this :-) <wigs>that may elicit an elegant solution. no idea how well it would perform <nalaginrut>you'll meet stackoverflow anyway, if you can't find a way to eradicate the loops ;-P <nalaginrut>well, thers's no stackoverflow actually, but 4 cores CPU with threads can't deal with my ugly algorithm ;-D <stis>for kanren: the performance depends on if you can backtrack early and skipp large branches of the search space! <stis>an the other hand knren is probably 1000x slower then C! <stis>So I would consider porting it over to e.g. gprolog <stis>That could by a factor of 100 <wigs>I wonder if anyone submits an answer using a relational language <stis>No it's hard core but really an interesting task! <stis>To note you will do the multiplication by doing it the hand book style and then try to search for cut oppurtunities. <stis>I really don't know if there are any though! <nalaginrut>wigs: actually, guys use sed/awk/gnuplot... to solve the problem <stis>And even if there is oppertunities it can be dwarfed by the spped of hardware multiplication compared to dooing it in a program! <nalaginrut>wigs: it's programmer's carnival, so many strange but cool style for the match <nalaginrut>last year, a guy use different non-common-language to solve each problem <nalaginrut>I didn't read the code of gnuplot, I don't know how they cold <fbs>sneek: later tell wigs I fixed gnutls-guile2.0 it by getting libnettle and gnutls-3.1.9 :) <cky>ijp: I am. Come join us at #gcj2. :-) <fbs>does anyone have a simple example of guile with gnutls? <add^_>fbs: what are you doing? :-) <add^_>fbs: I added tls support to your irc thingy, and made a bot with it too, although I haven't put the bot on github :-P <add^_>Although I guess the tls support could be made much more... neatly. <cky>add^_: About the non-GnuTLS TLS support. <add^_>I wouldn't make my own tls implementation :-P <add^_>cky: So, you could use what I have and polish it up, and if you put up that version, I could take down mine :-P <add^_>I wish I made the code less... hacky. Then you wouldn't have to polish it up. <add^_>It's probably an easy fix though *add^_ is reading through "The little Schemer" and "The seasoned Schemer", and waiting for the third book to be delivered. <cky>The third book is The Reasoned Schemer. <cky>A 2nd edition of that is coming out soon. <cky>BTW, I see that mark_weaver is kicking butt in GCJ today. Very impressive!! <add^_>A second edition? Maybe I shouldn't have bought it yet :-/ <add^_>Oh, hope it all goes well for mark_weaver <fbs>nice to see it being used a bit <add^_>It was fun to play around with, but my friends got tired of my bot ;-) <add^_>Well, I was at fault for that I suppose, lol <cky>add^_: Why, did you make it super-annoying? :-P <add^_>I accidentally had to debug it in our channel <add^_>And it was a bit much for them <zxq9>Are there any maintained RPMs for Guile2 on RHEL6||derivatives? <add^_>But it was a learning process <fbs>add^_: would be nice if you put it some where so i can steal your tls and other improvements, <fbs>havent really used github in the last year :p <add^_>You haven't really been *here* for the last year ;-) <add^_>I'm not good at making commits <fbs>i usually rebase squash them <add^_>I had to change one thing that was really disturbing, :banana: or something <fbs>squash comits with rebase -i <fbs>lets you edit, reorder and merge commits <fbs>so you can do sigh and fuck and ... and when youre done squash them into one nice commit <add^_>Did I really write those as my commits? <add^_>I tend to go for non-foul language <fbs>i found a sigh and a ... <add^_>Those I remember, I just didn't remember the other one <add^_>I could give you the changes I've made, I recommend you clean them up though <fbs>yea im looking at them, i dont have time for the next 5 weeks anyway <add^_>There's so many commits that's just me fumbling around not knowing what the heck I'm doing <fbs>i see you change a bit of the build system <add^_>Yeah, yours didn't work for me <add^_>But I could send you *just* the code, and you do whatever you want with the rest. <add^_>It's up there, but I don't want to merge all my lame commits with yours. :-P <fbs>if you just keep the repo online its fine <fbs>its on my todo list :p <fbs>if you feel like making a nice pull request or something youre free to do so <fbs>dont forget to add yourself to the authors tho :p <add^_>Removed the old fork, I couldn't figure stuff out so now I'm making fresh :-P <add^_>Still have the old thing on this computer though.. If one would for some (unknown) reason want the old commits. <fbs>i think you can just create a new branch starting at your first commit, rebase and fix all commits and then delete the old branch and push that <fbs>anyway, looking forward to a nice pullrequest :) <fbs>git add -p might also be nice if you dont know it yet <fbs>i sometimes use it when i got a lot of changes to a file that I want to put in diffferent commits <fbs>if you have questions just ask/pm, im off to make food <add^_>Hope it goes well, since I read that as you were going to eat, not make. <add^_>ah geez, I'd forgotten to install gnutls on my newly installed computer where I'm cleaning up the code.. Now on to that.. <add^_>Huh, weird, I could have sworn it looked worse.. :-P <ijp>cky: I didn't see your score on my 'friends leaderboard' so I assumed you didn't enter <cky>ijp: I'm participating now. <cky>ijp: Anyway, feel free to join #gcj2 if you want to. :-) <cky>I'm currently working on problem C, in Scheme, and problem A, in x86 (or maybe x64) assembly. <cky>Some people are going to try to solve the problems in 9 languages (one language A-small, one for A-large, one for B-small, etc.). <ijp>hmm, I'm a little concerned now about a 'shortcut' I took in C <cky>nalaginrut: Because it's more interesting than some of the other contenders. <ijp>anyway, I will want to pick mark_weaver's brains over this <cky>And there's not much learning curve for me, unlike, say, Whirl, or brainfuck, or... <cky>ijp: You're not really supposed to be discussing problem specifics during the contest. :-) <cky>ijp: So I'm not sure how you will pick his brains about it, unless you're talking about after the contest. <ijp>and I can wait 7 hours <cky>I do have a solution approach, and hopefully it's not too slow. <cky>Wow, this is strangely more elegant than I thought. <add^_>Hope you all will succeed well :-) <add^_>Hm, I wonder how to make autoconf check if gnutls is installed.. <add^_>I'm adding that into my configure.ac before I make a pullrequest to your repo fbs <add^_>Also, I wonder why I added my name to some of the files I didn't code anything at all... Geh <fbs>how do i debug 'ice-9/boot-9.scm:106:20: no code for module (gcrypt internal) <fbs>i just cloned his repo and cant get it to build <add^_>Sorry for obvious question, do you have gcrypt installed? <fbs>It worked before i pulled it in <fbs>probably someting easy <fbs>yea guess its time to do that <add^_>shizzy0: not right now it seems <fbs>add^_: ah nice, ill take a look once i figure this out <fbs>i have no idea whats happening :p <add^_>I could try it out, but I need to install gcrypt first I guess <fbs>yea, would be nice if you could try <add^_>is it libgcrypt11 I should install? <add^_>I'm guessing that because that's the only one I have in my repo <add^_>I guess I'm going to have to tweak the configure.ac file to even get that working <fbs>manually loading the file into guile seems to work <fbs>if i swap random.scm and hash.scm in the automake i get the same error on random.go <fbs>add^_: why is acinclude.m4 in the pullrequest, isnt that automagic? <add^_>Some have it installed, others (like me) don't <shizzy0>anybody feel comfortable sharing Andy Wingo's email with me? I'm not a spambot. Promise. <add^_>I changed internal.scm to be above the others, and some other autoconf/automake stuff <fbs>can you give me a git diff ? <add^_>Where do you start having problems? ./autogen.sh && ./configure && make <fbs>ice-9/boot-9.scm:106:20: no code for module (gcrypt internal) <fbs>its somewhere in the buildsystem <add^_>hm, then I'm not sure if you really need all my junk. Can't you try putting internal.scm \\ on the top then hash.scm \\ and then random.scm (all with gcrypt/ before) <fbs>if you can just 'git diff' and pastebin that ill probably figure it out <add^_>Does that give all the info about what I changed though? *add^_ is pasting, wait a moment <fbs>not if you commited stuff or added/changed autogenerated files <add^_>But there's files that needs to be added.. <add^_>Gosh, I'll just up it to github or something <fbs>tarball of the repo is fine <taylanub>I want to achieve behavior like, after (my-define x y), (my-reference x) expands to y during compilation. What would be the cleanest way to do this ? <ijp>taylanub: depends, what is y <taylanub>"Anything" I guess. I'm not sure if I'm getting caught in the XY-problem here, what I really want to do is define a variable in the expander's environment, such that I can later reference that variable in another macro call, to influence the behavior of the macro. Well, what I *really* want to do is to make a clean syntactic version of my bytestructures code. :P <taylanub>And ideally the user should be able to define new bytestructure-descriptors in the same file, such that later calls to `bytestructure-ref' etc. (which should do their thing during macro-expansion) will understand that descriptor. <ijp>taylanub: well, it isn't quite as nice as it could be. <ijp>the easiest way might be to use eval-when <taylanub>I think eval-when is acceptable for new definitions. How about the reference though ? E.g. in (bytestructure-ref descriptor bytevector index ...), how will `descriptor' be dereferenced and used ? <ijp>my brain isn't functioning well enough for macro questions at the moment <taylanub>Honestly I'm thinking of just using `eval' in the syntax-transformer. :\\ <mark_weaver>damn, I just can't get a handle on how to solve that last problem :-( <ijp>mark_weaver: me neither :( <ijp>taylanub: google code jam <mark_weaver>I used Guile for all the problems I did solve though, and they all ran very fast. <ijp>mark_weaver: I was a little concerned about C part 3 for speed <ijp>hmm, how long is left before we can talk specifics <mark_weaver>I know that using C for the last problem wouldn't save me. I need a better algorithm. ***jao is now known as Guest8691
<ijp>hmm, four hours left to go <mark_weaver>to be honest, I'm not sure that my solution to the largest input of problem C was correct. *crosses fingers* ***Guest8691 is now known as jao
<ijp>right, I noticed a flaw in my solution earlier, but by then it was too late <mark_weaver>regarding prob C part 3: coding it in a faster language won't help. if you don't have a good algorithm, you're completely hosed. <ijp>B was the most embarrassing for me <ijp><ijp> I had the solution ages ago, convinced myself I was wrong, wrote some hideous array code, went back to my original solution <ijp>well, nested vectors <ijp>it's not even a question of speed, the api sucks <mark_weaver>and I typically define some procedures to make accessing them nice. <mark_weaver>if you look at my solutions from last year, you'll see me do that a lot. <mark_weaver>things like (define grid (let ((v [compute vector of vectors])) (lambda (i j) (vector-ref (vector-ref v i) j)))) <mark_weaver>vector-ec from SRFI-42 is a great help as well. I like SRFI-42 for this because it generates fast code. <mark_weaver>but yeah, we can't talk about the actual problems/algorithms until the contest is over. <ijp>taylanub has some macro trouble, you might be able to help him with <ijp>foof loop generates okay code <ijp>maybe the nested extensions could have covered that, but I rarely use them <mark_weaver>ijp: does that loop generate output, or does it call 'f' only for side effects (too lazy to grok generated code) <ijp>well, v1 v2 and f don't actually exist <ijp>so the optimiser treats them as opaque <ijp>in this case, f would be sideeffecting <mark_weaver>I'm trying to understand what that code does, so that I can write an analogous loop using srfi-42 for comparison. <ijp>mark_weaver: a nested loop, i & j traversed in parallel in each <ijp>all in all, foof-loop isn't that clever <mark_weaver>are 'i' and 'j' bound to elements of the vectors, or indices? <ijp>mark_weaver: elements there, though you can bind indices as well <ijp>(vector-for-each (lambda (i j) (vector-for-each (lambda (k l) (f i j k l)) v1 v2)) v1 v2) <ijp>vector-for-each works on multiple vectors, right? <ijp>the thing that bothers me most about srfi 41 is its extension mechanism <cordawyn>hello! A newbie question, if you don't mind ;) <cordawyn>What are .sls files? I can see they're plain Scheme, nothing special. <mark_weaver>I confess that I'm not thrilled about the use of mutable variables. <ijp>cordawyn: .sls is an r6rs convention for library files <cordawyn>and guile's use-modules doesn't like them? <mark_weaver>ijp: what's wrong with the extension mechanism? I guess it could be a bit easier to use, but I hear the foof-loop's extensibility isn't so hot either. <mark_weaver>someone should really make a loop macro based on Oleg's 'ck'. With that, you could make a very elegant easy to use extension mechanism I think. <ijp>cordawyn: you can add the extension to guile with -x <ijp>cordawyn: but if there is a package on guildhall that still uses it, I should probably change that <cordawyn>ijp: I'm trying to get parscheme to work here, but guile complains "ERROR: no code for module (wak private include)", which is an .sls file, unlike the rest <ijp>mark_weaver: yeah, the problem with foof-loop is that it's a cps macro, not very sexy <mark_weaver>cordawyn: the problem is, supporting .sls by default would slow down module loading. the number of filesystem lookups is proportional to the number of entries in your load patch *multiplied* by the number of extensions. <cordawyn>ijp: so there's no way around that, you'll have to tweak parscheme at guildhall? <ijp>sure, you can run a script with -x .sls <mark_weaver>cordawyn: strange. on my system, wak/private/include.scm exists, and wak/private/include.sls does not exist. <mark_weaver>cordawyn: are you using ijp's repo, or something else? <cordawyn>i wak-parscheme 0-2009.5.29-2 parser combinator library <ijp>I don't have a .sls for it either <cordawyn>it looks "underported" too - there are s48-{package,interface}.scm files there ;) <mark_weaver>ijp: is wak/private/include.* part of wak-parscheme, or a different package? (maybe wak-common?) <ijp>but I'm looking at the zip right now <cordawyn>i wak-common 0.1.0 common infrastructure for the Wak ports <mark_weaver>cordawyn: what version of wak-common do you have installed? <mark_weaver>cordawyn: ah, mine in 0.1.1.. you need to upgrade that. <ijp>weird, that it doesn't use 0.1.1 <mark_weaver>ijp: is there a way to upgrade all installed packages? <ijp>mark_weaver: I was mostly thinking of :-dispatch-set!, :dispatched looks unobjectionable <ijp>mark_weaver: 'guild upgrade' should try to upgrade them all <mark_weaver>I think that has to do with the feature (for better or worse) that you can shorten things like (:vector x vec) to (: x vec), and (:range i N) to (: i N). <cordawyn>(on a totally unrelated note: big thanks to the makers of "info guile" - my "info"phobia had been cured by that well-made doc!) <mark_weaver>I guess it's similar in some ways to CLOS/GOOPS having mutable method tables, except that in this case the reasons for it are far less compelling. <ijp>well, srfi 42 is limited by the fact that r5rs doesn't have a module system, or any other real extension mechanism <ijp>but once you are in a Scheme that does, it's just a poor clone <mark_weaver>ijp: fwiw, although I still have some reservations about some details here and there, I've come to think that R6RS is the right way forward. <mark_weaver>I'll probably work on some of the hard bits of improving R6RS compliance at some point, e.g. R6RS exceptions, transcoders, phasing, etc. <mark_weaver>I might even try to get in the habit of writing more portable code again. (I tried that once for R5RS, but it mostly didn't work out :) <ijp>how would transoders fit into your port changes? <mark_weaver>I'm not sure exactly. I haven't yet studied it carefully. <mark_weaver>I think it's mostly orthogonal to the recent ports work I did though. <ijp>the srfi-42 generated code and the foof-loop generated code is structurally very similar <ijp>not surprising really *ijp goes back to playing with (ice-9 peg) <cky>mark_weaver: My solution for C-large takes 9 seconds, running on Racket. <cky>(I nuked my Guile installation to make way for 2.0.9, but never got around to building it yet.) <cky>mark_weaver: Not sure how yours performs in comparison. <cky>I'm about to start on problem A, writing a Scheme reference implementation first, then an assembly version to test out a new implementation technique. <cky>mark_weaver: Feel free to join #gcj2 if you enjoy talking about non-spoilery stuff about stuff. <cky>shizzy0: You can leave messages for wingo via sneek. <cky>Just say "sneek: later tell wingo <Your message here>". <mark_weaver>cky: 9 seconds, that's very good! the solution I submitted took 1m12s, but it's easy to make faster. I just didn't bother. A super-easy improvement makes it 17s, and it would be easy to go further. <cky>I wasn't even micro-optimising at all. <mark_weaver>the actual computation of the fair and square numbers up to 10^100 takes only 3 seconds. <cky>Just wrote something that's straightforward but not brute-force (of course). <mark_weaver>however, I confess that I'm not 100% sure that my solution is correct. I made a guess. *crosses fingers* <cky>We'll just have to compare code afterwards to see if we were on the right track. :-) <mark_weaver>I really have no idea how to solve the last problem. I've basically given up at this point. I'm too exhausted to think about it any more. <cky>mark_weaver: Yeah, I'm not bothering with B or D. <cky>I'm only doing A as a hedge in case C-large were wrong. <mark_weaver>I have some ideas about D, but I don't have enough confidence that it would run fast enough (even for the small problem), and am insufficiently motivated to write a bunch of hairy code that might not work. <cky>I'd rather do an assembly version of A than to do B. :-P <cky>mark_weaver: Yeah. I think for a 60-point problem, it requires some really smart solution approaches, not just optimisations of a straightforward one. <cky>mark_weaver: Me? Uh, uh, okay, maybe.... <mark_weaver>If you bail on B, I think you will do a *head-desk* when you see the solution. <cky>mark_weaver: I have a solution approach for B already. <cky>I don't know if it's correct, but it's worth a try. <ijp>I have a feeling I'm going to do that when either of you explains to me how I was supposed to have done C