--- Log opened Wed Dec 29 00:00:02 2010
00:00 -!- ymasory [~ymasory@adsl-2-40-178.mia.bellsouth.net] has quit [Read error:
Connection reset by peer]
00:01 < adg> Eko: it's much slower to update two maps than to just use a
RWMutex
00:01 < adg> Eko: almost 4x slower (i just tried it)
00:06 < Eko> lame.  Oh well, was a thought.
00:07 * Eko still likes having a coroutine managing his data and asking it nicely
for things.
00:15 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
00:15 -!- joatmon54 [~engest@cpe-66-74-195-46.san.res.rr.com] has joined #go-nuts
00:34 -!- Davidian1024 [~Davidian1@173.88.174.84] has quit [Ping timeout: 272
seconds]
00:34 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has joined
#go-nuts
00:34 -!- DarthShrine [~angus@pdpc/supporter/student/DarthShrine] has quit [Remote
host closed the connection]
00:35 -!- itrekkie [~itrekkie@ip72-211-155-116.tc.ph.cox.net] has quit [Quit:
itrekkie]
00:55 -!- ios_ [~ios@180.191.43.195] has quit [Quit: Leaving]
01:01 -!- ios_ [~ios@180.191.94.28] has joined #go-nuts
01:07 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has quit
[Ping timeout: 240 seconds]
01:07 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has joined
#go-nuts
01:16 -!- shvntr [~shvntr@116.26.134.123] has joined #go-nuts
01:21 -!- niemeyer_ [~niemeyer@200-203-59-56.pltce701.dsl.brasiltelecom.net.br]
has joined #go-nuts
01:24 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts
01:31 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Quit: WeeChat
0.3.2]
01:31 < Eko> man, writing a server to RFC specs is tedious.  I'm so used to
writing IRC bots that play fast and loose with anything they can fudge.
01:38 -!- reiddraper [~reid@c-68-33-177-129.hsd1.md.comcast.net] has joined
#go-nuts
01:38 -!- reiddraper [~reid@c-68-33-177-129.hsd1.md.comcast.net] has quit [Client
Quit]
01:38 -!- reiddraper [~reid@c-68-33-177-129.hsd1.md.comcast.net] has joined
#go-nuts
01:40 < reiddraper> if I get a copy of a file desriptor from a TCPListener
object through .File().Fd(), what do I have to do to it to make it usable when
passed into syscall.ForkExec?  My goal is for the exec'd process to have access to
this file descriptor
01:43 -!- bamccaig [~bamccaig@unaffiliated/bamccaig] has joined #go-nuts
01:59 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts
02:07 -!- wrtp [~rog@drynoch.demon.co.uk] has quit [Quit: wrtp]
02:10 -!- Sh4pe [~Sh4pe@p5083CC4E.dip.t-dialin.net] has joined #go-nuts
02:10 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has quit
[Ping timeout: 276 seconds]
02:11 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has joined
#go-nuts
02:12 -!- Sh4pe [~Sh4pe@p5083CC4E.dip.t-dialin.net] has quit [Client Quit]
02:18 -!- Boney [~paul@124-148-146-189.dyn.iinet.net.au] has quit [Read error:
Connection reset by peer]
02:19 -!- Boney [~paul@124-168-78-137.dyn.iinet.net.au] has joined #go-nuts
02:20 < Eko> reiddraper: unless the FD is explicitly set close-on-exec, it
should still be open
02:20 < Eko> I don't know if the runtime does that or not.
02:20 < reiddraper> the copied fd doesn't have close-on-exec set, or so i
believe from reading docs
02:21 < reiddraper> one thing I just changed, was from using
syscall.ForkExec to os.ForkExec, so now I can at least see std* output from my
child process
02:22 < Eko> forkexec looks like it has semantics of creating file
descriptors for you...  so you may have to pass the FIle object as the proper
index of the fd array to forkexec
02:22 < reiddraper> so in the fd list, i pass in stdin, stdout, stderr and
my open socket connection.  do you know how I access that fourth (socket) fd from
my new program?
02:23 < reiddraper> Eko: yes, I pass in stdin, out, err as the first the
indices
02:24 < Eko> reiddraper: check out the source for syscall.forkExec
02:24 < Eko> it has a comment that indicates that FDs are set close-on-exec
02:24 < Eko> "Acquire the fork lock so that no other threads create new fds
that are not yet close-on-exec before we fork."
02:24 < reiddraper> Eko: read that, but i don't think it sets close-on-exec
for the ones you explicitly pass in are close-on-exec
02:26 -!- Boney [~paul@124-168-78-137.dyn.iinet.net.au] has quit [Ping timeout:
260 seconds]
02:26 < reiddraper> from exec_unix.go "By convention, we don't close-on-exec
the fds we are started with"
02:27 -!- Boney [~paul@124-148-166-171.dyn.iinet.net.au] has joined #go-nuts
02:27 < Eko> reiddraper: forkAndExecInChild, see halfway down,
RawSyscall(SYS_FCNTL, uintptr(nextfd), F_SETFD, FD_CLOEXEC)
02:27 < Eko> that looks like it goes through the FD array, makes a new FD,
sets it CLOEXEC, and then adds it to the new process, no?
02:29 * Eko only understands some of what's going on, so he could easily be
misinterpreting.
02:31 < reiddraper> Eko: my understanding if shaky too.  the way i'm reading
it now, it dups the fd's, then calls close_exec on the originals...?
02:32 < Eko> hmmm.  That sounds sensible.
02:32 < Eko> does hg have a blame command, you can look up who wrote it ^_^
02:33 < reiddraper> Eko: it does, good idea
02:33 < reiddraper> So, there must be some way for the exec'd process to
have at these files, or you wouldn't pass them in in the first place
02:34 < reiddraper> so assuming that for a moment, do you know how a process
gets at the fd's it was started with?
02:34 -!- boscop [~boscop@f050128034.adsl.alicedsl.de] has quit [Ping timeout: 240
seconds]
02:35 < Eko> reiddraper: yeah, os.NewFile(..., #, ...)
02:35 < Eko> lol, surprise, it's gri and rsc who wrote that code.
02:36 < reiddraper> :)
02:37 < Eko> so you'd have to do something like TcpFile :=
os.NewFile(oldfdno, "/dev/null") maybe?
02:37 < reiddraper> so, let me know if this sounds rational.  my logic for
getting a tcplistener on a port will go something like.  try to listen on port, if
EADDRESSINUSE, then use the file from os.NewFile?
02:38 < Eko> sounds reasonable
02:38 < Eko> how do you trick a TCPListener into using your *File?
02:39 < reiddraper> excellent question
02:39 < Eko> hehe.
02:39 < reiddraper> perhaps I can have my code only rely on the net.Listener
interface
02:40 < reiddraper> so the listener can be contsructed with syscalls from
the fd, or normally with tcplistener
02:40 < Eko> if I were you, I'd patch in a new function that makes a
TCPListener (and probably all of the others) from an FD number
02:41 < Eko> I can imagine that, for a system language, the need to do what
you're doing will come up often enough to justify it.
02:41 < reiddraper> Eko: that certainly sounds reasonable
02:42 < Eko> if you look at the ListenTCP function, it looks like it would
be really easy to make a ListenTCPFd() that basically just takes out some lines.
02:42 < Eko> (I suck at naming functions though, so thats probably a
terrible name)
02:42 < reiddraper> yeah.  Go has been an interesting experience coming from
python where I could just monkey path things however i like
02:43 < reiddraper> to switch out the fd
02:43 < reiddraper> but it certainly feels more elegant in Go, most of the
time anyway
02:43 < Eko> yeah; I'm writing an IRC server, and I'm finding that so much
of it is really elegant and still blindingly fast
02:44 -!- niemeyer_ [~niemeyer@200-203-59-56.pltce701.dsl.brasiltelecom.net.br]
has quit [Ping timeout: 246 seconds]
02:44 < reiddraper> yeah, the speed has been quite impressive, i'm writing
an http server and it's quite a bit faster than I could possibly need
02:45 < Eko> at times I've had 300 clients each connecting and joining 20
channels, and it was able to do it all in under 30 seconds...  and when you add it
up, that's something like 30,000 messages being sent per second...  and that's
without any real optimization on my part
02:46 < reiddraper> damn, that is fast
02:46 < Namegduf> I got mine to sync 20,000 remote clients in 20 channels
each in 12-14 seconds, 6-7 if I disable the client subsystem.
02:47 < Namegduf> The slow part is iterating the huge channels (they get up
to ~950 users) for sending join messages
02:47 < Eko> yep.
02:47 < Namegduf> Which is why disabling the client subsystem makes it so
much faster.
02:47 < Namegduf> However!
02:47 < Namegduf> TS6 does not work that way.
02:47 < Eko> I know!
02:47 < Eko> <3 TS6
02:47 < Namegduf> It sends all the joins for a single channel together, as
opposed to for a single user or one at a time.
02:47 < Namegduf> Likely for that very reason.
02:47 < Eko> NJOIN <TS> <client> ....
02:47 < Eko> or something similar
02:47 < Namegduf> It's even better considering that upping it to 100k users,
*80%* of the time is in that iteration.
02:48 < Namegduf> (I forget exactly how long it is...  long.)
02:48 < Eko> Namegduf: how are you testing it with so many users?
02:48 < Eko> my system won't even let me set a maxfd higher than 12280
02:48 < Namegduf> "remote clients"
02:48 < Eko> oh, right, yours are internal
02:48 < Namegduf> As in, ones added by a linking module
02:49 < Namegduf> Yeah.
02:49 < Eko> maybe I should do that =/
02:49 < reiddraper> Eko: gotta run, thanks for your help
02:49 < Eko> reiddraper: no problem, hope I helped a bit.  have fun!
02:49 < reiddraper> Eko: certainly did
02:49 -!- reiddraper [~reid@c-68-33-177-129.hsd1.md.comcast.net] has quit [Quit:
reiddraper]
02:49 < Namegduf> I suggest so.
02:49 < Namegduf> Local and remote clients are both important metrics.
02:50 < Namegduf> Remote determines absolute limits on the size of the
network it'll work on, even as services, and so is where I was focusing most of my
attention (also, I was more interested in improving performance of the core at the
time), but local is obviously important in not needing 100 servers to get there.
02:52 < Eko> once I get through the RFC (I'm going through it with a
fine-toothed comb and making sure I have everything as close as I want it), I'll
see if I can add pseudoclients to the server itself that don't require TCP
connections.
02:53 * Eko wonders if he can use io.Pipe
02:54 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Ping timeout: 240
seconds]
02:55 < Namegduf> I'm focusing more on compatibility than RFC compliance.
So much in there is bad.
02:55 < Namegduf> +p is stupid, +i is stupid (should be always on), +k is
silly with account-based join systems...
02:55 < Eko> Namegduf: well, on my first pass I was "let's get something
that is vaguely usable" now it's "make sure I didn't miss stuff"
02:55 < Namegduf> Oh, yeah
02:56 < Namegduf> UTF-8 nicks are awesome too.
02:56 < Eko> for instance, I didn't have user modes or OPER implemented
until yesterday
02:56 < Namegduf> Mine doesn't and won't implement OPER
02:56 < Namegduf> It opers on login to an account
02:56 < Namegduf> Tying oper access with the account system
02:56 < Eko> definitely doable with services
02:57 < Namegduf> It has a command to login to an account and a hookable
account auth system which will eventually permit login to accounts from
configuration.
02:57 < Eko> all you have to do is add services and remove O:lines though,
and any IRC server can be that way.
02:57 < Namegduf> (Right now, modules/dev/testaccount just adds a test
account)
02:57 < Namegduf> Actually, no, they can't, not with existing Services and
IRCds.
02:57 < Eko> +o can't be propagated remotely?
02:57 < Namegduf> SNOTICES are completely inaccessible and most services
packages do not fully duplicate IRCd oper commands.
02:58 < Eko> oh, I meant with a services that meant to do that
02:58 < Eko> instead of the other way around
02:59 < Eko> when our servers get closer to functional (read: TS6) we should
see if they can link.
02:59 < Eko> yours is probably closer than mine =/
03:00 < Namegduf> That'd be interesting.
03:01 < Eko> it'd probably give us a better idea of the chances of them
linking with an existing TS6 server, and it'd be a lot more informative than just
blindly trying it on one.
03:01 < Namegduf> Maybe.  I'm planning on trying mine with a real one every
so often just to see how far it gets through the burst.
03:02 < Eko> I have one configured on my server, but it's mothballed,
probably until I get out to cali.
03:02 < Eko> depending on how desperately I need a linux box to test this,
though, it may come out of hiding.
03:03 -!- Wiz126 [~Wiz@24.229.245.72.res-cmts.sm.ptd.net] has quit []
03:04 < Eko> so, question about your interpretation of the RFC: does an
INVITE allow you to join irrespective of all modes including +i, +l, +b, and +k?
That's always been the way I interpreted it, but I don't know how it's done in
practice.
03:04 < Namegduf> In practice, it depends.
03:05 < Namegduf> I believe traditionally it only overrides +i but nicer
IRCDs override all.  Mine takes the latter stance.
03:05 < Namegduf> Well, I say nicer.
03:05 < Namegduf> "some" have it override all.
03:05 < Eko> lol.
03:05 < Eko> mine is currently overriding all
03:06 < Namegduf> Actually, mine overrides nothing right now, but the plan
is for it to override everything "below oper level"
03:06 < Namegduf> Or at least equal to or less than op level.
03:06 < Eko> because for instance, you may want to invite (and +v) someone
who's banned on probation
03:06 < Eko> or invite someone because it's easier than telling them the
+key
03:06 < Namegduf> Or invite over an ISP ban
03:07 < Namegduf> Which would otherwise require an exception
03:07 < Eko> or invite someone who got disconnected and their limit spot was
filled, but who was actively participating, etc.
03:07 < Namegduf> Hmm, I don't think I implement +l
03:07 < Namegduf> I don't know if I will, I'm not sure I see a legitimate
usecase which isn't best solved properly
03:08 < Eko> it's used on networks to prevent botnets, typically set at 500
or 1000
03:08 < Rennex> hmm, you guys are writing ircds?
03:08 < Namegduf> In Go, yes.
03:08 < Eko> Rennex: yep.
03:08 < Namegduf> Eko: Joinflooding can be tackled using an actual joinflood
prevention feature, though
03:09 < Rennex> either one doing redundant server-to-server connections?-)
because frankly that's the only reason i'd consider writing a new ircd ;)
03:09 < Eko> Rennex: it's my third foray into IRCd writing, one was in C and
was unsuccessful, one was extending an existing IRCd to the then-new TS6, and this
one is in GO, and is far easier and faster.
03:09 < Namegduf> One of the design goals of mine is that it could do that,
along with most anything else.
03:09 < Eko> ditto.
03:09 < Eko> especially with TS6.
03:09 < Namegduf> Not the first design goal, though.
03:10 < Namegduf> Minimal goal: You can now write Services in Go.
03:10 < Eko> theoreticaly with TS6 you just send messages everywhere, and
they stop bouncing when they run up against older/same time stamps.
03:10 < Eko> wheeee
03:10 -!- sauerbraten_ [~sauerbrat@p508CFE24.dip.t-dialin.net] has joined #go-nuts
03:10 < Namegduf> TS6 does not do redundant; redundant relies on
implementing reliable delivery
03:10 < KBme> Eko: it's weird, on ngircd it returns an error
03:11 < Rennex> that's good.  channels splitting in half because of
netsplits is so 80s
03:11 < KBme> ERR_NOSUCHNICK
03:11 < Eko> Namegduf: the botnet prevention is separate from join flooding.
They idle, and new ones connect when a new bot joins the net
03:12 < Eko> KBme: what does?
03:12 < Namegduf> Eko: Channel join flodod prevention.
03:13 < Eko> why was I thinking that when we implemented TS6 in shadow that
it allowed multilinking...
03:13 * Eko is now curious.
03:14 -!- sauerbraten [~sauerbrat@p508CEBAD.dip.t-dialin.net] has quit [Ping
timeout: 240 seconds]
03:14 < KBme> Eko: PRIVMSG nick1,nick2
03:15 < Namegduf> That is standard and implemented on every IRCD I've ever
used.
03:15 < Namegduf> I suspect ngircd may just be a specifically limited
example there.
03:15 < Eko> KBme: it's been in the RFC since 1459 and there is no reason
not to do it...
03:16 < vsmatck> I have a function which may return two different types of
errors.  A network connection error, and a marshaling error.  I'm trying to think
of how to return these different errors because the user will need to take
different actions depending on the type of error.
03:16 < Eko> it also works theoretically with PRIVMSG
#channel,user,#channel,nonexistent
03:16 < vsmatck> Like should I return two separate errors.  Or make a new
type which conforms to os.Error?
03:16 < Eko> vsmatck: if they both implement os.Error, then you're good
03:16 < Eko> vsmatck: and then they can use a type switch if checking which
one will help them
03:17 < vsmatck> I don't want to have to rely on string comparison to know
if the error is a connection error or not.
03:17 < vsmatck> Hm. So maybe I should have two types which conform to
os.Error.  Like connErr and marshalError?
03:17 < Eko> vsmatck: yep.
03:17 < vsmatck> I don't like the idea of doing a type switch.
03:18 < vsmatck> It's for an API.  Trying to figure out the best way, or if
there's an existing idiomatic way.
03:18 < Eko> that's the idiomatic way.
03:18 < KBme> so just add one int to the structure, where you have an error
code
03:18 < KBme> it can still be an os.Error
03:18 < Eko> (but you'd need to type assert if you returned it as an
os.Error)
03:19 < vsmatck> I figure if I did add an int I'd return the new type I made
and not os.Error.
03:19 < KBme> ah yea
03:19 < vsmatck> ya I think that way would be best.
03:19 < Eko> vsmatck: type ConnectionError string; type MarshallError
string; then you can return ConnectionError("error message here")
03:19 < vsmatck> Hm. I just don't think it'd be good to require the user to
do a type switch to figure out the type of error.
03:19 < Namegduf> Type switches are perfectly safe if you have a good
default: that actually works.
03:19 < Eko> and, assuming you define the String() methods, you can either
let the client treat it as an os.Error (checking for null and printing) or usign a
switch err.(type) {...} to handle both
03:20 < Eko> vsmatck: they can also do it as type assertions if they want
03:20 < Eko> if _,connbad := err.(ConnectionError); connbad { do something
to fix the connection }
03:21 < vsmatck> ah, I didn't think of using the if thing.  I was thinking I
had to use the switch statement.
03:21 < Eko> it's simple, it's clear to read, and it's lightning fast in
terms of implementation (no string comparisons).  It's probably only a few
instructions shorter than doing an int comparison, because that's more or less
what it's doing
03:21 < vsmatck> That actually seems pretty good too.
03:21 < Eko> longer than*
03:22 < Namegduf> Type switches/assertions are not "lightning fast".
03:22 < Namegduf> Just a note there.
03:22 -!- _dx [~e@173.246.194.131] has quit [Quit: .]
03:22 < Eko> Namegduf: oh no?
03:22 < Namegduf> String comparisons are actually usually very fast because
if the length differs it's a simple integer comparison
03:23 < vsmatck> I think string comparisons make code brittle.
03:23 < Namegduf> Eko: Not sure how slow, but I know there's some overhead.
03:23 < vsmatck> Hm. I like Eko's way.  But I want to understand this
overhead.  *reads docs*
03:23 < Namegduf> I don't know how type lookups and comparisons work
exactly.
03:24 < Namegduf> I think the itable contains a pointer to the type?
03:24 < vsmatck> Hopefully it's not on the level of C++ dynamic_cast.  If
it's really minor I'll use it.
03:24 < exch> hmm.  a while ago I was a bit miffed at why google's website
passes along invalid html 5.  Most notably incomplete tags.  I just learned this
is been done on purpose to reduce the amount of data being sent over the wire, but
because it relies on sstandardized fallback rendering for HTML 5, the omitted tags
are carefully chosen to still have the page rendered accurately across all targets
03:24 < Namegduf> I'd use it.
03:25 < Namegduf> I'm just commenting on the "lighting fast" thing
03:25 < vsmatck> Are we talking about regular lightning, or greased
lightning here?
03:25 < Namegduf> Use it because it's idiomatic and you don't need blazing
speed at the expense of maintainability everywhere (if you were, you'd be using
assembly or C...)
03:25 < Namegduf> :P
03:26 < Eko> Namegduf:
http://research.swtch.com/2009/12/go-data-structures-interfaces.html
03:26 < vsmatck> Namegduf: ah, I agree.  This is an API to do database I/O
too.  Definetly not CPU performance sensitive.
03:26 < Eko> you'll probably be pleasantly surprised by how little overhead
there is.
03:26 < vsmatck> Thanks Eko!  Thanks Namegduf!  :)
03:26 -!- soapy_illusions [~alex@bas1-montreal50-1279440699.dsl.bell.ca] has
joined #go-nuts
03:27 < vsmatck> ah good blog post *reads*
03:27 < soapy_illusions> hey everyone, I am trying to append to a slice and
it is then throwing out of bound errors, can anyone help
03:27 < Namegduf> Eko: Two pointer derefs assuming type comparison itself is
just an integer comparison, compared to an integer comparison in the common/best
case and a quick iteration down a single block of memory plus a single deref...
03:28 -!- sauerbraten_ [~sauerbrat@p508CFE24.dip.t-dialin.net] has quit [Remote
host closed the connection]
03:28 < vsmatck> soapy_illusions: Does it look like this?  mySlice =
append(mySlice, otherSlice)
03:28 < Namegduf> I think the string comparison would usually win; at the
least I wouldn't describe its speed as an advantage.
03:29 < Eko> Namegduf: do go strings store the length and use that in
comparisons?
03:29 < Namegduf> Yes.
03:29 < Eko> if so, then in a one-to-one equality check, the inequality case
is much faster for a string
03:29 < Namegduf> Go strings are a length and a pointer to a block of memory
03:29 < Eko> but the equality check could potentially be much slower
03:30 < soapy_illusions> vsmatck, haha really sorry man it was a stupid typo
on my part I was doing foo = append(foo, foo)
03:30 < Namegduf> Hmm, true, but derefencing being really really slow in the
worst case...
03:30 < soapy_illusions> vsmatck, my bad
03:30 < Eko> and then if you're talking about a type switch vs.  a string
switch, the type switch will be MUCH MUCH faster in almost any nontrivial case
03:30 < vsmatck> soapy_illusions: sall good.  Glad you got it figured out.
03:31 < Eko> and a dereference is probably not that slow with the size of
CPU caches these days and the relatively small sizes that a compiled program has
03:31 < Namegduf> Eko: I unno.  Hopefully not.
03:31 < Namegduf> It depends.
03:32 < Namegduf> I wonder if anyone's looked at the effect of goroutines on
cache.
03:32 -!- reiddraper [~reid@pool-173-67-26-197.bltmmd.fios.verizon.net] has joined
#go-nuts
03:32 < Eko> if they're anything like threads, they kill them dead
03:32 < Eko> I can only hope they're not *that* bad.
03:32 < Namegduf> Yeah, because the idiom is to use a lot of them.
03:33 < vsmatck> I imagine it'd hurt performance.  However it seems to me
that goroutines really help design better I/O code.
03:33 < vsmatck> But then..  if we all start having 32 CPUs it may not be
that bad.
03:33 < Eko> lol
03:33 < Eko> vsmatck: but the transferring of shared data between 32 (or,
more likely, 8) caches is bad
03:34 < Eko> currently some classes of programs do worse with multiple CPUs
than with a single one.
03:34 < vsmatck> Queues are bad for sharing performance also.
03:34 < Namegduf> Eko: How do you do buffering?
03:34 < Eko> Namegduf: buffering?
03:34 < Namegduf> On client I/O
03:35 < vsmatck> In highly threaded programs queues are generally empty or
full.  The FIFO requirement creates extra sharing requirements.
03:35 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has quit
[Ping timeout: 240 seconds]
03:35 < vsmatck> I watched a really good presentation on this recently.
*finds*
03:35 < Eko> right now I only buffer output, and I have a 100-string buffer
on the output write channel
03:35 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has joined
#go-nuts
03:35 < Namegduf> Hmm, interesting.
03:36 < Namegduf> You use a bufio to read lines at once from the client?
03:36 < Eko> I will eventually want to buffer input similarly, as right now
I'm relying on the operating system to not lose any data if the input buffer gets
too big
03:36 < Eko> Namegduf: one line at a time, yeah
03:36 -!- cw [~cw@parsec.stupidest.org] has quit [Read error: Connection reset by
peer]
03:36 < Namegduf> I use a dirty trick where I have a byte array written to
by one goroutine at the same time another is reading from it
03:36 < Eko> :O
03:36 < Eko> that does sound like a dirty trick
03:37 < vsmatck> Thought this presentation was interesting.
http://www.infoq.com/presentations/LMAX
03:37 < Namegduf> It works because the writing goroutine only ever appends.
03:37 < vsmatck> They argue against queues for consumer/producer in systems
where FIFO is not a requirement.
03:38 < Eko> Namegduf: so it keeps getting bigger forever?
03:39 < Namegduf> No; the output goroutine becomes the writer (it used to
send a message to an actual writer goroutine to do it, now it just acquires a
mutex) and then shrinks it, whenever a write complets
03:39 < Namegduf> *completes
03:39 < Eko> interesting.
03:39 < Eko> I'd be curious to see a direct comparison of raw socket IO
throughput both ways.
03:40 < Namegduf> If it ever successfully writes everything, it terminates
in there.
03:40 < Namegduf> If writes aren't blocking for long enough to cause write
timeouts, the server doesn't have a buffer or communication and just writes
directly.
03:41 < Namegduf> The problem is that joining a 1000 user channel causes me
to flood off now, heh.
03:41 < Eko> ?
03:41 < Namegduf> NAMES.
03:42 < Eko> if it just keeps appending, how does that kill anything?
03:42 < Namegduf> It has a cap.
03:42 < Eko> ah.
03:42 < Eko> that's the nice part about buffered channels
03:42 < Namegduf> That'd be Bad.
03:42 < Eko> any write after it's full blocks.
03:42 < Namegduf> A single slow client could even *deliberately* sabotage
the server that way.
03:42 < Eko> yeah, I'm not happy with my LIST implementation
03:43 < Namegduf> I'm thinking of trying to get behaviour like yours there.
03:43 < Eko> if there are a lot of channels, you could theoretically spam
LIST and eat up the server goroutine time
03:43 < Eko> so I made it another coroutine
03:44 < Eko> but now there's the question of what happens if the server data
changes while it's sending you your LIST.
03:44 < Eko> (or if you quit)
03:45 < Eko> oh, computing in the real world, how you make us idealists sad.
03:46 < Namegduf> If you're using a map?
03:46 < Namegduf> I think you might segfault
03:46 < Namegduf> Apparantly.
03:47 < Eko> oh, I'll definitely segfault if the user quits
03:47 < Namegduf> Ouch.
03:47 < Namegduf> Mine just drops writes if the user is terminating.
03:47 < Eko> but I might or might not segfault if a channel drops.
03:47 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts
03:48 < Eko> Namegduf: well, the problem is that it already has a pointer to
your Channel structure, but the server can be disposing of you while it's sending
03:48 < Namegduf> GC should protect against that?
03:48 < Eko> true
03:48 < Eko> I guess i don't mean segfault, but it would keep sending on the
channel after it's closed
03:49 < Eko> which will eventually panic you.
03:49 < Namegduf> Yeah, that requires some trickery.
03:49 < Eko> and I don't really want to have to stick a recover in there,
though that's actually probably the best solution.
03:49 < Eko> because blocking the server while it sends all of the channels
is NOT an option.
03:51 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Quit: Leaving]
03:53 -!- soapy_illusions [~alex@bas1-montreal50-1279440699.dsl.bell.ca] has quit
[Quit: Leaving]
03:54 < Eko> am I the only one who uses map[X]bool as a set?  sometimes I
feel bad about it, but I do it anyway....
03:54 < Namegduf> I used to, but the reason that set existed was bad.
03:54 < Namegduf> And I got rid of it.
03:55 < Eko> I use it a lot.
03:55 < vsmatck> I miss std::set<T>.
03:55 < Eko> channels maintain a set of users
03:55 < Eko> users maintain a set of channels, too, actually.
03:55 < Namegduf> I use a two-dimensional linked list like some IRCDs but
such a map would probably perform better.
03:56 < Eko> 2D linked list?
03:56 < Namegduf> ...except that it'd involve reads using synchronisation,
which takes away the performance gain.
03:56 < Namegduf> Yeah.  Membership struct which is in two linked lists.
03:57 < Namegduf> Prev user, next user (in channel list), next channel, prev
channel (in user list)
03:57 < Eko> the channels are linked between the first user who joined the
channel or what?
03:58 < |Craig|> When I don't care about order or fast membership testing in
sets, I use this:
https://github.com/Craig-Macomber/Grains--Vegetarian-Zombie-Rising/blob/master/Server/iterBag.got
its an unrolled linked list or sorts
03:58 < Eko> if the first user leaves, the last and next are updated to
point to the subsequent user who joined
03:58 < Eko> and if the channel vanishes they point to each other?
03:58 < Eko> kinda slick, actually.
03:59 < Namegduf> Yeah.
03:59 < Namegduf> |Craig|: Fast membership testing is required
03:59 < Eko> yeah, that's why I went with map[*Client]bool and
map[*Channel]bool
03:59 < Namegduf> Well, actually, it's only required if it can't otherwise
detect duplicate adds.
04:00 < Eko> fast inserts, fast membership checking, fast removes, and it's
only accessed from one place, so I haven't seen a reason to change it.
04:01 < Eko> the probable problem with it is that the GC probably doesn't
resize maps to be smaller when elements are removed.
04:01 < Eko> so a channel that gets huge will always stay huge in memory.
04:02 < Eko> though in practice, most huge channels probably stay huge
anyway, so it might be a minimal point.
04:03 < vsmatck> Hm. I have no idea how map memory is managed.  If the value
is not a pointer would the GC even be used?
04:03 < Eko> wheee, I think all I have left is to implement KICK.
04:03 < Eko> vsmatck: yeah, I have no idea.
04:04 < Eko> when I implemented a hash table, I resized when I got over a
certain % fill, but I never resized down again...
04:04 < vsmatck> hey..  I bet this is the reason maps are value only now
that I think about it.
04:04 < vsmatck> You can't get a pointer to a map value.
04:04 < Eko> mmmm
04:04 < Eko> interesting
04:05 < Namegduf> Eko: My server doesn't distinguish between a PART and a
KICK internally except in source.
04:05 < vsmatck> This is pure speculation here.
04:05 < Namegduf> If you kick yourself it turns into a part.  :D
04:05 < Eko> lol.
04:05 < Namegduf> The commands both translate to the same call into the core
04:05 < Eko> interesting.
04:05 < Eko> mine probably will too.
04:05 < Namegduf> It just has a source field.
04:05 < Namegduf> Same user is a part, different user or nil
(server-sourced) is a kick
04:06 < Eko> srv.Event <- &SEPart{cli, reason, channel, sync}
04:06 < Namegduf> Delete is similar
04:06 < Namegduf> So a self-kill would turn into a quit
04:06 < Eko> lol
04:06 < fuzzybyte> why go has built-in map, but not list?
04:06 < Eko> fuzzybyte: slices?
04:06 < Namegduf> The specific performance characteristics of a list are
rarely needed.
04:06 < Namegduf> Slices are generally the right tool.
04:07 < Namegduf> The central reason I don't use one is that I need fast
random remove from the middle.
04:07 < Eko> which is surprisingly rare in programming.
04:07 < Namegduf> Yeah.
04:07 < Namegduf> Lists are also really easy to implement yourself if you DO
need one.
04:08 < fuzzybyte> there is already container/list and container/ring for
circular list
04:08 < Eko> container/list has one.
04:08 < Eko> but if you don't like interface{} you might as well roll your
own with whatever specific needs you have.
04:08 < Namegduf> Besides, a single one wouldn't do.
04:09 < Namegduf> Do you need it single-linked, do you need it
double-linked...
04:09 < Eko> do you need it to be a skip-list?  a double-skip list?
04:09 < Namegduf> Do you need it to be sorted or not?
04:09 < Eko> lol.
04:09 < Namegduf> A skip list would be nice.
04:09 < Namegduf> Not sure if it'd be worth it...
04:10 < Eko> I hadn't seen a skip list in years and had to code one on a
whiteboard for one of my google interviews.
04:10 < Eko> it was fun.
04:10 < Namegduf> Neat.
04:10 < Eko> I love learning while I'm interviewing.
04:10 < Eko> distracts nicely from the pressure of impressing them.
04:11 < Namegduf> Beats being asked to solve bizarre lateral thinking
problems involving hats, boats, and people whose actions are constrained in the
most curious ways.
04:12 < Eko> lol
04:12 < vsmatck> "write function that returns 1 with a probability of
1/(2^n)".  That's what screened me out.
04:12 < Eko> does that have to do with knowing what color hat you're
wearing?
04:12 < Namegduf> I remember that one.
04:12 < Namegduf> Not from an interview, though, I just heard about it
somewhere.
04:13 < Eko> I heard it as the blue eyes logic problem (also not in an
interview)
04:13 < Eko> took me a month to reason out
04:13 < Eko> but it was soooo satisfying when I did.
04:13 < Eko> http://xkcd.com/blue_eyes.html
04:13 < Namegduf> Yeah, I saw that one.
04:16 < Eko> once I figured it out, it was like, another week or two before
I thought to check the solution, because I had proven to myself that it was
correct.
04:16 < Eko> I love logic.  Which is probably why I love programming.
04:17 -!- reiddraper [~reid@pool-173-67-26-197.bltmmd.fios.verizon.net] has quit
[Quit: reiddraper]
04:21 -!- Tv1 [~tv@cpe-76-168-227-45.socal.res.rr.com] has joined #go-nuts
04:25 -!- beachbum [~darenw@174-28-166-22.albq.qwest.net] has joined #go-nuts
04:30 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 276 seconds]
04:30 < Eko> Namegduf: what're your thoughts on KICK
<user1>,<user2> <channel1>,<channel2> :<reason>
04:31 < Namegduf> Neat.
04:32 < Eko> er, I switched channels and users
04:32 < Eko> but is that useful?
04:32 < nsf> hahaha, I heard this logic puzzle about blue eyes
04:32 < nsf> but in russian versions the guy who knows his eye color kills
himself
04:32 < nsf> instead of leaving the island :D
04:32 < nsf> version*
04:33 < Eko> nsf: I made damn sure nobody told me the answer because I love
figuring them out myself, and ROFL.
04:33 < Eko> I guess knowing you've got blue eyes is just such a burden
04:34 < nsf> no, the puzzle says they have some kind of religion that
forbids the self eye color knowing
04:34 < Eko> lol
04:35 < Eko> so being perfect logicians would certainly be a burden
04:35 < nsf> yeah :)
04:35 < Eko> anyone else would live a happy life not knowing that they could
reason out their own eye color.
04:35 -!- reiddraper [~reid@pool-173-67-26-197.bltmmd.fios.verizon.net] has joined
#go-nuts
04:36 -!- keithgcascio [~keithcasc@nat/google/x-hndyaujouapfxsuc] has quit [Quit:
Leaving]
04:41 < nsf> although I don't like that puzzle
04:42 < Eko> now, what would be REALLY funny would be to take 201 people and
put them on a real island and impose those rules.
04:43 < nsf> they would say: "dude, wtf, who cares about eye color, we need
food"
04:43 < Eko> (the ones about getting off the island, not offing yourself,
when you know your eye color lol)
04:43 < Eko> ah, but if they say anything you shoot them and replace them.
04:43 < nsf> :D
04:43 < Eko> no communication on this island, remember?
04:44 < nsf> island of death
04:44 < Eko> except for the one sentence that the Guru says once.
04:44 < nsf> you know what's the most funniest part
04:44 < nsf> what about guys with brown eyes
04:44 < Eko> they're screwed
04:44 < nsf> like they will never leave the island
04:44 < nsf> :D
04:44 < Eko> yep.
04:45 < Eko> unless the guru says "I see someone with brown eyes" after the
blue eyed folks are gone
04:45 < Eko> but then the guru would be left all alone
04:45 < nsf> hehe, they will still stay
04:45 < Eko> (at which point he/she finds a mirror and gets off the island)
04:46 < TheSeeker> The 'obvious' answer that comes to mind for me is
"everyone else had died of old age when the guru spoke, so only 2 were left on the
island" but that seems to contradict the rules of the challenge :)
04:46 < nsf> if 100 guys with brown eyes know that someone has brown eyes it
gives them nothing
04:46 < Eko> lol.
04:46 < Eko> nsf: nope, they would leave too
04:46 < nsf> nope
04:47 < Eko> nsf: do you know the answer?  because it works either way
(don't say in channel, others might want to think more about it)
04:47 < nsf> because everyone would think: "ok, I see 99 brown eyed people,
maybe my eye color is different"
04:47 < nsf> yes, I know the answer :)
04:48 < Eko> then you'd know that the same logic applies ^_^
04:49 < nsf> it's not
04:49 < nsf> :\
04:49 < Eko> #blueeyes
04:49 < Eko> so we don't spoil it.
04:51 < nsf> :(
04:51 * nsf fails
04:52 < Eko> it took me a month to figure it out, lol
04:52 < TheSeeker> here, have a battle of wits instead.
http://www.youtube.com/watch?v=eQNHBUqfLnM
04:53 < nsf> I've googled for the answer :\
04:53 < nsf> but I heard this puzzle before
04:53 < nsf> and wasn't able to figure it out
04:54 -!- foocraft [~dsc@78.100.220.119] has quit [Ping timeout: 240 seconds]
04:54 < nsf> http://www.brain-fun.com/Brain-Teasers/EinsteinsRiddle.php
04:54 < nsf> I liked this one more
04:54 < nsf> and solved it on my own
04:56 < fuzzybyte> nsf: what do you think of adding a "detail" attribute to
candidates gocode autocompletio, that is, a snippet from the beginning of the code
where the referenced candidate is defined?  the library im using to implement
autocompletion has an option for this, but now there isn't any use for it.  I've
seen many eclipse plugins do this too.  not sure if it's worth the trouble, tough.
04:56 -!- reiddraper [~reid@pool-173-67-26-197.bltmmd.fios.verizon.net] has quit
[Quit: reiddraper]
04:56 < nsf> I don't think it's a good idea
04:57 < nsf> but if you disagree the source code is here, hack it..  maybe
I'll change my mind
04:57 < Eko> I use it in eclipse occasionally to check if the function I'm
calling is checking the variables or not and various other cursory things
04:57 < fuzzybyte> :) i don't think it's worth my time.  not now, at least.
04:58 < fuzzybyte> actually i find it little annoying when there's a huge
yellow box filling the screen in eclipse.
04:58 < nsf> fuzzybyte: well, gocode does everything I want, so it isn't
worth my time for sure
04:59 < fuzzybyte> just throwing ideas :)
05:00 < Eko> fuzzybyte: the newer ones, if memory serves, show it only when
you hover over the yellow box or if you click further down the list with arrows
05:00 < Eko> *and hit leftarrow
05:15 -!- xash [~xash@d025211.adsl.hansenet.de] has quit [Ping timeout: 250
seconds]
05:17 < fuzzybyte> one thing i'd be interested in developing is to get
auto-indentation support, but i don't know how to make it work so that it doesn't
get confused over brackets inside comments, strings, etc.
05:18 < fuzzybyte> eclipse is so good at that
05:22 -!- araujo [~araujo@190.38.51.34] has joined #go-nuts
05:23 -!- araujo [~araujo@190.38.51.34] has quit [Changing host]
05:23 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts
05:25 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Ping timeout: 265
seconds]
05:30 < adg> hey folks
05:30 < adg> i have some binary releases if anyone's game to try 'em
05:30 < adg>
http://code.google.com/p/go/downloads/list?deleted=1&ts=1293600001
05:30 < adg> http://code.google.com/p/go/downloads/list (rather)
05:31 < adg> i'm particularly interested to hear people's experience with
the linux binaries
05:32 < tdnrad_> neato
05:33 < tdnrad_> might have to give those a shot in the new year
05:33 < tdnrad_> things are quite busy until I get that out of the way
05:42 -!- vasu_ [~vasu@202.63.112.184] has joined #go-nuts
05:53 -!- niekie [~niek@CAcert/Assurer/niekie] has quit [Ping timeout: 260
seconds]
05:57 -!- niekie [~niek@CAcert/Assurer/niekie] has joined #go-nuts
05:57 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts
06:02 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Client Quit]
06:07 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts
06:08 -!- bnjmn [~bnjmn@siegel.dreamhost.com] has left #go-nuts []
06:09 < nsf> adg: trying them now..  although, I don't understand why do you
include .hg dir to the archive
06:09 < nsf> looks like "linux 386" works
06:09 < nsf> compiled gocode, tested it, gofmt works too
06:10 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Quit: Leaving]
06:11 < nsf> cgo works
06:13 < nsf> trying "linux amd64"...  it will take more time (on qemu)
06:14 < adg> nsf: thank you very much
06:15 < adg> nsf: .hg directory is included so people can upgrade / send CLs
/ etc easily
06:15 < adg> and what's 20mb between friends?
06:15 < nsf> i see
06:15 < adg> i'll drop the .hg part once we've been going a little while
06:16 < nsf> binary releases are nice
06:17 < nsf> compiling Go on qemu takes 20-40 minutes
06:17 < nsf> downloading and unpacking is faster
06:17 < adg> yikes
06:18 < nsf> I've noticed that default GOROOT is /usr/local/go
06:18 < adg> yes
06:18 < nsf> you should mention that somewhere I guess later
06:19 < adg> cat $GOROOT/README
06:19 < adg> under 'Binary Distribution Notes'
06:19 < nsf> ah, I see
06:19 < nsf> nice
06:21 < |Craig|> is there a binary release of GccGo?
06:22 < nsf> indeed that would be even more useful
06:22 < Eko> gc all the way!  >:-)
06:22 < nsf> because gccgo takes 30-60 minutes on a regular machine :D
06:22 < Eko> :-o
06:22 < Eko> what, is it generating a whole new toolchain?
06:22 < nsf> maybe, yes
06:22 < nsf> well, at least 10 minutes
06:22 < Eko> dayum.
06:23 < nsf> without bootstrap
06:23 < nsf> I thin
06:23 < nsf> k
06:23 < |Craig|> I tried to build gccgo, and failed
06:24 -!- JBeshir [~namegduf@eu.beshir.org] has joined #go-nuts
06:24 -!- JBeshir [~namegduf@eu.beshir.org] has quit [Client Quit]
06:24 < Eko> so, opinions: what should IRC opers be able to do on a standard
sized IRC network (maybe 3-5 servers, 2000-10000 users, 800-1500 channels)
06:24 < Eko> KILL, K:LINE, CLEARCHAN, OPME?
06:24 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts
06:24 < nsf> ban everyone
06:24 < nsf> :P
06:24 < Namegduf> Opinions differ greatly
06:25 < Namegduf> This is one area where required functionality differs
significantly based on scenario.
06:25 < |Craig|> Eko: the only non gigantic irc network I've used had less
than 100 users peak, and maybe 5 or 6 channels
06:25 < Eko> yeah.
06:26 < |Craig|> I think the most common networks are tiny, it really
depends on what you mean by standard sized
06:26 < Namegduf> He did define it.
06:26 < nsf> adg: "linux amd64" works too..  tested building and executing
gocode, gofmt, cgo (termbox library)
06:26 < Namegduf> That's actually a fairly big size, but interestignly tends
to be the focus of attention.
06:26 < Eko> My intent was then to ask about what the differences would be
between that and "small" (anything smaller) and "big" (anything bigger) than that.
06:27 < Namegduf> One philosophy could adequately be described as "the EFnet
philosophy".  Admins should have no power to do anything but ban users from the
network.
06:27 < Eko> I have actually been on five or six networks as I described, in
addition to DAL, EF, and FreeNode.
06:27 < Eko> but I could be weird.
06:28 < Namegduf> If stuff breaks at the channel level too bad- or at least
its Services job to fix.
06:28 < Namegduf> *it's
06:28 < Eko> that's probably the best way to do it at the level I described.
06:28 < Eko> and anything larger.
06:28 < Namegduf> It's fairly common on large networks and scales well if
your staff is either very small or very lazy.
06:28 < Namegduf> Frees you from the need to grow staff with user count.  :P
06:29 < Eko> so, for a small network (<3 servers, <1000 users, no
services, <100 channels), what would be reasonable for an OPER?
06:29 < Eko> I assume by "no services" that a lot of the more popular
channels will be run by bots.
06:29 < Namegduf> No services?
06:29 < Namegduf> That is a weird network you describe
06:30 < Namegduf> "Install Services" is what would be reasonable
06:30 < Eko> Namegduf: that was the setup for my favorite network of all
time, alas it is dead.
06:30 < Namegduf> I don't think networks without Services are a reasonable
usecase to consider effectiveness of stuff in
06:30 < Namegduf> Because the premise indicates that they aren't designing
it for optimal performance in any usecase
06:31 < Namegduf> Aside possibly "induce nostalgia".
06:31 < Eko> Namegduf: and you would be correct; however, it is reasonable
to assume that there are SOME circumstances in which operators should have some
sort of power, and I would like to know what powers they may need to have, so I
chose that one ;-)
06:31 < Namegduf> Well, I would say "capability to freely view and
manipulate state".
06:31 < Eko> (also, I've seen a services outage that took a week to fix)
06:32 < Namegduf> Is the direct opposite of the "EFnet philosophy"
06:32 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3]
06:32 < Namegduf> If an IRC server is a service, then the admins are the
people maintaining it; would you deny a DBA access to SQL on the grounds that they
"shouldn't interfere with the application's data"?
06:33 * Eko can't tell which side Namegduf is arguing sometimes ;-)
06:33 < Namegduf> Small networks I've seen either use something leaning
towards the same as larger or else simply have all the powers they need to resolve
any conceivable kind of issue, with no real focus on "restricting" administrators.
06:34 < Eko> so, what subset of power is the simplest that gives you the
ability to solve any concievable kind of issue with the minimum of effort?
06:34 < Namegduf> Hmm.
06:34 < Eko> KILL, K:LINE, CLEARCHAN, OPME?
06:35 < Namegduf> That will work but some of the solutions can be
suboptimal.
06:35 < Namegduf> You have no IRCD-side mechanism to deal with channel
takeovers- Services can help there.
06:35 < Eko> CLEAROPS is another that I've thought about
06:35 < Namegduf> Aside nuking a channel from outside.
06:36 < Eko> OJOIN?
06:36 < Eko> then you can talk it over nicely, OPME and fix it or just
CLEARCHAN if it's irreparable?
06:36 < Namegduf> That's a good option.
06:37 < Eko> so then the question is, do you make opers use OJOIN or just
let them always join channels regardless of mode
06:37 < Namegduf> Former.
06:37 < Eko> and send a WALLOPS, of course.
06:37 < Namegduf> Opers use their connections for things other than opering.
06:38 < Namegduf> They should always have to deliberately choose to invoke
their capabilities.
06:38 < Eko> I was on a server once that would -o you after a certain amount
of time
06:38 < Eko> though I don't think that should be a default by any means.
06:38 < Eko> good philosophy.
06:39 < Eko> also, should OPME remove all other chanops?  otherwise, a
fast-fingered takeover bot can deop you.
06:39 < Eko> or would you then flip a coin and KILL it or CLEARCHAN
06:39 < Namegduf> Hard to say.
06:40 < Eko> I am imperceptably leaning toward removing other chanops,
because if you're using OPME you really should only be doing it because the
operators aren't cooperating
06:40 < Namegduf> Oh, yes.
06:41 < Namegduf> Capability to view secret channels.
06:41 < Eko> lol, good call.
06:41 < Namegduf> How you do that differs a lot between things.
06:41 < Eko> yeah.
06:41 < Namegduf> If you provide IRCD-side ignore mechanisms, you also may
or may not want the ability to override it.
06:41 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Quit:
Leaving.]
06:42 < Namegduf> Not relevant if you don't, of course.
06:42 < Eko> I haven't done so yet
06:42 < Namegduf> PM whitelisting at least is popular.
06:43 < Eko> knock has always seemed kinda weird to me.
06:43 < Eko> if I did anything, I might do KNOCK if you're not on a channel
with the person
06:43 < Eko> otherwise it goes through
06:43 < Eko> but I haven't gotten that far yet.
06:44 -!- Mellow [~Mellow@S010600119502636d.wp.shawcable.net] has joined #go-nuts
06:45 < Namegduf> An interesting one I'll be skipping is +O
06:45 < Namegduf> Because I think that +i and whatever mechanisms exist for
exempting users from +i should work
06:46 < Namegduf> And solving the fact that they don't by providing a
special oper version doesn't help everyone else.
06:47 < Eko> yeah, I think +O is silly too.
06:47 < Eko> along with such things as SUMMON and USERS.
06:48 < Eko> I can't really imagine a reason for even operators to be
getting a list of everyone connected
07:04 < anticw> anyone know off hand of a simple lexer (too lazy to write
one myself)
07:04 < anticw> i guess src/pkg/scanner isn't a bad start, but something
more generic would be nice
07:09 -!- Mellow [~Mellow@S010600119502636d.wp.shawcable.net] has quit [Quit:
Leaving]
07:11 -!- foocraft [~dsc@78.100.179.14] has joined #go-nuts
07:15 -!- lmoura_ [~lauromour@187.59.115.154] has joined #go-nuts
07:15 < Eko> anticw: not for go, no
07:16 < Eko> though rsc had an article on his blog about yacc not being
dead, so he may have found a way to use it with go.  Not sure.
07:16 < Eko> (of course, yacc working might not make lex work)
07:17 -!- lmoura [~lauromour@186.212.105.150] has quit [Ping timeout: 255 seconds]
07:26 -!- vasu_ [~vasu@202.63.112.184] has quit [Remote host closed the
connection]
07:30 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
07:30 -!- zozoR [~zozoR@56346ed3.rev.stofanet.dk] has joined #go-nuts
07:31 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has joined #go-nuts
07:33 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has left #go-nuts []
07:39 < anticw> Eko: there is goyacc, that's not bad
07:39 < anticw> a lexer typically takes a stream of bytes and outputs tokens
07:39 < anticw> yacc parses token patterns
07:43 -!- vegai [vegai@archlinux/developer/vegai] has joined #go-nuts
07:49 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has quit [Ping timeout: 255
seconds]
08:00 -!- chressie [~chressie@dreggn.in-ulm.de] has quit [Quit: WeeChat 0.3.3]
08:01 -!- chressie [~chressie@dreggn.in-ulm.de] has joined #go-nuts
08:04 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts
08:07 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has quit
[Read error: Connection reset by peer]
08:07 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has joined
#go-nuts
08:10 -!- joatmon54 [~engest@cpe-66-74-195-46.san.res.rr.com] has quit [Quit:
Ex-Chat]
08:11 -!- illya77 [~illya77@77-49-133-95.pool.ukrtel.net] has joined #go-nuts
08:11 -!- tensorpudding [~user@99.56.169.128] has quit [Remote host closed the
connection]
08:18 -!- cirno|sleep [~cirno@77.232.15.216] has quit [Ping timeout: 255 seconds]
08:20 -!- snearch [~snearch@f053008239.adsl.alicedsl.de] has joined #go-nuts
08:32 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts
08:39 -!- LeNsTR [~lenstr@79.165.23.176] has joined #go-nuts
08:39 -!- LeNsTR [~lenstr@79.165.23.176] has quit [Changing host]
08:39 -!- LeNsTR [~lenstr@unaffiliated/lenstr] has joined #go-nuts
08:39 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts
08:42 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts
08:45 -!- plexdev [~plexdev@arthur.espians.com] has quit [Ping timeout: 255
seconds]
08:46 -!- Urmel| [~11087Urme@82-136-196-44.ip.telfort.nl] has quit [Ping timeout:
255 seconds]
08:47 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has quit
[Read error: Connection reset by peer]
08:47 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has joined
#go-nuts
08:50 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|]
08:51 -!- Urmel| [~11087Urme@82-136-196-44.ip.telfort.nl] has joined #go-nuts
08:58 < taruti> Is there a sane alternative to curses in Go?
09:01 -!- Project_2501 [~Marvin@82.84.93.10] has joined #go-nuts
09:02 < uriel> 'sane alternative to curses' doesn't compute
09:03 -!- photron_ [~photron@port-92-201-196-89.dynamic.qsc.de] has joined
#go-nuts
09:04 < taruti> uriel: something to draw UIs in *nix terminals (yes, I know
those are broken)
09:05 < uriel> I think there might be a couple in here somewhere:
09:05 < uriel> http://go-lang.cat-v.org/pure-go-libs
09:05 < uriel> there are also things built on top of curses I think, see the
bindings page
09:07 < taruti> uriel: nothing in the pure-go-section
09:07 < taruti> clingon looks promising but needs sdl
09:07 < Namegduf> I thought I remembered one.
09:17 -!- noktoborus [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts
09:26 < adg> nsf: awesome.  did you test the linux-386 one on a 386 machine,
or an amd64 machine?  and what linux distro?
09:26 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Ping timeout: 260
seconds]
09:36 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts
09:41 < tensai_cirno> check termbox
09:41 < tensai_cirno> taruti, ^^^
09:42 < taruti> thanks
10:01 < nsf> adg: I've tested linux 386 on a 386 machine, archlinux distro
and linux amd64 on the qemu (emulator), same distro
10:03 < nsf> well, not really
10:03 < nsf> the machine is x86_64, but distro is 32 bit
10:04 < nsf> :\
10:04 < nsf> what a mess..
10:08 -!- femtoo [~femto@95-89-248-96-dynip.superkabel.de] has joined #go-nuts
10:10 < nsf> taruti: yeah, termbox is the one, but only if you're targetting
linux, because it's broken on mac
10:10 < nsf> although I'm sure it is possible to make ncurse-based backend
for termbox in a day
10:11 < taruti> sane terminal emulators is enough
10:13 -!- Fish [~Fish@9fans.fr] has joined #go-nuts
10:14 < nsf> it's broken on mac for other reason (have no idea what's wrong,
have no mac to investigate), but I'm just saying..  the library interface is
small, it's pretty easy to implement it even on windows
10:14 < taruti> :)
10:35 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
11:03 -!- femtoo [~femto@95-89-248-96-dynip.superkabel.de] has quit [Ping timeout:
240 seconds]
11:04 -!- toyoshim [~toyoshim@y168217.dynamic.ppp.asahi-net.or.jp] has quit [Ping
timeout: 240 seconds]
11:05 -!- snearch [~snearch@f053008239.adsl.alicedsl.de] has quit [Quit:
Verlassend]
11:09 -!- toyoshim [~toyoshim@y168217.dynamic.ppp.asahi-net.or.jp] has joined
#go-nuts
11:12 -!- rlab [~Miranda@91.200.158.34] has quit [Read error: No route to host]
11:15 -!- femtoo [~femto@95-89-248-96-dynip.superkabel.de] has joined #go-nuts
11:24 -!- wrtp [~rog@drynoch.demon.co.uk] has joined #go-nuts
11:28 -!- xash [~xash@d162187.adsl.hansenet.de] has joined #go-nuts
11:38 -!- Scorchin [~Scorchin@host86-173-188-202.range86-173.btcentralplus.com]
has joined #go-nuts
12:00 < adg> nsf: great, thanks again
12:01 < nsf> ;)
12:06 -!- Eko [~eko@adsl-76-251-235-206.dsl.ipltin.sbcglobal.net] has quit [Quit:
This computer has gone to sleep]
12:33 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
12:41 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Ping timeout: 250 seconds]
12:50 -!- noktoborus [debian-tor@gateway/tor-sasl/noktoborus] has quit [Ping
timeout: 240 seconds]
13:03 -!- wrtp [~rog@drynoch.demon.co.uk] has quit [Quit: wrtp]
13:13 -!- noktoborus [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts
13:14 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts
13:16 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 265 seconds]
13:18 -!- tvw [~tv@e176001183.adsl.alicedsl.de] has joined #go-nuts
13:18 -!- oal [~oal@5.79-160-122.customer.lyse.net] has joined #go-nuts
13:19 < oal> Is Go faster than running javascript with V8? Or is that a
stupid question?
13:21 < vegai>
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=go
13:21 < oal> Oh, thank you
13:22 < vegai> the 64bit go seems to fare a bit better:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=go
13:25 < oal> Thank you vegai :)
13:30 < hokapoka> Erm, when using interfaces, can you use Exported
properties or is it only Exported Methods to define interfaces?
13:30 < aiju> hokapoka: only methods
13:31 < hokapoka> Okay, thought as much,
13:31 < hokapoka> many thanks.
13:31 < aiju> and usually it's only one method :)
13:31 < aiju> Go interfaces are not Java classes…
13:32 < hokapoka> Just trying to setup some kinda persisant datastore for my
objects.
13:35 < hokapoka> thinking about the best approach so I have a Single Save,
and depending on the sate it either Inserts or Updates the persistant store.
13:38 < hokapoka> In that case, as you can only define Exported properties,
one shouldn't try to access any of the Exported props from within the method that
the interface type is passed, instead any manipulation should be done via the
methods that are used.
13:39 < hokapoka> opp, s/ as you can only define Exported properties/ as you
can only define Exported Methods
13:41 < KBme> well that sould logic: your interface should define all the
methods it will be using?
13:43 -!- ios_ [~ios@180.191.94.28] has quit [Quit: Leaving]
13:43 < hokapoka> I would assume the compiler would error if it trys to use
an Exported method that hasn't been defined on the interface type passed.
13:46 < hokapoka> which it does.
13:50 -!- sauerbraten [~sauerbrat@p508CFE24.dip.t-dialin.net] has joined #go-nuts
13:53 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3]
13:59 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
14:09 -!- sauerbraten [~sauerbrat@p508CFE24.dip.t-dialin.net] has quit [Read
error: Connection timed out]
14:17 -!- tensai_cirno [~cirno@80.250.216.102] has joined #go-nuts
14:17 -!- niemeyer_ [~niemeyer@200-203-59-56.pltce701.dsl.brasiltelecom.net.br]
has joined #go-nuts
14:21 -!- schilly [~schilly@boxen.math.washington.edu] has joined #go-nuts
14:49 -!- l00t [~i-i3id3r_@201008247247.user.veloxzone.com.br] has quit [Ping
timeout: 276 seconds]
14:50 -!- l00t [~i-i3id3r_@201008247247.user.veloxzone.com.br] has joined #go-nuts
14:58 -!- boscop [~boscop@g226245247.adsl.alicedsl.de] has joined #go-nuts
14:59 -!- Project-2501 [~Marvin@82.84.93.10] has joined #go-nuts
15:03 -!- Project_2501 [~Marvin@82.84.93.10] has quit [Ping timeout: 255 seconds]
15:11 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts
15:35 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has quit
[Ping timeout: 255 seconds]
15:35 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has joined
#go-nuts
15:37 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
15:40 -!- niemeyer__ [~niemeyer@189.30.51.90] has joined #go-nuts
15:42 -!- shvntr [~shvntr@116.26.134.123] has quit [Ping timeout: 265 seconds]
15:44 -!- niemeyer_ [~niemeyer@200-203-59-56.pltce701.dsl.brasiltelecom.net.br]
has quit [Ping timeout: 240 seconds]
16:13 -!- sauerbraten [~sauerbrat@p508CFE24.dip.t-dialin.net] has joined #go-nuts
16:14 -!- Venom_X [~pjacobs@66.54.185.131] has joined #go-nuts
16:25 -!- aconran [~aconran-o@adsl-76-199-140-78.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
16:30 -!- tensai_cirno [~cirno@80.250.216.102] has quit [Ping timeout: 260
seconds]
16:35 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3]
16:37 -!- WonTu [~WonTu@p57B56CC9.dip.t-dialin.net] has joined #go-nuts
16:38 -!- WonTu [~WonTu@p57B56CC9.dip.t-dialin.net] has left #go-nuts []
16:46 -!- keithcascio [~keithcasc@nat/google/x-unrvnlaspqtjbsch] has joined
#go-nuts
16:50 -!- Venom_X [~pjacobs@66.54.185.131] has quit [Ping timeout: 240 seconds]
16:53 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-162-156.clienti.tiscali.it] has
joined #go-nuts
16:54 -!- Venom_X [~pjacobs@66.54.185.131] has joined #go-nuts
16:56 -!- Project-2501 [~Marvin@82.84.93.10] has quit [Ping timeout: 240 seconds]
17:08 -!- eikenberry [~jae@ivanova.zhar.net] has joined #go-nuts
17:10 -!- tensai_cirno [~cirno@194.154.66.104] has joined #go-nuts
17:22 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has quit
[Ping timeout: 240 seconds]
17:23 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has joined
#go-nuts
17:24 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
17:26 -!- kanru [~kanru@118-160-173-16.dynamic.hinet.net] has joined #go-nuts
17:38 -!- illya77 [~illya77@77-49-133-95.pool.ukrtel.net] has quit [Read error:
Connection reset by peer]
17:43 -!- tensai_cirno [~cirno@194.154.66.104] has quit [Ping timeout: 255
seconds]
17:44 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has quit
[Ping timeout: 276 seconds]
17:45 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has joined
#go-nuts
17:45 -!- tensai_cirno [~cirno@194.154.66.104] has joined #go-nuts
17:46 -!- anticw_ [~anticw@parsec.stupidest.org] has joined #go-nuts
17:50 -!- kanru [~kanru@118-160-173-16.dynamic.hinet.net] has quit [Ping timeout:
255 seconds]
17:52 -!- tensai_cirno [~cirno@194.154.66.104] has quit [Ping timeout: 265
seconds]
17:53 -!- niemeyer__ [~niemeyer@189.30.51.90] has quit [Ping timeout: 272 seconds]
17:54 < taruti> Has implenting unions via closed interfaces been discussed
before?
17:54 < taruti> i.e.  type ClosedIface interface { isClosedIface() }, which
is "closed" ?
17:56 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has joined #go-nuts
17:56 -!- daharon [~daharon@173-11-102-86-SFBA.hfc.comcastbusiness.net] has joined
#go-nuts
18:01 < anticw> is that a union?
18:03 -!- foocraft [~dsc@78.100.179.14] has quit [Quit: Leaving]
18:06 < taruti> anticw: except for memory layout, yes.
18:12 -!- deso_ [~deso@x0561a.wh30.tu-dresden.de] has joined #go-nuts
18:20 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has quit
[Ping timeout: 246 seconds]
18:21 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has joined
#go-nuts
18:22 -!- illya77 [~illya77@129-159-112-92.pool.ukrtel.net] has joined #go-nuts
18:26 -!- outworlder [~stephen@189.90.170.251] has joined #go-nuts
18:27 < outworlder> is it possible to use the fork() unix syscall?
18:27 < taruti> there is os.ForkExec
18:29 < outworlder> taruti: my understanding is that it will run the
executable specified in its arguments.  however, I wanted to fork the current
process
18:38 -!- bgentry [~bgentry@75.85.173.206] has quit [Quit: bgentry]
18:39 < temoto> Yeah, strange that it is implicitly squashed 2 syscalls.
18:40 < temoto> Maybe it's because Go needs to reinitialize something in
child processes after fork (like epoll state) and that is not written yet.
18:41 < cbeck> That would be my guess
18:41 -!- nlg [~nlg@c-19c2e455.02-416-6c6b701.cust.bredbandsbolaget.se] has joined
#go-nuts
18:41 < nlg> where can i get my gopher tshirt?
18:43 < temoto> Or maybe that's because authors considered that there is no
need for forking.  Like use goroutines for what you wanted to fork.
18:43 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
18:44 < nlg>
http://ronnyb.spreadshirt.com/golang-fan-shirt-A6285354/customize/color/2
18:44 -!- nlg [~nlg@c-19c2e455.02-416-6c6b701.cust.bredbandsbolaget.se] has quit
[Client Quit]
18:44 < TheSeeker> http://shop.cafepress.com/golang
18:44 < TheSeeker> damn
18:52 < outworlder> temoto: I can agree with that reasoning.  however, I
currently have a C program that calls (non-threadsafe) third-party libraries I
have no control over, so it is implemented as a forking server.
18:55 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts
19:07 < taruti> Is there an easy way to embed files as []byte variable in a
go-executable?
19:08 < taruti> other than to generate in Makefile foo -> foo.hex.go and
include that
19:12 -!- sauerbraten_ [~sauerbrat@p508CFE24.dip.t-dialin.net] has joined #go-nuts
19:12 -!- sauerbraten [~sauerbrat@p508CFE24.dip.t-dialin.net] has quit [Remote
host closed the connection]
19:12 -!- sauerbraten_ [~sauerbrat@p508CFE24.dip.t-dialin.net] has quit [Remote
host closed the connection]
19:12 -!- sauerbraten [~sauerbrat@p508CFE24.dip.t-dialin.net] has joined #go-nuts
19:21 -!- Chryson [~Chryson@c-71-61-11-114.hsd1.pa.comcast.net] has joined
#go-nuts
19:24 -!- snearch [~snearch@f053008239.adsl.alicedsl.de] has joined #go-nuts
19:29 -!- l00t [~i-i3id3r_@201008247247.user.veloxzone.com.br] has quit [Ping
timeout: 240 seconds]
19:30 -!- illya77 [~illya77@129-159-112-92.pool.ukrtel.net] has quit [Read error:
Connection reset by peer]
19:36 -!- Eko [~eko@adsl-76-251-235-206.dsl.ipltin.sbcglobal.net] has joined
#go-nuts
19:42 -!- l00t [~i-i3id3r_@189.105.5.123] has joined #go-nuts
19:42 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has joined #go-nuts
19:43 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
19:49 -!- unofficialmvp [~dev@94-62-164-227.b.ipv4ilink.net] has left #go-nuts []
20:00 -!- BlaSux [7f000001@69.195.144.4] has quit [Ping timeout: 272 seconds]
20:01 -!- femtooo [~femto@95-89-248-96-dynip.superkabel.de] has joined #go-nuts
20:02 -!- sxs [~sxs@dslb-188-104-163-130.pools.arcor-ip.net] has joined #go-nuts
20:03 < sxs> hello
20:03 < sxs> i try to write a nanonr syntaxhighlighting for nan.  has
someone experience with hat?
20:04 -!- femtoo [~femto@95-89-248-96-dynip.superkabel.de] has quit [Ping timeout:
240 seconds]
20:05 < Eko> sxs: examples of how it was one with vim and emacs are both in
the source tree under $GOROOT/misc . Please submit a patch (or con somsone into
submitting one for you) if you get one working, so that other people can use it
too.
20:05 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Quit:
Leaving.]
20:06 < sxs> ahh, thx.  there is one for XCode :)
20:07 -!- BlaSux [7f000001@69.195.144.4] has joined #go-nuts
20:08 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has joined #go-nuts
20:13 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Quit: Leaving]
20:16 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal]
20:19 < taruti> Has anyone packaged nicely sessions for either web.go or
plain http-package?
20:19 -!- pothos_ [~pothos@111-240-213-117.dynamic.hinet.net] has joined #go-nuts
20:21 -!- pothos [~pothos@111-240-221-153.dynamic.hinet.net] has quit [Ping
timeout: 272 seconds]
20:51 -!- foocraft [~dsc@78.100.179.14] has joined #go-nuts
20:52 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts
20:52 -!- sxs [~sxs@dslb-188-104-163-130.pools.arcor-ip.net] has quit [Quit:
namaste]
21:01 -!- snearch [~snearch@f053008239.adsl.alicedsl.de] has quit [Quit:
Verlassend]
21:06 -!- nettok [~quassel@200.119.160.95] has joined #go-nuts
21:10 -!- donpdonp [~donp@donk.personaltelco.net] has joined #go-nuts
21:10 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
21:10 < donpdonp> is there a popular web app framework in go?
21:12 -!- bgentry [~bgentry@75.85.173.206] has joined #go-nuts
21:13 < temoto> Go on Rails :)
21:13 -!- dju_ [~dju@at.dmz.me] has joined #go-nuts
21:13 -!- dju_ [~dju@at.dmz.me] has quit [Changing host]
21:13 -!- dju_ [~dju@fsf/member/dju] has joined #go-nuts
21:13 -!- dju_ [~dju@fsf/member/dju] has quit [Read error: Connection reset by
peer]
21:14 < temoto> and djanGo
21:15 < temoto> donpdonp, i think there is one - web.go
21:17 < uriel> there are a couple actually, there is also rest.go and some
other I don't remember
21:17 < cbeck> Go on Golems
21:18 < uriel> sxs: when you finish it, send me a copy and I will add it to:
http://go-lang.cat-v.org/text-editors/
21:19 -!- l00t [~i-i3id3r_@189.105.5.123] has quit [Quit: Leaving]
21:19 < donpdonp> temoto: djanGo.  lol
21:21 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Ping timeout: 276 seconds]
21:22 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts
21:22 < daharon> It would be cool to see something like Tornado written in
go.  A full-on async application server...
21:23 < exch> You're welcome to do it :)
21:23 < daharon> I reeeeally want to.  I need a vacation...
21:26 < donpdonp> uriel: thx, found https://github.com/nathankerr/rest.go
21:26 < donpdonp> and getwebgo.com
21:26 < uriel> donpdonp: see also http://go-lang.cat-v.org/go-code
21:26 < uriel> and so on
21:27 < uriel> (or maybe in the libs section)
21:27 < temoto> omg please don't introduce callback terror in Go
21:27 < temoto> Go runtime is a full-on network server already.
21:28 < temoto> Just sit in accept/go process loop and you're fine.
21:28 -!- LeNsTR [~lenstr@unaffiliated/lenstr] has quit [Quit: LeNsTR]
21:28 < temoto> i mean for { accept(); go process() }
21:29 < temoto> donpdonp, ^
21:30 -!- devrim [~Adium@cpe-72-225-239-227.nyc.res.rr.com] has quit [Quit:
Leaving.]
21:36 < Eko> phew, finally got jaid packaged so you can just run "make
install"
21:36 < skelterjohn> what is jaid?
21:36 < donpdonp> temoto: noted
21:37 -!- emjayess [~emjayess@pix1.i29.net] has joined #go-nuts
21:38 < Eko> skelterjohn: the IRC server I'm writing.  until now, I've been
using my custom auto-build tool to build it, but I don't like making other people
use that.
21:39 < skelterjohn> what is your auto-build tool?
21:39 < Eko> skelterjohn: gofr
21:39 < skelterjohn> i ask because i wrote one too - gb:
http://code.google.com/p/go-gb/
21:39 < Eko> it's great for personal projects when you want to have local
packages not installed to $GOROOT and whatnot, but it's not appropriate for things
that will be distributed.
21:40 < |Craig|> Eko: I hacked a horrible make file system for that purpose
21:40 < Eko> skelterjohn: mine does local packages with relative imports,
cgo, and gotest generation...  I had way too much time on my hands.
21:40 < skelterjohn> unfortunately anything based purely on make will be
insufficient, since it can't analyze source
21:41 < skelterjohn> ah - i didn't do cgo or gotest
21:41 < skelterjohn> i've never written a cgo project
21:41 < Eko> me neither, I was just bored (lol)
21:41 < skelterjohn> and i felt that learning to by writing a build system
was the wrong approach
21:41 < Eko> heh.
21:41 < |Craig|> skelterjohn: make can analyze source, but thats asking for
suffering
21:41 < skelterjohn> also i don't have so much time on my hands
21:41 < Eko> skelterjohn: I just never sleep.
21:42 -!- donpdonp [~donp@donk.personaltelco.net] has left #go-nuts []
21:42 < skelterjohn> some things i can't justify at this point, though
projects like this are fun
21:42 < skelterjohn> there are a lot of things i'd like to do that i can't
justify the time spent
21:42 < skelterjohn> that -> for which
21:42 < Eko> indeed.
21:43 < skelterjohn> argh: why does the go dashboard not show up in a google
search for "go dashboard"
21:44 < skelterjohn> i wanted to see if Eko's project was listed, and hope
it wasn't so i wouldn't feel so bad about not knowing about it before i did gb
21:45 < Eko> anyone who wants to battle-test an IRCd (try to break it!) is
welcome to: ssl - irc://irc.didntdoit.net:16697/#jaid | nonssl -
irc://irc.didntdoit.net:16667/#jaid
21:45 < Eko> skelterjohn: gofr is listed.
21:45 < skelterjohn> well there we go
21:46 < KBme> Eko: yea?
21:48 < Eko> KBme: sure.  I'd prefer if it were by executing commands that
are tricky, but I'd be interested to see someone run a lot of remote clients
(though warning would be nice).
21:50 < KBme> tricky commands like?
21:50 < KBme> channel modes and the likes?
21:50 < Eko> yeah
21:51 < Eko> also, connecting twice and seeing if you can get into channels
your other self has set modes against, seeing if you can kick a fullop as halfop,
etc
21:51 < KBme> yep
21:51 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has quit
[Ping timeout: 255 seconds]
21:51 < KBme> well, modes are pretty much next, i'm doing tests now..
21:52 < Eko> are you on the net?  I didn't see a signon...
21:52 -!- Davidian1024 [~Davidian1@cpe-173-88-174-84.neo.res.rr.com] has joined
#go-nuts
21:54 < KBme> on the net?
21:54 < KBme> ah, no
21:54 < KBme> well, i'm guessing you already are doing stress-testing with
privmsgs, that's pretty much where I am.
21:58 < Eko> you writing an ircd too?
21:58 < KBme> client library
21:58 < Eko> ah.
21:58 -!- heliocma [~heliocma@187.105.142.232] has joined #go-nuts
21:58 < KBme> so i could use your server in my unit tests ;)
21:58 < Eko> my stress-testing is actually with large numbers of users in
large numbers of channels
22:02 < cbeck> Eko: Have flod control set up yet?
22:02 < cbeck> s/flod/flood/
22:02 < Eko> cbeck: no
22:05 -!- zozoR [~zozoR@56346ed3.rev.stofanet.dk] has quit [Quit: Morten.  Desu~]
22:10 < KBme> is there a way to have a tls config generated?
22:14 < Eko> KBme:
https://bitbucket.org/kylelemons/jaid/src/26f31c6ee134/src/pkg/irc/server.go#cl-506
22:15 < KBme> oh that's simple enough
22:15 < Eko> and there's a prorgam in $GOROOT/src/pkg/crypto/tls somewhere
that can generate them for you
22:15 < Eko> genrate the cert.pem and key.pem that is
22:16 < Eko> (I shamelessly copied it almost verbatim for my jaid-gencert)
22:18 < KBme> :)
22:19 -!- outworlder [~stephen@189.90.170.251] has quit [Quit: Leaving.]
22:20 -!- drry [~drry@unaffiliated/drry] has quit [Ping timeout: 240 seconds]
22:21 < Eko> rofl, I just ended a commit message (from the command-line)
with :wq
22:21 < Eko> I am so cool >_<
22:34 -!- Fish [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the
Fish]
22:35 -!- heliocma [~heliocma@187.105.142.232] has left #go-nuts []
22:41 -!- sav [~lsd@jagat.xored.org] has joined #go-nuts
22:42 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 240 seconds]
22:50 -!- tvw [~tv@e176001183.adsl.alicedsl.de] has quit [Remote host closed the
connection]
22:52 -!- niemeyer__ [~niemeyer@189.30.51.90] has joined #go-nuts
22:57 -!- femtooo [~femto@95-89-248-96-dynip.superkabel.de] has quit [Read error:
Connection reset by peer]
22:58 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has joined
#go-nuts
23:04 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Read error:
Connection reset by peer]
23:05 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts
23:16 -!- oal [~oal@5.79-160-122.customer.lyse.net] has left #go-nuts []
23:17 -!- deso_ [~deso@x0561a.wh30.tu-dresden.de] has quit [Remote host closed the
connection]
23:21 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit:
Verlassend]
23:28 -!- cbeck1 [cbeck@gateway/shell/pdx.edu/x-ubdstoaobwnnzmdo] has joined
#go-nuts
23:28 -!- cbeck [cbeck@gateway/shell/pdx.edu/x-adwauuliceipuhgv] has quit [Read
error: Connection reset by peer]
23:31 -!- aconran [~aconran-o@adsl-76-199-140-78.dsl.pltn13.sbcglobal.net] has
quit [Remote host closed the connection]
23:31 -!- aconran [~aconran-o@adsl-76-199-140-78.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
23:31 -!- emjayess [~emjayess@pix1.i29.net] has quit [Quit: Leaving]
23:33 -!- aconran_ [~aconran-o@adsl-76-199-140-78.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
23:34 -!- foocraft [~dsc@78.100.179.14] has quit [Ping timeout: 272 seconds]
23:36 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Quit: Leaving]
23:36 -!- aconran [~aconran-o@adsl-76-199-140-78.dsl.pltn13.sbcglobal.net] has
quit [Ping timeout: 255 seconds]
23:38 -!- napsy [~luka@88.200.96.18] has joined #go-nuts
23:38 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts
23:41 -!- drry [~drry@unaffiliated/drry] has joined #go-nuts
23:50 -!- Chryson [~Chryson@c-71-61-11-114.hsd1.pa.comcast.net] has quit [Quit:
Leaving]
23:50 -!- aconran__ [~aconran-o@adsl-76-199-140-78.dsl.pltn13.sbcglobal.net] has
joined #go-nuts
23:52 -!- aconran_ [~aconran-o@adsl-76-199-140-78.dsl.pltn13.sbcglobal.net] has
quit [Ping timeout: 240 seconds]
23:57 -!- tensai_cirno [~cirno@77.232.15.216] has quit [Ping timeout: 240 seconds]
--- Log closed Thu Dec 30 00:00:01 2010