--- 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