00:19 jonrafkind: i just updated git and tried to rebuild but I got this error: default-load-handler: cannot open input file: "/home/jon/svn/plt-docs/src/b/racket/gc2/xform-collects/racket/path.rkt" (No such file or directory; errno=2)
00:19 jonrafkind: anyone else see that?
00:21 askhader: I want to use fold-files to create the structure of mine. However I want the behavior that if a directory was encountered then its contents should be nested a by a single layer within the list. I can see why the following doesn't work but can anyone else see a way to do this with a single call to fold-files? http://paste.lisp.org/display/116432
00:22 askhader: Or perhaps I just ought not to use fold-files.
00:29 jonrafkind: ok a clean build seems to have fixed it
00:31 (quit) Fare: Quit: Leaving
00:34 (quit) RyanRN: Quit: Leaving.
00:46 (quit) jeapostrophe_: Quit: jeapostrophe_
01:05 (nick) His_Shadow -> Lajla
01:41 (quit) danbrown: Remote host closed the connection
02:12 (quit) jonrafkind: Ping timeout: 240 seconds
04:40 (join) martin_hex
04:40 (quit) martinhex: Disconnected by services
04:40 (nick) martin_hex -> martinhex
04:41 (join) Ogion_
04:47 (quit) Ogion: *.net *.split
05:02 (join) offby1`
05:04 (quit) offby1: Ping timeout: 260 seconds
05:21 (quit) jao: Read error: Operation timed out
05:24 (join) RyanRN
05:55 (join) jao
06:37 (join) b-man_
06:58 (quit) Axsuul: Ping timeout: 250 seconds
06:58 (quit) Yann3: Read error: Connection reset by peer
07:00 (join) Yann1
07:06 (quit) vu3rdd: Quit: ERC Version 5.3 (IRC client for Emacs)
07:45 (quit) martinhex: Remote host closed the connection
07:51 (join) samth_
07:57 samth_: jeapostrophe, does the xrandr fix not take effect till we get to that revision?
07:59 (quit) mikeX: Ping timeout: 260 seconds
08:16 (join) mikeX
08:26 (join) MayDaniel
08:29 (quit) samth_: Ping timeout: 252 seconds
08:39 (quit) MayDaniel: 
08:53 (join) jeapostrophe_
09:13 (join) danbrown
09:25 samth: jeapostrophe_, jeapostrophe, does the xrandr fix not take effect until that push?
09:26 samth: or did it not fix the problem?
09:26 jeapostrophe_: it didn't fix it
09:26 jeapostrophe_: i need to switch the way i am faking X11
09:26 jeapostrophe_: I'm in the process of trying something else
09:26 samth: what version of ubuntu are you using?
09:27 samth: i think on 10.04, xrandr works with xvfb
09:27 samth: at least according to their bug tracker
09:27 jeapostrophe_: hmm
09:27 jeapostrophe_: maybe i'll try to upgrade
09:27 jeapostrophe_: i'm on 9.10
09:27 jeapostrophe_: do you know how i upgrade?
09:28 samth: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/516123
09:28 samth: do you have a gui on the machine?
09:28 jeapostrophe_: nope
09:29 samth: see: https://help.ubuntu.com/community/LucidUpgrades
09:29 (quit) mikeX: Read error: Operation timed out
09:29 samth: in particular: https://help.ubuntu.com/community/LucidUpgrades#Network%20Upgrade%20for%20Ubuntu%20Servers%20%28Recommended%29
09:29 rudybot: http://tinyurl.com/32jfoxy
09:30 samth: alternatively, would xnest work?
09:30 jeapostrophe_: no because it needs a real server and i have none
09:32 jeapostrophe_: upgrade in progress
09:32 (quit) danbrown: Remote host closed the connection
09:32 samth: you could just try upgrading the x server
09:32 jeapostrophe_: i did "apt-get update" "apt-get upgrade" and it didn't do anything
09:33 samth: right, you need to follow the instructions on that page
09:33 samth: basically, upgrade (for safety) will never remove a package
09:33 jeapostrophe_: i meant when i tried to just update the x server
09:33 samth: you can do 'dist-upgrade', which allows more invasive changes
09:34 jeapostrophe_: that didn't list the server either, just the kernel
09:34 samth: but for the xserver, just do 'apt-get install xserver-blah-blah
09:34 jeapostrophe_: it didn't do anything
09:34 samth: you didn't do anything that changed your sources file
09:35 samth: there are a couple options:
09:35 jeapostrophe_: i have no idea what you're talking about
09:35 samth: 1. change /etc/apt/sources.list manually
09:35 jeapostrophe_: i'm running the update to 10.04
09:35 samth: 2. run the full update to 10.04
09:41 askhader: Are there racket libraries for determining the 'type' of a file? Something equivalent to the Unix 'file' command. I could just write a wrapper around file but wanted to see if there was a better sol'n first.
09:42 samth: askhader, I don't think so
09:42 askhader: Wow, really?
09:42 askhader: I wouldn've thought this was done and put to rest ages ago.
09:43 samth: well, the problem is impossible in general, and `file' does a pretty good job
09:43 jeapostrophe_: what other solution would there be than wrap file?
09:43 askhader: Some bindings to do what file does?
09:44 jeapostrophe_: i wouldn't want to maintain its database
09:44 samth: file is actually pretty compilcated
09:44 jeapostrophe_: better let it do it
09:44 samth: for a demonstration, try 'man 5 magic'
09:44 askhader isn't familiar with how file functions.
09:45 askhader: Ah I see.
09:45 askhader: Yeah I'm perfectly fine with using file- I just like to reduce the amount of system calls.
09:45 samth: sadly there isn't a shared lib that `file(1)' calls, that could be wrapped via the ffi, for just that reason
09:46 (quit) Quetzalcoatl_: Ping timeout: 276 seconds
09:46 askhader: I see
10:01 (quit) RyanRN: Read error: No route to host
10:01 (join) RyanRN
10:13 (quit) pygospa: Disconnected by services
10:13 (join) TheRealPygo
10:14 samth: did the upgrade finish, jeapostrophe>
10:14 samth: ?
10:21 (join) MayDaniel
10:31 (join) hanDerPeder
10:39 (join) vu3rdd
10:58 (join) danbrown
11:02 (quit) MayDaniel: 
11:11 (join) mceier
11:16 (join) hircus
11:17 hircus: hi. is anyone familiar with Racket's Unix-style installation mode?
11:18 samth: hircus, somewhat
11:18 hircus: I'm installing with the intention to package the result as an RPM, and the "raco setup" phase hardcoded the temporary location for the collects directory, i.e. $DESTDIR/usr/lib/racket... rather than /usr/lib/racket...
11:18 hircus: I believe this was a problem since the 4.x days too
11:20 samth: as in, it doesn't work, or there's a hardcoded path that you want to change?
11:21 hircus: problem is that the -X (--collects) argument passed to racket/racket3m has the DESTDIR prepended. I wonder, if I take it out, whether the build still works or not...
11:22 samth: i'm still confused, why is this a problem
11:22 (quit) jeapostrophe_: Quit: jeapostrophe_
11:23 hircus: the paths are embedded in the .zo modules produced, and this is not allowed in Fedora Linux. a) if the paths are not used at runtime then they should not be there, and b) if the paths are used then they will be incorrect
11:24 hircus: here's an example: http://fpaste.org/w0b0/
11:27 hircus: I just checked; not passing $DESTDIR causes the compilation of the collects to fail as they could not find the collects directory
11:28 hircus: so what I'd need is an override: temporarily look up the collects in $DESTDIR/usr/lib/racket but when compiling, pretend that the collects were in /usr/lib/racket, since that's where they'd be on an installed system anyway
11:28 samth: yes, so those paths are embedded at build time, and are i believe necessary for compilation, but do not refer to paths on the runtime machine
11:28 samth: i don't think you need to pretend anything
11:29 hircus: can I clobber them after compilation is finished?
11:29 samth: for example, the distributions we provide from: http://download.racket-lang.org/ have paths embedded in them
11:29 samth: and those paths do not refer to real paths on the machine the binary is installed on
11:30 hircus: right. the Fedora build system is triggered to fail when it sees the buildroot (the DESTDIR) in generated files, though
11:30 samth: can you manually rewrite the zo files? i doubt that's a good idea
11:30 hircus: If I open them in binary format and replace them by a string of the same length, it should be safe, right?
11:31 samth: probably
11:31 samth: you can raise this issue on the mailing list, if you want
11:31 hircus: but shortening the file, on the other hand, would not be safe? is the .zo file format documented somewhere?
11:31 hircus: yeah. probably will
11:32 samth: see http://docs.racket-lang.org/raco/decompile.html for documentation
11:32 samth: but that's not documentation of the on-disk format
11:33 (join) anRch
11:35 samth: the on-disk format changes regularly
11:37 hircus: odd, they end up in in.sxref documentation files too
11:38 samth: the identifiers are identified by the path they're from
11:38 (join) MayDaniel
11:39 hircus: right. where in the code is the identifiers injected into the files? I can perhaps patch that
11:39 samth: no, you really can't
11:39 samth: trust me
11:39 hircus: I trust you know better :)
11:40 samth: the use of paths to represent where identifiers are from is a central concept in the language
11:40 hircus: well if the official word is that that is harmless, I'll just turn off the test
11:40 samth: it's certainly harmless
11:41 hircus: but if I shorten up the path while still leaving them unique (e.g. DESTDIR/a/b/c -> /a/b/c) then the functionality would not be affected, I suppose?
11:41 samth: as i said, when you download a distribution from our site
11:41 hircus: right, those have your buildroots embedded too
11:41 samth: the paths are embedded as well
11:41 hircus: is that the same case with the sxref files? what are they used for?
11:41 samth: the sxref files are cross-references for the documentation
11:41 samth: the docs are indexed by identifier identity
11:42 hircus: aha. so that's why the buildroots pop up there too
11:42 hircus: because the identifiers include them
11:42 samth: yes
11:42 samth: for example, see: http://docs.racket-lang.org/search/index.html?q=+
11:42 samth: note that there are a lot of versions of that
11:44 samth: it might be possible to change the representation to include some token that represents the top of the collects tree
11:44 (nick) offby1` -> offby1
11:44 (quit) offby1: Changing host
11:44 (join) offby1
11:44 samth: but that probably won't work in the presence of multiple elements of PLTCOLLECTS
11:44 hircus: right. fair enough. there's no secret information in the $DESTDIR that we use anyway
11:45 samth: i hope not :)
11:46 samth: jeapostrophe, drdr is taking too long
11:47 samth: hircus, are you taking over the fedora package of racket?
11:47 hircus: I need a phrasing that explains the issue -- does this work? "Racket uses the path to the source file as the unique identifier for the compiled objects it generates. As such it will include the $DESTDIR, but as the path is used only as an identifier and not an actual location on disk, this is harmless"
11:47 samth: that's correct
11:47 hircus: samth: well, or rather, creating one. We've been stalled since PLT 4.0 comes out because the previous maintainer stopped working on it (I'm still trying to figure out what happens to him)
11:48 (join) jonrafkind
11:48 samth: ah
11:48 hircus: is there an IRC log for this channel? so I can refer to this conversation
11:48 samth: hircus, see the topic
11:48 hircus: I believe I tried packaging 4.0 too, but didn't receive a satisfactory explanation for those $DESTDIR occurences so I decided to leave the mater standing at the time
11:48 jonrafkind: clklein, ping
11:48 hircus: aha! thanks
11:49 samth: hircus, biab
11:53 clklein: jonrafkind: pong
11:55 hircus: samth: when you get back, I'm curious -- is Mozilla planning to use Racket, or they just invest in PL research in general? (I know they're developing Rust on the side)
12:20 (quit) jao: Ping timeout: 250 seconds
12:20 (quit) MayDaniel: 
12:31 (quit) b-man_: Remote host closed the connection
12:40 (quit) anRch: Quit: anRch
13:01 (join) Axsuul
13:04 askhader: I'm solving a problem in which I am checking the extension of filenames. I know which filenames I am lookign for in advance. Would it be `faster' to actually test the substrings of the filenames or just use a regular expression?
13:04 askhader: looking*
13:11 hircus: are the extensions fixed length? If not using a regex to split on the . and capture the later group might be simpler
13:14 (quit) vu3rdd: Quit: ERC Version 5.3 (IRC client for Emacs)
13:16 (join) anRch
13:18 askhader: The extensions are fixed length
13:18 askhader: I'll be checking for .flac, .mp3 etc.
13:18 askhader: The thing is that I will have to compute string-length for each filename if I take the substring approach.
13:18 askhader: I don't know if this is slower than a single regular expression match.
13:18 askhader: I think it probably will be.
13:18 hircus: flac is 4 chars, mp3 is 3 chars
13:19 askhader: Oh I see what you mena.
13:19 askhader: yah regexp..
13:19 hircus: and yes, you'd have to take the string length and then find the dot
13:19 askhader: Well not really, just check the last n letters
13:19 askhader: With regards to the dot, I mean
13:20 hircus: ah yes. grab 4 and then check for either "flac" or ".mp3". well, but then what if I give you a file called thisisnotaflac ?
13:20 hircus: regexp will let you avoid all the degenerate corner cases
13:23 jeapostrophe: does anyone know of a formal model of regular expressions with back references?
13:28 (join) Yann3
13:29 (quit) Yann1: Ping timeout: 265 seconds
13:48 (quit) hanDerPeder: Ping timeout: 272 seconds
14:00 (quit) danbrown: Remote host closed the connection
14:04 eli: hircus: ping
14:05 hircus: eli: pong
14:05 eli: hircus: In case you have any issues with packaging, you can just ping me (eli@barzilay.org),
14:05 eli: but in general I think that things should be very easy now --
14:06 eli: There were a nubmer of issues in the past (like the DESTDIR thing), and we've slowly made things be more "normal" in the sense that a usual configure+make build process should work.
14:06 hircus: eli: yup, thanks. I had the same problem I had with 4.0 but Sam explained what those pathnames embedded in compiled modules are actually used for
14:06 eli: Don't even bother with the 4.x builds, just start with the recent one,
14:07 hircus: yap, thanks for that! I'm pleasantly surprised that I can just drop in Fedora's %configure macro there. When compiling Bigloo it fails if certain standard autoconf-like parameters are given that it does not understand
14:07 hircus: oh, I'm not doing 4.x anymore. that was.. last year, I think (I remember asking you some questions about that)
14:07 eli: as for embedded paths in compiled files -- there shouldn't be any hard wired absolute paths, so if you see any, that
14:07 eli: 's a bug.
14:07 samth: hircus, mozilla is not planning to use Racket that I know of
14:07 samth: eli, it's not a bug - it's in the serialization of module-path-indexes
14:08 hircus: I contemplated doing an in-place install and then using the same move function used by the installer script, but then I realized that means I can't use shared libs, so I guess it's better to have those funny paths in the identifiers
14:08 eli: samth: Example file?
14:08 hircus: eli: pretty much any .zo files. but you won't see it unless you do a Unix-style install ; then you can grab for the directory you DESTDIR into
14:09 hircus: s/grab/grep
14:09 eli: Doing a unix-style install -- using our installer -- will basically move the files and change some bits in the executable, but it doesn't change any .zo files.
14:09 samth: eli, download the Racket install sh file, then do 'strings collects/lang/private/compiled/teach-shared_rkt.zo'
14:10 samth: or just do that for your local collects tree, it will have a full embedded path
14:11 eli: You mean the single "/var/tmp/racket/collects/mzlib/private/shared-body.rkt@pairHmid-ellipsesDellipses@bind"?
14:12 (join) jao
14:12 hircus: eli: looks like that, yes
14:12 eli: I still agree with myself then -- that should be considered a bug.
14:13 samth: eli, i'm pretty sure that's not a bug
14:14 eli: It *is* a bug that we get a hard-wired path in the .zo files, since the plt tree should be reolcatable, therefore .zo files should not have such hard-wired paths.
14:14 hircus: would be nice if instead of passing the absolute path to the collects, we can pass the intended install location (that will be used as module identifiers) plus DESTDIR (so that it can use it for compiling)
14:14 hircus: eli: samth informed me that the tree is still relocatable. those "paths" are actually used as unique identifiers
14:14 samth: eli, those zo's are relocatable
14:14 eli: hircus: No, that would just hard-wire a different path -- the real solution should be avoiding it in the first place.
14:15 eli: hircus: That's my guess -- and they're bad identifiers.
14:15 eli: samth: As long as there no clash with another file that happens to be in the same place.
14:15 hircus: just use random strings as identifiers, perhaps? or use the SHA sum of the source files if you want the IDs to be meaningful
14:15 eli: Like I said -- it's a bug.
14:16 eli: Yea, something like that -- or a path that is relativized to the racket root would work too.
14:16 samth: eli, i think the identification of module-path-indexes with filesystem paths is pretty deeply embedded in the code
14:16 eli: That (relative to root) was the usual solution in the other places where this happened.
14:16 samth: but maybe it'll be easy for matthew to change
14:16 eli: samth: That doesn't make it any less of a bug.
14:17 hircus: eli: another smaller bug -- the names used for the shared objects in a Unix-style install. There's an open bug in Fedora's bigloo packaging which is quite similar: ldconfig expects files ending in .so to be symlinks -- the idea is they go into development packages, and point to versioned .so files e.g. libfoo.so -> libfoo.so.1
14:17 hircus: but Racket has lib{,g}racket3m.so -> lib{,g}racket3m-5.0.2.so; that probably should be lib{,g}racket3m.so.5.0.2
14:17 eli: hircus: (got to go, I'll ping you back in about 15 minutes...)
14:18 hircus: eli: ok
14:18 hircus digging to find out where shared libs are given names
14:19 samth: hircus, there shouldn't be any shared libraries
14:20 hircus: samth: there are if you configure with --enable-shared
14:20 samth: you probably shouldn't do that
14:20 hircus: samth: ah. any known problem with it? that's the recommended way on Unix systems (and the README actually mentions it saying Unix admins would recommend that)
14:21 (join) b-man_
14:22 samth: hircus, i'm not entirely positive on what the advantages/disadvantages of --enable-shared are here, but we typically don't use it
14:22 samth: and i
14:22 samth: 've seen problems caused by it
14:23 hircus: well racket+gracket .so files are 14.2 MB in total, so that's the amount of memory saved by each user if they concurrently runs Racket
14:24 hircus: I'll take it under advisement and disable it if there are any problems.
14:24 samth: (a) it turns out, sadly, the users don't run racket concurrently that much :)
14:24 samth: and (b) the gracket .so is going away in the next release
14:24 hircus: but the racket.so file will still be there? hm
14:25 samth: actually, the gracket .so might just become much much smaller
14:25 hircus: ah, it'll just share more code with racket.so then
14:26 samth: as in, from representing 200k additional lines of code to representing 1k
14:26 hircus: another question -- is Racket's copy of gc any different from the standalone gc release? can I reuse the one already in Fedora (version 7.2 alpha 4)
14:27 samth: not sure
14:27 samth: back in a bit
14:27 hircus: ok
14:47 jeapostrophe: hircus: you cannot use an off the shelf boehm gc
14:52 hircus: jeapostrophe: aha, thanks. the bundled one is sufficiently tweaked, then? and how about libffi?
14:53 hircus: I fear that I might have to put Racket in an unofficial Fedora repo for now; we haven't relaxed our guidelines regarding bundled libraries yet (as Ubuntu has, after giving up on compiling Firefox against a stand-alone xulrunner engine)
14:59 (quit) clklein: Read error: Connection reset by peer
15:02 (join) clklein
15:03 jeapostrophe: same with libffi
15:03 jeapostrophe: we tweak it
15:05 (join) danbrown
15:10 (quit) anRch: Quit: anRch
15:10 hircus: jeapostrophe: question: which of the two gc copies are used by default? I see gc which seems to be an older Boehm GC (7.1 instead of 7.2), and gc2
15:11 jeapostrophe: gc2 is programmatically generated during the build using a racket build with gc1
15:11 jeapostrophe: gc2 is normally used, although it is possible to use gc1 if you want
15:11 hircus: ah, ok. I guess I'm looking at a directory *after* I already did a build
15:11 jeapostrophe: they are called 3m (gc2) and cgc (gc)
15:12 jeapostrophe: well gc2 is not generated, but the version of the VM that uses gc2
15:12 jeapostrophe: it is in the xsrc directory after a build
15:12 hircus: ah
15:12 hircus: so -- gc1 is only for bootstrapping?
15:12 jeapostrophe: basically, but you could use it if you wanted
15:13 hircus: ok, good, in which case there's no problem with bundling, Fedora-wise since gc1 is not used by the compiled product
15:13 (quit) Yann3: Ping timeout: 240 seconds
15:13 (join) Yann1
15:14 (join) MayDaniel
15:15 hircus: how about libffi -- the README only says that the change from upstream is to avoid a compiler warning. can I build with the system copy? Fedora has 3.0.9 while racket has 3.0.10rc0 (according to libffi's configure.ac)
15:16 jeapostrophe: i don't know exactly, i know in the past we've changed more but we tend to send the patches back too
15:20 eli: hircus: I doubt that using a system libffi will work -- at least in the past it was awfully lagging behind the source.
15:20 eli: (Probably because it was maintained in some weird way as part of the GCC repo.)
15:21 (quit) danbrown: Remote host closed the connection
15:21 hircus: eli: ok, fair enough. could I request an optional switch for compiling against the system libffi though? in case in the future libffi does get updated
15:21 eli: There's a number of other things in there -- lightening, libunwind, gmp, these are all core functionalities that are anywhere from slightly different to very different from the defaults.
15:22 hircus: eugh. I did not notice gmp yet
15:22 eli: No need to request -- we certainly need to do that, but it seems that libffi is still not nearly popular enough to justofy working on that.
15:24 hircus: and the same with gmp and all the other bundled libs? by all means, do set them to a sane default (e.g. using bundled vs using system lib), but that way at least it'd be easier to test if the system libs are adequate
15:24 hircus: (and push the upstream projects to actually release a version that racket can use out-of-the-box)
15:25 eli: That won't happen with GMP.  Lisps often need things at a core enough level to require more than what a library provides.
15:25 eli: It *might* happen with lightening, though our core hacker was using it on more platforms and needed to fix misc things.
15:26 eli: libunwind is probably even easier, but I'm not sure.
15:26 (join) _ryanc_
15:27 eli: hircus: BTW, you should try to strip the binaries, 14mb sounds way bigger than what it should be.
15:27 eli: I have 2.9m and 4.6m for racket and gracket respectively (and the latter is soon turning to a tiny stub).
15:27 eli: (That's on an x86_64)
15:30 hircus: eli: actually I have 1.8 and 3.1 M -- I was looking at the build tree post-compile but before stripping
15:30 hircus: right. time to go home -- I'll ping you when I have a Yum repository containing a custom build
15:30 hircus: is there a test suite that I can run as part of the build process, for sanity checking?
15:31 eli: Lots of them...
15:31 eli: As a convenient top-level point you can run
15:31 eli: racket on the collects/tests/run-automated-tests.rkt file
15:32 eli: But that might have a bunch of "known errors" that you wouldn't know about.
15:32 hircus: excellent. and I can do this using the same racket binary that was used during 'make install' right?
15:32 eli: Yes.
15:32 hircus: and that is exactly the same binary that will end up installed (i.e. same failure mode)
15:32 eli: (There are no gui tests that this will run.)
15:32 eli: Yes.
15:32 hircus: ok. well I'll just comment out each failing test and check it with you
15:32 hircus: ok, thanks :) got to run
15:32 (quit) hircus: Quit: Leaving.
15:36 (quit) MayDaniel: 
16:09 (quit) mceier: Quit: leaving
16:28 (quit) b-man_: Ping timeout: 260 seconds
16:33 (quit) RyanRN: Remote host closed the connection
16:57 (join) pygospa
16:57 (quit) TheRealPygo: Ping timeout: 240 seconds
17:02 (quit) jonrafkind: Quit: Ex-Chat
17:03 (join) jonrafkind
17:12 (join) danbrown
17:23 (quit) danbrown: Remote host closed the connection
17:25 (join) danbrown
17:56 (quit) jao: Ping timeout: 255 seconds
17:57 (quit) danbrown: Remote host closed the connection
18:02 (join) jao
18:11 (join) danbrown
18:20 (join) Fare
18:21 (join) mceier
18:46 (quit) _ryanc_: Quit: Leaving
18:49 (quit) danbrown: Remote host closed the connection
19:02 (join) jeapostrophe_
19:13 (quit) jeapostrophe_: Quit: jeapostrophe_
19:39 (quit) emma: Ping timeout: 240 seconds
20:22 (join) emma
20:23 (quit) mceier: Quit: leaving
20:36 (join) jeapostrophe_
20:45 askhader: Is there any regular expression construct for match this word or that word, similar to bash's {this,that,other}
20:45 (quit) Yann1: Ping timeout: 276 seconds
20:52 eli: askhader: #rx"(this|that|other)" ?
20:57 (quit) pygospa: Ping timeout: 240 seconds
21:01 (quit) Fare: Quit: Leaving
21:03 (quit) jonrafkind: Ping timeout: 264 seconds
21:03 (join) fmu
21:04 (quit) jeapostrophe_: Quit: jeapostrophe_
21:32 (join) pygospa
21:45 (join) jeapostrophe_
21:49 (quit) jeapostrophe_: Client Quit
21:54 (join) blake_johnson
21:56 (part) blake_johnson
22:14 (join) dvanhorn
22:38 (join) danbrown
22:47 (join) vu3rdd
22:51 (quit) dvanhorn: Quit: Page closed
22:54 (quit) danbrown: Remote host closed the connection
23:32 (join) danbrown