IRC log of dig on 2012-07-03

Timestamps are in UTC.

00:14:12 [scor]
scor has quit (Quit: scor)
00:29:27 [bblfish]
bblfish has quit (Read error: Connection reset by peer)
00:30:02 [bblfish]
bblfish (~bblfish@AAubervilliers-651-1-127-44.w86-198.abo.wanadoo.fr) has joined #dig
01:29:18 [presbrey]
presbrey has quit (Quit: Terminated with extreme prejudice - dircproxy 1.2.0)
01:32:30 [scor]
scor (~scor@c-98-216-97-72.hsd1.ma.comcast.net) has joined #dig
01:32:30 [scor]
scor has quit (Changing host)
01:32:30 [scor]
scor (~scor@drupal.org/user/52142/view) has joined #dig
02:22:13 [presbrey]
presbrey (~presbrey@2001:4830:2446:b5:aede:48ff:fe00:6001) has joined #dig
02:44:19 [bblfish]
bblfish has quit (Read error: Connection reset by peer)
02:44:55 [bblfish]
bblfish (~bblfish@AAubervilliers-651-1-127-44.w86-198.abo.wanadoo.fr) has joined #dig
03:40:05 [scor]
scor has quit (Quit: scor)
05:03:03 [Pipian]
Pipian (~pipian@static-mum-59.181.115.17.mtnl.net.in) has joined #dig
07:12:33 [Pipian_]
Pipian_ (~pipian@static-mum-59.181.115.17.mtnl.net.in) has joined #dig
07:12:33 [Pipian]
Pipian has quit (Read error: Connection reset by peer)
07:12:34 [Pipian_]
Pipian_ is now known as Pipian
07:15:01 [melvster]
melvster (~melvin@p5797F363.dip.t-dialin.net) has joined #dig
07:32:43 [rszeno]
rszeno (~rszeno@79.114.102.131) has joined #dig
07:37:19 [melvster]
melvster has quit (Remote host closed the connection)
07:37:48 [melvster]
melvster (~melvin@p5797F363.dip.t-dialin.net) has joined #dig
07:58:12 [deiu]
deiu (~andrei@unaffiliated/deiu) has joined #dig
09:10:45 [presbrey]
presbrey has quit (Ping timeout: 240 seconds)
09:10:52 [betehess]
betehess has quit (Ping timeout: 245 seconds)
09:11:17 [betehess]
betehess (~betehess@2001:470:8b2d:804:1d4e:3963:99ee:e9d3) has joined #dig
09:12:29 [presbrey]
presbrey (~presbrey@2001:4830:2446:b5:aede:48ff:fe00:6001) has joined #dig
10:14:49 [cheater__]
cheater__ has quit (Ping timeout: 246 seconds)
10:28:16 [cheater__]
cheater__ (~cheater@g230227254.adsl.alicedsl.de) has joined #dig
10:32:52 [Pipian]
Pipian has quit (Ping timeout: 248 seconds)
10:48:00 [Pipian]
Pipian (~pipian@static-mum-59.181.115.17.mtnl.net.in) has joined #dig
10:48:00 [Pipian]
Pipian has quit (Client Quit)
11:19:41 [trueg]
trueg (~trueg@dslb-094-217-041-120.pools.arcor-ip.net) has joined #dig
11:22:14 [RalphS]
RalphS (Ralph@w3cdhcp61.w3.org) has joined #dig
11:46:43 [melvster1]
melvster1 (~melvin@p4FF96E37.dip.t-dialin.net) has joined #dig
11:48:06 [melvster]
melvster has quit (Ping timeout: 264 seconds)
12:53:47 [t4nk286]
t4nk286 (a103012a@gateway/web/freenode/ip.161.3.1.42) has joined #dig
12:55:08 [bblfish]
hi
12:56:38 [t4nk286]
hi, i have a question about rdflib.js.
12:56:48 [t4nk286]
t4nk286 has quit (Client Quit)
12:57:11 [rblin]
rblin (a103012a@gateway/web/freenode/ip.161.3.1.42) has joined #dig
12:57:28 [rblin]
is it possible in rdflib to fetch remote graphs in parallel?
12:57:37 [rblin]
what method do I call?
13:00:11 [bblfish]
rblin, I think presbrey or melvster1 are those who know most about this lib. Perhaps it is also worth asking that question on github as a bug report
13:00:43 [bblfish]
with explanation of where you are seeing the problem
13:00:52 [RalphS]
RalphS has quit (Ping timeout: 265 seconds)
13:01:26 [RalphS]
RalphS (Ralph@30-7-118.wireless.csail.mit.edu) has joined #dig
13:04:13 [rblin]
I try to make a loop on all foaf knows of one foaf profile but when i want to check if all foaf:knows are loading i have only the last foaf knows loaded.
13:05:42 [bblfish]
what method are you calling?
13:07:59 [rblin]
fetch.nowOrWhenFetched()
13:09:23 [bblfish]
did you check with Wireshark if the connections were being made?
13:10:00 [bblfish]
I am not sure if rdflib can do fetches in parallel, or more than one at a time, or if one needs to create different fetch objects....
13:11:51 [rblin]
yes I check it with wireshark and when i want to load 5 foaf at the same time i have 5 HTTP GET in my wireshark console
13:12:18 [bblfish]
those GETs are going on in parallel?
13:13:55 [rblin]
GETs are launch successivly in a loop.
13:15:05 [bblfish]
so you do something like for (url <- friends) { fetch.nowOrWhenFetched( function() { do something with result } ) }
13:15:07 [bblfish]
?
13:15:35 [bblfish]
(can't remember the exact method calls)
13:15:57 [bblfish]
perhaps fetch(url).nowOrWhenFetched(...)
13:17:00 [rblin]
yes
13:18:24 [bblfish]
and you see wireshark downloading these in parallel?
13:20:00 [rblin]
yes :)
13:22:35 [bblfish]
ok, so I think then it's your client code that is overwriting the graphs perhaps, or that is now able to use the information
13:22:51 [bblfish]
I would create a hashmap URL=>Graph for each downloaded graph
13:41:46 [bblfish]
there are a lot of good examples at https://github.com/linkeddata/rdflib.js/blob/master/test/
13:42:09 [bblfish]
but it is true that some good documentation would be helpful, to know what methods are available on a graph
13:42:12 [bblfish]
graph.size?
13:43:03 [rblin]
no
13:48:00 [scor]
scor (~scor@w0107748.mgh.harvard.edu) has joined #dig
13:48:00 [scor]
scor has quit (Changing host)
13:48:00 [scor]
scor (~scor@drupal.org/user/52142/view) has joined #dig
13:48:30 [amy]
amy (~amy@30-6-207.wireless.csail.mit.edu) has joined #dig
13:51:10 [bblfish]
there must be a way to iterate through the graph in the mean time, so you can find out its size.... perhaps graph.length
14:25:51 [bblfish_]
bblfish_ (~bblfish@ALagny-551-1-140-22.w92-141.abo.wanadoo.fr) has joined #dig
14:27:24 [bblfish]
bblfish has quit (Ping timeout: 250 seconds)
14:58:28 [deiu]
bblfish_, are you going to start the teleconf yourself?
14:59:31 [bblfish]
bblfish (~bblfish@AAubervilliers-651-1-127-44.w86-198.abo.wanadoo.fr) has joined #dig
15:02:11 [bblfish_]
bblfish_ has quit (Ping timeout: 246 seconds)
15:29:35 [rblin]
rblin has quit (Ping timeout: 245 seconds)
16:20:27 [danbri]
danbri has quit (Remote host closed the connection)
16:25:16 [danbri]
danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) has joined #dig
16:34:52 [danbri_]
danbri_ (~danbri@cable-146-255-150-74.dynamic.telemach.ba) has joined #dig
16:35:35 [danbri__]
danbri__ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) has joined #dig
16:38:39 [danbri]
danbri has quit (Ping timeout: 244 seconds)
16:39:41 [danbri_]
danbri_ has quit (Ping timeout: 244 seconds)
16:45:04 [trueg]
trueg is now known as trueg_away
16:48:30 [trueg_away]
trueg_away is now known as trueg
17:12:14 [deiu]
deiu has quit (Ping timeout: 244 seconds)
17:21:51 [trueg]
trueg is now known as trueg_away
18:31:54 [betehess_]
betehess_ (~betehess@31-35-216.wireless.csail.mit.edu) has joined #dig
18:32:41 [betehess_]
betehess_ has quit (Client Quit)
18:38:00 [timbl]
timbl (~timbl@93-62-235-11.ip24.fastwebnet.it) has joined #dig
19:22:23 [timbl]
timbl has quit (Quit: timbl)
19:28:28 [melvster]
melvster (~melvin@p4FF96242.dip.t-dialin.net) has joined #dig
19:29:57 [melvster1]
melvster1 has quit (Ping timeout: 265 seconds)
19:50:13 [manu1]
manu1 has quit (Ping timeout: 246 seconds)
20:01:07 [bblfish]
bertails, hi!
20:01:58 [bblfish]
from time to time we should sync up so we know where we are going :-) betehess
20:04:56 [manu1]
manu1 (~chatzilla@pool-96-240-166-105.ronkva.east.verizon.net) has joined #dig
20:07:51 [danbri]
danbri (~danbri@cable-146-255-150-74.dynamic.telemach.ba) has joined #dig
20:09:49 [danbri__]
danbri__ has quit (Ping timeout: 246 seconds)
20:19:55 [RalphS]
RalphS has quit ()
20:32:14 [kennyluck]
kennyluck has quit (Ping timeout: 246 seconds)
20:41:09 [kennyluck]
kennyluck (~kennyluck@114-43-117-27.dynamic.hinet.net) has joined #dig
20:47:11 [trueg_away]
trueg_away is now known as trueg
20:48:42 [trueg]
trueg has quit ()
20:55:44 [danbri]
danbri has quit (Remote host closed the connection)
21:06:43 [bblfish]
$35000 WebID challenge http://www.healthdata.gov/blog/platform-challenge-1-simplified-sign
21:09:00 [betehess]
bblfish: there is no need for a default graph
21:09:58 [bblfish]
where do you put the information that links a graph to its metadata?
21:10:06 [betehess]
wherever you want
21:10:15 [bblfish]
well why not call that the default graph
21:10:25 [betehess]
because it does not make sense
21:10:30 [betehess]
for example
21:10:49 [betehess]
I see where you're going, so let me explain that
21:11:38 [betehess]
case 1: everything is on the file system. every graph is in its own file on the disk, let's say base-dir/foo/bar/baz.ttl
21:12:10 [betehess]
the server can follow this convention: the metadata is available at base-dir/foo/bar/baz.meta.ttl
21:12:13 [betehess]
done
21:12:18 [betehess]
now case 2
21:12:32 [betehess]
everything is in an rdf store
21:12:54 [betehess]
solution 1: you do the same as in case one, but with the rdf store
21:13:25 [betehess]
solution 2: you use one mega graph to hold all the metadata, and you call it something like "ldp:my-default-graph"
21:13:36 [betehess]
which is not meant to be exposed by the LDP server
21:13:48 [betehess]
again, it's an implementation detail
21:14:48 [betehess]
the client only knows that if it wants to "know more" about the graph that it is GETting, it just needs to follow the Link header
21:15:02 [bblfish]
how do you get the list of all graphs in teh store currently?
21:15:17 [bblfish]
I think that's part of the AP'I I suppose
21:15:21 [betehess]
why do you need it?
21:15:46 [bblfish]
Well maintenance of graphs, know how much memory I am using, things like that
21:16:23 [betehess]
so you want to centralize the data somewhere
21:16:37 [betehess]
think about that: does Apache needs to know that?
21:16:47 [betehess]
still, it can serve files
21:16:51 [betehess]
that's the same
21:17:03 [bblfish]
who is using the graphstore api?
21:17:35 [bblfish]
that agent would want to know these things...
21:18:01 [bblfish]
I just think there is an interpretation of default graphs where it makes sense
21:18:09 [betehess]
ok, let me comment there
21:18:26 [bblfish]
( the union of all graphs certainly is stupid )
21:18:45 [betehess]
first of all, do you agree that you could choose whatever graph to hold this kind of information?
21:18:57 [betehess]
instead of the default one?
21:19:34 [betehess]
then, what you want is a way to answer questions like: how many graph do I have
21:19:38 [bblfish]
the problem with any graph, is that then you have a problem finding out which one it is
21:19:46 [bblfish]
you are asking the store to know its name
21:20:03 [betehess]
sesame and jena offers that in their api, so you should not have to maintain it yourself
21:20:07 [bblfish]
it's like I should be albe to talk to you even when you don't remember your name :-)
21:20:17 [betehess]
also, think about a purely file-based implementation, like Apache
21:20:32 [bblfish]
apache has metadata too: it's the file system
21:20:35 [betehess]
having centralized data for that would make it more difficult to scale on different server
21:20:43 [bblfish]
and apache has config files
21:20:58 [bblfish]
I don't see why you call it centralised
21:21:08 [betehess]
guess what, when you access the file system, you iterate over all the files to get the information. there is a cost
21:21:13 [betehess]
that's explicit
21:21:22 [betehess]
there is no centralized index
21:21:30 [betehess]
which is very important
21:21:48 [bblfish]
but the data store itself knows a lot about its contents, no?
21:21:59 [betehess]
not necesseraly
21:22:10 [bblfish]
well it should know what contents it has
21:22:12 [betehess]
only if you add this constraint in the api
21:22:19 [betehess]
depends
21:22:44 [betehess]
making that mandatory in the main interface would be a huge mistake
21:22:57 [betehess]
you could impose another typeclass for it
21:23:10 [betehess]
but even that, I'm not sure that you really need it
21:23:27 [betehess]
at least, don't impose yourself to have to maintain this kind of metadata
21:23:30 [bblfish]
you can always create a named graph as you say to put that info
21:23:41 [betehess]
but you'll have to maintain it
21:23:47 [betehess]
in a very centralized way
21:24:00 [bblfish]
but I think on startup an amin needs to be able to ask queries even when the admin does not know what graph is the name of the default graph
21:24:03 [betehess]
or, you may want to get something that iterates over the existing graphs
21:24:27 [bblfish]
the way you are doing things you are going to make the admin's job debend on knweldge of an external resource. You can't bootstrap the thing
21:24:29 [betehess]
don't understand your last comment
21:24:38 [betehess]
of course you can
21:24:51 [betehess]
you tell the admin to "RTFM"
21:25:09 [bblfish]
but each implemetnation is going to place the default graph elsewhere
21:25:23 [bblfish]
it's like .
21:25:26 [bblfish]
in the file system
21:25:31 [betehess]
so what? you don't expose this information anyway
21:25:39 [betehess]
it's server specific
21:25:51 [bblfish]
yes, the server admin also needs to get going
21:25:52 [betehess]
Apache does not tell you on what filesystem it's running
21:26:06 [betehess]
sure, but that's implementation specific
21:26:08 [bblfish]
but you know which file you start off looking for config info
21:26:22 [bblfish]
default graph is just an indexical
21:26:28 [betehess]
config is something totally different from the current discussion
21:26:38 [bblfish]
it says give me the metadat store of the store
21:26:47 [bblfish]
even if I don't know what it is named
21:26:48 [betehess]
that's *your* interpretation
21:26:50 [betehess]
your convention
21:27:00 [bblfish]
yes, what is wrong with it?
21:27:05 [betehess]
people may have other plans for their default graph
21:27:14 [betehess]
because you don't have to impose it
21:27:21 [betehess]
that's just wrong and useless in this case
21:27:36 [betehess]
it will never be exposed by LDP
21:28:21 [betehess]
if you want to write a server that provides to the sysadmin this kind of information, why not, but you need to be aware of the implications
21:28:43 [bblfish]
well I think we'll probably find out by using it
21:28:51 [betehess]
IMO, making that efficient though metadata that you would maintain is just plainly wrong
21:29:40 [betehess]
try to think how you would do that 1. without centralized index 2. with a pure filesystem-based implementation
21:30:20 [bblfish]
yes, ... I'll see how it works in practice. But I have a feeling that you may need the index. But I can't tell for sure.
21:30:27 [betehess]
and tell the sysadmin to do "man du", like with apache
21:30:29 [bblfish]
As I say even in the file system you have the . notation
21:31:01 [betehess]
if there is an index, we won't scale, and we'll actually make the administration more complicated
21:31:15 [betehess]
think about why Apache is so loved by sysadmins...
21:31:59 [betehess]
I don't understand re: in the file system you have the . notation
21:32:32 [bblfish]
well I am thinking of the default graph as an indexical for the metadata
21:32:58 [betehess]
so everytime someone is accessing the store, you need to block on the default graph to update it?????
21:32:59 [bblfish]
Also the other thing I am looking at is how this compares to N3 which has a main graph that cotnains graphs
21:33:18 [bblfish]
ah ok
21:33:25 [bblfish]
that's what you mean
21:33:36 [betehess]
that's just a consequence
21:34:00 [betehess]
and I know that you don't like the word "block"
21:34:01 [betehess]
:-)
21:34:10 [bblfish]
well we have a lot of blocking things in there
21:34:17 [bblfish]
we should really rewrite all of it
21:34:23 [betehess]
like what?
21:34:34 [bblfish]
is sesame and jena not blocking?
21:34:44 [bblfish]
the parsers are blocking mostly
21:34:47 [betehess]
in the current naive implementation, maybe, but not in the future
21:34:53 [bblfish]
:-)
21:35:04 [betehess]
the interface is fine re: store
21:35:08 [bblfish]
ok. Still do you think that
21:35:23 [bblfish]
null.instanceOf[URI] is really a good idea?
21:35:26 [betehess]
no
21:35:41 [betehess]
if we *have to*, it would be store.getDefaultGraph()
21:35:45 [bblfish]
ah ok
21:35:48 [betehess]
but as we won't do it, don't worry
21:36:09 [bblfish]
well Pat Hayes presentation is quite interesting btw
21:36:15 [betehess]
I know
21:36:26 [bblfish]
anyway... I am writing a CORS proxy right now
21:36:33 [betehess]
but that's not that relevant until Pat changes everything in RDF and SPARQL
21:36:56 [bblfish]
was my checking ok?
21:37:03 [betehess]
checking?
21:37:08 [bblfish]
check-in
21:37:13 [betehess]
the last one?
21:37:17 [betehess]
I hope so :-)
21:37:36 [bblfish]
ah ok, so you have had no problems yet
21:37:44 [betehess]
I've been working on a RecordBinder
21:37:47 [betehess]
not ready yet
21:37:55 [bblfish]
the Sesame issue is odd because I added some simple tests and those work
21:37:56 [betehess]
I've not synchronized yet
21:38:14 [bblfish]
what was the library you metnioned for doiong closing of sockets?
21:39:16 [bblfish]
last week, when you looked at Sesame
21:39:19 [betehess]
hrmmm
21:39:28 [betehess]
scala-arm I believe
21:39:40 [betehess]
from Josh Suerueth
21:39:54 [bblfish]
ah found the notes
21:40:16 [bblfish]
yes http://jsuereth.com/scala-arm/usage.html
21:40:35 [bblfish]
I think un-jon was thinking or asking about transactions
21:40:56 [bblfish]
thinking abut implementing transactions with his monadic contexts
21:41:37 [betehess]
why not
21:41:47 [betehess]
I'm waiting for a demonstration of the value
21:42:07 [betehess]
also, if we support only one context, this would be useless
21:42:08 [bblfish]
ok. Good, if monadic contexts help transactions then that seems like it would add value
21:42:22 [betehess]
maybe
21:42:33 [bblfish]
all to be seen
21:42:58 [bblfish]
I find it more useful to start with real world problems and then to move to change stuff
21:42:58 [betehess]
monads would make explicit the fact that we only need the sequence
21:43:37 [bblfish]
I was thinking in discussion with un-jon that perhaps
21:43:44 [bblfish]
the graph object should be
21:43:46 [bblfish]
mutable
21:43:56 [bblfish]
or rather there should be mutable and immutable
21:44:02 [bblfish]
like in scala collections
21:44:19 [betehess]
that would be ok
21:44:20 [bblfish]
( just an idea ). The reason being that sesaem and jena are mutable
21:44:24 [betehess]
yes
21:44:34 [betehess]
that would be fine
21:44:38 [bblfish]
of course a good implemetnation would use non-mutable data structures
21:44:44 [bblfish]
ah ok good :-)
21:44:45 [betehess]
yes
21:44:57 [betehess]
well, as long as you don't mess with the types, it's fine
21:45:27 [betehess]
also, make sure that you make defensive copies when going from mutable to immutable
21:45:39 [bblfish]
For the moment I don't need it. But I can see that one could. It would be nice to have real immutable graphs that don't do a whole copy (ie are efficeint)
21:45:41 [betehess]
same the other way actually...
21:45:53 [betehess]
well, we need it with Diesel
21:46:08 [betehess]
diesel is O(n**2) because of that
21:46:13 [bblfish]
ah ok.
21:46:28 [betehess]
as it uses graph union
21:46:30 [bblfish]
+1 then for that
21:46:54 [bblfish]
Ok. run out of ideas I think
21:46:55 [betehess]
well, it works for now, so let's wait until we have real performance issue
21:47:19 [bblfish]
yes I should present myself on the Linked Data Platform working group soon
21:47:23 [betehess]
"n" is never big with Diesel
21:47:39 [betehess]
can you join it through the Apache Foundation?
21:47:46 [bblfish]
I am already in
21:47:48 [betehess]
k
21:47:53 [bblfish]
just have not had time to say hello
21:48:06 [bblfish]
WG means I'll have to do some work
21:48:46 [bblfish]
should have CORS working soon, and the RWW should be going too.
21:49:22 [bblfish]
well thanks for the feedback :-)
21:50:09 [bblfish]
DIGlogger: pointer?
21:50:09 [bblfish]
See http://dig.csail.mit.edu/irc/dig/2012-07-03#T21-50-09
21:50:53 [betehess]
sure
21:50:54 [bblfish]
we need to get this working for Lyon in October
21:50:58 [betehess]
yes
21:51:02 [bblfish]
:-)
21:51:03 [betehess]
I should be there btw
21:51:31 [bblfish]
oh and for Chaos Communication Congress in december, with Tor
21:51:49 [betehess]
hrmmm, now I need to do a foldLeft on a HList #shapeless
21:52:07 [bblfish]
un-jon showed how one could do webid over Tor competitor i2p
21:52:17 [betehess]
wow, nice
21:52:17 [bblfish]
well linked data over i2p
21:52:27 [betehess]
that is nice
21:52:37 [betehess]
can't wait to see
21:52:40 [bblfish]
one could have linked data over i2p and tor and normal web. That would be really cool :-)
21:53:14 [betehess]
does he have some writings about that already?
21:53:47 [bblfish]
he just got i2p working on his computer published a foaf file in the .i2p url
21:54:21 [bblfish]
you have things like
21:54:38 [bblfish]
http://sdfsdfsdfsdf.onion/betehess/foaf.n3
21:54:55 [bblfish]
or http://ssdfsdfsdfs.i2p/bblfish/foaf.rdf
21:55:14 [betehess]
as the webid?
21:55:16 [bblfish]
sdss... are cryptokeys that identify the machine in a distributed has table
21:55:20 [bblfish]
yes
21:55:22 [betehess]
oh
21:55:24 [betehess]
I see
21:55:31 [bblfish]
well with #me at the end or soemthing
21:55:47 [bblfish]
so you can do linked data over those
21:55:52 [betehess]
but this is not considered as anonymous, isn't it?
21:55:53 [bblfish]
then you can do tls auth over them too
21:56:20 [bblfish]
well if you wanted to be clever you'd of course not put such an obvious url
21:56:35 [betehess]
you could even have one-time webid
21:56:40 [bblfish]
not /bethess/foaf.n3 but perhaps /btls/#me
21:56:59 [betehess]
k
21:57:01 [bblfish]
the important thing about these networks is that people don't know where your machine is
21:57:16 [bblfish]
so they don't know where you are
21:57:37 [bblfish]
and you could just show people who don't know you a public key
21:57:45 [bblfish]
and to your friends have a link to a full profile
21:58:04 [bblfish]
plus you don't need TLS server auth
21:58:16 [bblfish]
because the server is dientified cryptographically
21:58:18 [betehess]
that sounds wonderful
21:58:37 [bblfish]
yes, just need to try it out to see hwo it works out :-)
22:03:25 [scor]
scor has quit (Quit: scor)
22:30:05 [danbri]
danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) has joined #dig
22:33:40 [danbri]
danbri has quit (Remote host closed the connection)
22:53:20 [melvster]
melvster has quit (Ping timeout: 252 seconds)
23:09:49 [bblfish]
bblfish has quit (Read error: Connection reset by peer)
23:10:25 [bblfish]
bblfish (~bblfish@AAubervilliers-651-1-127-44.w86-198.abo.wanadoo.fr) has joined #dig
23:20:49 [amy]
amy has left #dig