--- Log opened Sun Mar 06 00:00:55 2011
00:17 -!- tarrant [~tarrant@]
has joined #go-nuts
00:22 -!- chomp [~ken@c-71-206-216-232.hsd1.pa.comcast.net] has quit [Quit:
00:27 -!- photron [~photron@port-92-201-10-205.dynamic.qsc.de] has quit [Read
error: Operation timed out]
00:31 -!- dshep [~dshep@] has joined #go-nuts
00:37 -!- dshep [~dshep@] has quit [Quit: dshep]
00:41 -!- dshep [~dshep@] has joined #go-nuts
00:58 -!- tarrant [~tarrant@]
has quit [Quit: Leaving...]
01:07 -!- tarrant [~tarrant@]
has joined #go-nuts
01:07 -!- tvw [~tv@e176001205.adsl.alicedsl.de] has quit [Ping timeout: 255
01:08 -!- tvw [~tv@e176000087.adsl.alicedsl.de] has joined #go-nuts
01:30 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has quit [Remote host
closed the connection]
01:46 -!- foocraft [~dsc@] has quit [Quit: Leaving]
01:55 -!- vinisterx [~ryan@74-129-201-27.dhcp.insightbb.com] has quit [Read error:
Operation timed out]
02:05 -!- dshep [~dshep@] has quit [Quit: dshep]
02:06 -!- tvw [~tv@e176000087.adsl.alicedsl.de] has quit [Remote host closed the
02:11 < tarrant> What's the best way to convert a u_char array to a Gostring
in cgo?
02:11 < steven> woot i wrote a channel-based fibonacci sequence :D
02:11 * steven dances
02:11 < steven> it was inspired by the fact that go's channels can be used
very similarly to python's yield
02:12 -!- tarrant [~tarrant@]
has quit [Quit: Linkinus - http://linkinus.com]
02:15 < steven> guys,
02:16 < steven> am i correct in understanding that a select with only one
case statement and no default statement is the same as just that case statement by
itself (whether its a send or receive operation)?
02:16 -!- shvntr [~shvntr@] has joined #go-nuts
02:23 -!- boscop [~boscop@f050135026.adsl.alicedsl.de] has quit [Ping timeout: 255
02:29 < |Craig|> steven: I believe that is the case
02:37 <@adg> steven: yes this is true
02:41 < steven> wow, i just read the semaphre example in effective_go, for
the first time, and i actually understood it.  its really fricken cool stuff!!
02:42 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has quit [Ping timeout: 276
02:44 < steven> does Go's concurrency abilities make it possible for a
single Go process to replace a cluster of rails mongrels (assuming the processes
are comparable)?
02:44 < steven> or am i misunderstanding something here?
02:54 -!- frewsxcv [~frewsxcv@] has joined #go-nuts
02:54 -!- frewsxcv [~frewsxcv@] has quit [Changing host]
02:54 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has joined #go-nuts
03:06 -!- foocraft [~dsc@dyn-86-36-42-96.wv.qatar.cmu.edu] has joined #go-nuts
03:20 <@adg> steven: probably
03:21 <@adg> serving http doesn't require much.  a lot of web servers and
frameworks are over the top
03:28 < steven> ok.
03:28 < steven> GUYS!
03:28 < steven> i figured out my problem!!
03:29 < steven> i already have a goroutine sending "ch <- value" and
*afterwards*, i "close(ch)" outside that goroutine.
03:29 < steven> which causes the panic "runtime error: send on closed
03:29 < steven> so im wondering, "what the crap?"
03:31 < steven> heres a good example: https://gist.github.com/857003
03:32 < exch_> the routine ding the sending should be responsible for
closing :)
03:32 < steven> ooh.  i didnt know that.
03:32 < steven> so that goroutine should listen in on some kind of
"wantsQuit" chan, and close when appropriate?
03:33 < exch_> i'm also not sure why you have the channel write in a select
03:33 < steven> oh that was an experiment.
03:33 < exch_> select is used to poll channels for available data to read
03:33 < steven> sorry.
03:33 < exch_> np, just saying
03:34 < steven> ty
03:34 < steven> where did you get the idea that only the goroutine sending
to a chan is resopnsible for closing it?
03:34 < steven> is that somewhere in the effective go docs or something?
03:35 < |Craig|> steven: because nothing else is safe
03:35 < steven> oh.  for the reason i just found out?
03:35 < steven> *discovered
03:35 < |Craig|> if you close it any other way, you might close while
sending, or close in 2 places at once, both of which are bad
03:35 < exch_> you get race conditions if something other than the writer
closes the channel
03:36 < exch_> brb
03:36 -!- exch_ [~exch@h78233.upc-h.chello.nl] has quit [Quit: leaving]
03:36 < |Craig|> in your code, close does not happen after the send (see
happens after in the spec)
03:36 -!- exch [~exch@h78233.upc-h.chello.nl] has joined #go-nuts
03:37 < steven> ah.  thanks guys..
03:37 < fzzbt> how do i get max value of uint64 type?  in C there's INT_MAX
etc.  for int type in limits.h..  how in go?
03:37 < |Craig|> hum, thats not in the spec, I wonder where I read about
that stuff..
03:37 < fzzbt> or any type for that matter
03:38 < |Craig|> fzzbt: 2<<64-1, but there are constants somewhere
03:39 < |Craig|> fzzbt: http://golang.org/pkg/math/
03:40 < exch> 1<<64-1 :)
03:40 < |Craig|> MaxUint64 = 1<<64 - 1 (I was wrong...)
03:40 < fzzbt> oh math..
03:40 < |Craig|> 2**64, 1<<64.  Silly me....
03:43 < steven> this *seems* to work, but the channels are reported as
not-closed..  probably because by the time main() is finished, the goroutine never
03:44 < steven> so is there a better way to test this concept?
03:47 < steven> ooh wait, no.  its happening because i didnt retreive the
0-value for both channels after closing them.
03:48 < |Craig|> steven: the break is not needed, though if you want
clarity, you can put a return there
03:48 < steven> oh good point.
03:49 < steven> i put it in there forgetting its not inside a for{}
03:49 < |Craig|> steven: also, if you just need to send a message to say you
are done, you can skip the send, and just close the chan and it will produce 0
03:49 < steven> and i would generally put break instead of return in case
any final actions would need to be taken, they can be put after the for{}, instead
of being litered and duplicated inside the select/for loops
03:50 < steven> hmm good point.
03:50 < steven> but crap, i just realized,
03:50 < |Craig|> steven: also, using a for x:=range(chan) is really nice.
Sucks items out until closed
03:50 < steven> this means i need to have a companion is-quitting-channel
for every goroutine (with its own incoming channel) whom i may want to kill in the
03:50 < steven> since a sender-goroutine cannot have any other way of
knowing that some external force wants it to die to death.
03:51 < steven> |Craig|: oh sweet i didnt know range was a function too,
thoguht it was just a for clause
03:51 < |Craig|> things you want to kill all at once can all be provided the
sam kill chan
03:51 < |Craig|> *smae
03:51 < |Craig|> *same.  I can't type aparently
03:52 < |Craig|> range is just a for clause, but you can use it to loop over
channel contents
03:52 < steven> i would just check closed(killchan) at some point in every
03:53 < |Craig|> steven: that or if you have a select that tends to block,
give it a case in there
03:54 < steven> but, if i did something like case <- killchan, wont only
one of the goroutines be able to receive a 0-value if i do clos(killchan)
03:54 < steven> or does it send that final 0-value to all receiving
expressions in existence?
03:54 < |Craig|> closed channels produce infinate o values
03:54 < steven> awesome!  this is sweet!
03:55 < exch> for some reason closed(ch) always returns false, even after it
has explicitely been closed
03:55 < |Craig|> I generally detect closing with for loops over channels, or
03:55 < exch> http://pastie.org/1638220
03:55 < steven> exch: nope
03:56 < steven> here's why:
03:56 < steven> https://gist.github.com/857003
03:56 < steven> i thought that same thing 15 mins ago exch and was confused.
but it turns out you need to receive from it one last time first.
03:57 < exch> weird.  i never ran into that before
03:57 < steven> "After at least one such zero value has been received,
closed(c) returns true."
03:57 < steven> yeah i only found out about it by accident and found that in
the spec.
03:57 < exch> prolly cos I poll for reads in a loop
03:57 < steven> right, dito
03:57 < |Craig|> if you just say close, that won't sync with the other go
routine, the close may happen much later
03:57 < exch> ah well.  closed(c) will soon be gone
03:58 < steven> now i think im armed with (almost?) enough understanding to
finally write this little bot in an idiomatic way that *doesnt* suck horribly and
leak channels and cause race conditions etc
03:58 < steven> exch: why will closed() soon be gone?
03:58 < |Craig|> closed is a bad idea.  If closed is false, you can't trust
it because it might close before the next instruction> its only useful if its
03:58 < exch> because if these confusions and race conditions it can cause
03:58 < steven> oh touche
03:58 < steven> ok ill try to write my stuff without closed()
03:58 < exch> it will be replaced with: v, ok := <-ch; ok will be false
if the chan is closed
03:59 < |Craig|> if you say "if !closed(x) {x<-1}" you will have an
03:59 < steven> but closed() isnt necessary anyway, considering you can just
receive on a killchan to know when you're supposta die
03:59 < steven> exch: i saw that trick on stackoverflow earlier, but i
couldnt find anything about it on golang.org (only relating to maps)
04:00 < steven> |Craig|: which i in fact did, earlier, for a while.
04:00 < steven> yay for knowledge!
04:00 < steven> we're so blessed :)
04:01 < exch> the v, ok := construct is used to check of mapkeys exist.
it's also used to validate type assertions
04:01 < exch> as in: n, ok := v.(int); to see if v is an int or not
04:01 < skelterjohn> non stop language tutorial party this weekend
04:02 < skelterjohn> i like it
04:02 < steven> haha
04:02 < steven> <3
04:05 < steven> i finally have a solid example of how to kill a goroutine
(which i could not figure out earlier)..
04:05 < steven> https://gist.github.com/857003
04:06 < steven> at least i hope its solid..  maybe its still not, but it
seems to pass my (trivial) test.
04:06 < steven> select/goroutines/channels completely confused the heck out
of me last time i tried to learn go.  now i realize why go wasnt that fun, because
without these things its just another language with nothing too special..  this is
what makes it fun and special :)
04:08 < exch> they certainly make life easier in some situations
04:09 < skelterjohn> i like it because you can get right to work and not
have to build up structure in order to do interesting things
04:09 < steven> right on.
04:09 < steven> my first goal is to build a solid, robust irc client (for a
bot, probably)
04:09 < skelterjohn> though certainly the concurrency support is what drew
me in the first place
04:09 < exch> yes, the lack of boilerplate is definitely a welcome change
from C#
04:10 * steven comes from ObjC and lately some Ruby too
04:10 < exch> Go just gets shit done.
04:10 < skelterjohn> i've fooled around with ObjC for ios dev
04:10 < steven> yeah its alright, not as fun as Go but better than C++
04:11 < skelterjohn> i thought it was a bit weird, tbh
04:11 < skelterjohn> i liked the ios memory management trick
04:11 < skelterjohn> but that is not an ObjC feature
04:12 < steven> heh
04:13 < |Craig|> I never did figure out why I get eternal handshakes.
Anyone here know anything about tls?
04:13 < steven> not i, sorry
04:14 < exch> nope, sorry
04:14 < skelterjohn> is the handshake part of an existing protocol?
04:14 < skelterjohn> oh, i suppose tls is a protocol
04:14 < |Craig|> I've got python+twisted client side, and go+tls server
side.  No errors, but I can't sent anything because the handshake call never
04:14 < skelterjohn> why not put a sniffer on the stream and see what data
is actually flying around?
04:15 < |Craig|> because debugging tls handshakes with a packetsniffer is
not easy...
04:15 < skelterjohn> ok :) i've never heard of tls
04:15 < |Craig|> both client and server are on the same computer using the
same certificate file
04:15 < skelterjohn> if you use a client in another language does it work
04:15 < |Craig|> skelterjohn: how about ssl, heard of that?
04:16 < skelterjohn> yes, i've heard of ssl
04:16 < skelterjohn> i don't know much more than 'secure socket layer'
04:16 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 246 seconds]
04:17 < |Craig|> its like the new SSL, though technically I think I'm
falling back to SSL
04:18 < |Craig|> tsl 1.0 = SSL 3.1 aparently
04:18 < |Craig|> I don't know why they went with a new name
04:35 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has quit [Ping timeout: 246
04:50 -!- iant [~iant@] has quit [Ping timeout: 276 seconds]
04:52 -!- pearle [~pearle@blk-224-181-222.eastlink.ca] has quit [Quit: Leaving]
04:54 < steven> where does the return value if a goroutine's function go?
is it possible to retreive, ever?
04:54 < steven> or is it discarded every single time?
04:55 < cbeck> discarded
04:56 < steven> k.
04:56 < steven> thanks
04:57 -!- foocraft [~dsc@dyn-86-36-42-96.wv.qatar.cmu.edu] has quit [Ping timeout:
252 seconds]
04:57 -!- vsayer [~vivek@c-76-102-205-58.hsd1.ca.comcast.net] has quit [Ping
timeout: 260 seconds]
05:02 < steven> this is both simpler and harder than i thought..
05:03 < steven> its one thing to tell all the goroutines they need to be
quit by giving them a chan to listen to, and when it receives, they know to die.
05:04 -!- foocraft [~dsc@dyn-86-36-42-96.wv.qatar.cmu.edu] has joined #go-nuts
05:04 < steven> but now i need to find a way to allow each goroutine to tell
the main loop+select that it specifically wants the whole thing to quit, ie
triggering the aforementioned cascade of goroutine-death
05:05 < steven> so it looks like i need to give each goroutine its own
individual "wanna quit?" channel, and listen for every one of them in the main
loop, to know when to quit.
05:05 < steven> is there a better solution than this?
05:07 < exch> http://jan.newmarch.name/go/index.html
05:07 < steven> whoaaaa
05:08 < exch> just saw that posted on hackernews
05:08 < steven> i doubt ill be able to understand this kinda stuff :)
05:08 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts
05:08 -!- mode/#go-nuts [+v iant] by ChanServ
05:08 < steven> im not all academic and whatnot.
05:09 < steven> oh sorry, i guess you werent responding to me so much as you
were just saying it.
05:09 < steven> my mistaken.
05:09 < exch> hehe ya, just posted it for relevancy
05:11 < exch> it seems to provide a fair amount of rudimentary network
theory which may come in handy at some point
05:11 < steven> :)
05:11 < steven> i wonder, does a still-open channel qualify for garbage
collection if nobody has a refernce to it anymore?
05:12 < steven> (ie, nobody is sending/receiving/referencing it)
05:12 < steven> or must it be closed first?
05:12 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host
closed the connection]
05:12 < exch> if there are no rederences to it, it should be marked for
cleanup afaik
05:12 < exch> *references
05:14 < steven> k.  cuz im thinking that a better solution to this problem
might involve giving every (relevant) goroutine a write-only channel allowing them
each to write to it when they want to signal that its quittin time, only listening
in one central spot, and never close it.
05:14 < steven> but i feel kinda nervous about having a channel that i never
close, it seems like an unclean, un-balanced thing to do
05:14 < steven> what are your thoughts on this, guys?  :)
05:16 < exch> If there is no way to do it cleanly, you probably need to
rethink your code layout.  having said that, we have a garbage collector for a
reason.  Your computer won't explode if you dont close it
05:16 < exch> I for one do prefer to clean up the mess I made though, but
that's just me
05:17 < steven> ditto
05:18 < steven> but which would you prefer, to have a write-only chan that
you pass around to every goroutine and never close, or individual write-close
channels per goroutine?
05:19 < exch> one channel that is passed to the goroutines.  The goroutines
should not be responsible for closing it though, cos another ruotine may still be
writing to it
05:19 < exch> the routine which created the channel should close it after
all goroutines have finished doing their stuff
05:20 < exch> I can see how that is tricky though.  How do you know when
that has happened if they cant send some signal
05:20 < steven> hmm, this forces me to think about something i was just
05:20 -!- frewsxcv [~frewsxcv@] has joined #go-nuts
05:20 -!- frewsxcv [~frewsxcv@] has quit [Changing host]
05:20 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has joined #go-nuts
05:22 < steven> i guess they might not all want to write to it, since its
optional.  so its hard to know whens the right time to close it.
05:22 < steven> but i dont like thinking my goroutines have so much freedom
that i never know what they're doing or what state they're in..  so perhaps i
should know.
05:24 < steven> whoa, this is a weird problem i just ran into..
05:25 < steven> i have a select that is only receiving from 2 channels, one
was close()'d and one has not yet been written to at all.  but the select seems to
wait until the second one writes, and accepts that, instead of noticing the
close()'d one!
05:25 < steven> im guessing whoever told me that close() just sends an
endless supply of 0-values was mistaken, or maybe i just misunderstood.
05:26 < steven> oh no, the spec confirms this.
05:26 < steven> ugh.  im confused.
05:28 < Namegduf> steven: Closed channels generally stop being read from by
automatic stuff.
05:29 < Namegduf> range will stop once they are closed, and I suspect select
will, too.
05:29 < steven> so they dont get notified simultaneously in all concurrent
selects in all existing goroutines that are trying to receive from it?
05:30 < steven> crap.  i was relying on the fact that select would continue
to receive from it, in my entire design.  crap.
05:30 < steven> back to square one.
05:30 < Namegduf> You can send a zero value.
05:30 < Namegduf> Although the problem of multiple readers exists.
05:30 < steven> i almost had something that worked, too..
05:31 < exch> http://pastie.org/1638405 this seems to work fine.  3 writers
and one reader.
05:31 < exch> not sure if that covers your issues though
05:32 < exch> not sure if the closing is what kills the goroutines or the
fact that main returns though.  lemme test
05:33 < steven> add select{} to the end :)
05:33 < exch> mm nope.  the close() is never registered with the workers in
that sample
05:34 < steven> well one thing i can deduce is that the next select
statement of mine, *does* properly notice that the channel is closed, and receive
a 0 value because of it.
05:34 < steven> its just that the *current* one does not.
05:35 < steven> man i suck at english.
05:35 < exch> with a select{} at the end of main, the workers throw a panic
because they attempt to write to a closed channel.
05:35 < exch> this is why closed() sucks
05:36 < steven> so what this seems to say is that if you close a chan, its
not necessarily sent immediately to all receiving operations, but its sent..
05:36 < steven> i dont get it.
05:36 < steven> OOOH
05:37 < steven> maybe this has to do with the fact that in select, the
expression is evaluated only once.
05:37 < exch> a close() sends a nil value to the channel.  but a goroutined
trying to write to the chan is in a blocking call waiting for a spot to open up
for it to write.  it never registers the nil/close
05:39 < steven> "If multiple cases can proceed, a pseudo-random fair choice
is made to decide which single communication will execute." -- shouldnt they just
do "the topmost will proceed"?
05:40 < exch> Now I see why you had a send in a select statement.  It seems
some of the behaviour has recently changed.  You used to be able to do: ok := ch
<- 1; this would do a non-blocking send and ok would be true if it succeeded.
This is now illegal
05:40 < steven> oh.  i had no idea about that.
05:40 < exch> compiler now complains about that: test.go:11: send statement
out <- i used as value; use select for non-blocking send
05:40 < exch> learn something new every day :p
05:40 < steven> no, thats not why i do that
05:41 < steven> i do it because the receiver (the main loop) may not be
ready for the sending of the string data just yet, but in the meantime the main
loop may have signalled that the goroutine should kill itself
05:41 < steven> so it puts the send string and the listen for quit message
both in a select in hopes that it will know what to do.
05:42 < steven> it does, just not at the timing i expected.
05:42 < steven> *with the?
05:42 < exch> mm It would be handy if you had some measure of control over
which case would run first then
05:43 < steven> right.  at least thats my guess as to the behavior im
05:46 < steven> changing it to use one-signal-chan-per-goroutine solves this
problem it seems.
05:48 < steven> so this horrible nightmare is what i ended up with, for the
simplest of cases: https://gist.github.com/857055
05:49 -!- segy_ [~segfault@pdpc/supporter/active/segy] has joined #go-nuts
05:50 < steven> the things i dont like about it are (1) it has one "you need
to die" signalling channel per input-fetching-goroutine, and (2) it has select
statements up the wazoo in a way that i cant think of minimizing
05:52 < steven> i guess the second point isnt so bad, its just
2-per-goroutine when i would prefer 1..  the first handles the blocking
data-fetching call (while listening for a quit), and the second handles the
blocking sending-data operation (while listening for a quit)
05:52 -!- segy [~segfault@pdpc/supporter/active/segy] has quit [Ping timeout: 276
05:52 < steven> cant think of a way to reduce that any further.
05:52 < steven> not without having less control over the lifetime of these
goroutines, at least.
06:08 < exch> ?permt outrageouslylongandconvultedwordwithcakeandcoffee
06:08 < exch> oops
06:08 < exch> wrong chan
06:15 < exch> the bignum package is excellent for doing word/character
permutations <3
06:33 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts
06:47 < |Craig|> steven: defer the calls you make after the loop, then you
can remove the label and break, and just return
06:49 < |Craig|> my go routine killer tents to be a single "halt <-chan
int" that I close to kill, and return when I pull a value from it in a select.  If
something is eating a stream of values on a channel, just use a for loop on the
channel, and it will automatically fall through when its input chan is closed.
06:53 -!- perdiy [~mkhl@sxemacs/devel/perdix] has joined #go-nuts
06:54 -!- vsayer [~vivek@c-76-102-205-58.hsd1.ca.comcast.net] has joined #go-nuts
06:55 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Ping timeout: 276 seconds]
07:03 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has joined #go-nuts
07:15 -!- photron [~photron@port-92-201-10-205.dynamic.qsc.de] has joined #go-nuts
07:18 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
07:26 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has joined #go-nuts
07:28 -!- nettok [~quassel@] has quit [Ping timeout: 264 seconds]
07:31 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host
closed the connection]
07:37 -!- tav [~tav@] has quit [Read error: Connection reset by peer]
07:38 -!- Natch| [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has
quit [Ping timeout: 250 seconds]
07:38 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has joined #go-nuts
07:39 -!- visof [~visof@] has joined #go-nuts
07:39 -!- visof [~visof@] has quit [Changing host]
07:39 -!- visof [~visof@unaffiliated/visof] has joined #go-nuts
07:46 -!- Natch| [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has
joined #go-nuts
07:54 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has quit [Remote
host closed the connection]
08:13 -!- piranha [~piranha@5ED4B890.cm-7-5c.dynamic.ziggo.nl] has quit [Quit:
Computer has gone to sleep.]
08:15 -!- xulfer [~xulfer@cheapbsd.net] has joined #go-nuts
08:16 -!- tav [~tav@] has joined #go-nuts
08:16 -!- karpar [~karpar@] has joined #go-nuts
08:18 -!- karpar [~karpar@] has quit [Client Quit]
08:19 -!- karpar [~karpar@] has joined #go-nuts
08:21 -!- napsy [~luka@tm.] has joined #go-nuts
08:24 -!- pjm0616 [~user@sigfpe-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit
[Ping timeout: 260 seconds]
08:25 -!- karpar [~karpar@] has quit [Ping timeout: 240 seconds]
08:28 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping
timeout: 260 seconds]
08:30 -!- Project_2501 [~Marvin@] has joined #go-nuts
08:31 -!- karpar [~karpar@] has joined #go-nuts
08:36 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts
08:41 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|]
08:46 -!- saturnfive [~saturnfiv@] has joined #go-nuts
08:47 -!- saturnfive [~saturnfiv@] has left #go-nuts []
08:53 -!- karpar [~karpar@] has quit [Ping timeout: 276 seconds]
09:08 -!- rlab [~Miranda@] has joined #go-nuts
09:15 -!- pjm0616 [~user@sigfpe-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined
09:20 -!- tensorpudding [~user@] has quit [Remote host closed the
09:33 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts
09:36 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Ping timeout:
255 seconds]
09:37 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts
09:39 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts
09:40 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Ping timeout:
255 seconds]
09:41 -!- edsrzf [~kelvan@122-61-221-144.jetstream.xtra.co.nz] has quit [Ping
timeout: 252 seconds]
09:44 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Ping
timeout: 260 seconds]
09:50 -!- ShadowIce
[~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has joined
09:50 -!- ShadowIce
[~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has quit
[Changing host]
09:50 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts
10:02 -!- aconran [~aconran-o@] has quit [Remote host closed the
10:02 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts
10:05 -!- aconran [~aconran-o@] has joined #go-nuts
10:05 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Ping timeout:
246 seconds]
10:07 -!- nickbp [~eqoaq@] has quit [Ping timeout: 276
10:15 -!- nickbp [~eqoaq@] has joined #go-nuts
10:19 -!- espeed [~espeed@] has joined #go-nuts
10:20 -!- nickbp [~eqoaq@] has quit [Ping timeout: 260
10:22 -!- aconran [~aconran-o@] has quit [Remote host closed the
10:23 -!- aconran [~aconran-o@] has joined #go-nuts
10:26 -!- GoBIR [~gobir@c-24-130-224-186.hsd1.ca.comcast.net] has quit [Ping
timeout: 252 seconds]
10:30 -!- GoBIR [~gobir@c-24-130-224-186.hsd1.ca.comcast.net] has joined #go-nuts
10:34 -!- aconran [~aconran-o@] has quit [Ping timeout: 276 seconds]
10:36 -!- nickbp [~eqoaq@] has joined #go-nuts
10:49 -!- DerHorst [~Horst@e176102247.adsl.alicedsl.de] has joined #go-nuts
10:51 -!- tensai_cirno [~cirno@] has joined #go-nuts
10:54 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined
11:03 -!- tensai_cirno [~cirno@] has quit [Ping timeout: 276 seconds]
11:36 -!- visof_ [~visof@] has joined #go-nuts
11:37 -!- visof__ [~visof@] has joined #go-nuts
11:39 -!- saschpe [~quassel@opensuse/member/saschpe] has joined #go-nuts
11:39 -!- visof [~visof@unaffiliated/visof] has quit [Ping timeout: 248 seconds]
11:40 -!- Project_2501 [~Marvin@] has quit [Quit: E se abbasso questa
leva che succ...]
11:40 -!- visof_ [~visof@] has quit [Ping timeout: 250 seconds]
11:48 < nsf> hm..  it's funny but I've never thought about bitwise operator
precedence until now
11:48 < nsf> operators*
11:49 < nsf> and it turns out that in C it's a bit broken :)
11:49 < zozoR> isnt C broken?  :D
11:49 < nsf> comparison operators have higher precedence than bitwise ops
11:49 < nsf> things like: x&mask == 0 won't work
11:50 < zozoR> (x&mask) == 0?
11:50 < nsf> (x&mask) == 0 should be written instead
11:50 < nsf> yes
11:50 < nsf> in Go it works
11:50 < zozoR> well, C is weird
11:50 < nsf> a little bit, yes
11:50 < zozoR> aiju said the other day "in soviet C namespace pollutes you"
11:51 < zozoR> i am the honored owner of a t-shirt that says that now :D
11:51 < zozoR> unfortunatly, nobody gets the joke : |
11:51 < nsf> I'm afraid in soviet russia we're using pascal instead
11:51 < nsf> :D
11:51 < zozoR> :D
11:52 < nsf> I think eastern europe is the only place where teachers still
teach pascal in schools
11:53 < zozoR> they should teach go
11:54 < nsf> maybe, I don't have opinion on that
11:55 < nsf> pascal isn't the worst choice btw
11:55 < nsf> it's better than java
11:56 < zozoR> well, i only hear people bash java all the time
11:56 < nsf> :D
11:57 < nsf> and C++, I hate C++
11:57 * nsf is writing a parser in C++ right now
11:57 < nsf> I hate it and I use it
11:57 < nsf> :D
11:59 < zozoR> i feel hate for C++ too
11:59 < zozoR> dont know why though
11:59 < Namegduf> C++ is extremely complex.
11:59 < Namegduf> It's basically C plus all the features.
11:59 < Namegduf> All of them.
11:59 < nsf> :)
12:00 < Namegduf> So you have the fun of manually writing low-level code
with the fun of a very complex language.
12:05 < nsf> C is the "programmer is always right", C++ is the "compiler is
always right"..  and what you do as a programmer is standing in the middle of this
12:06 < xyproto> I'm trying out goinstall for the first time.  How can I
install, for example Go-SDL with it?  I can't seem to make it work.
12:06 < nsf> and by C++ here I mean everything that was added on top of C
12:07 < xyproto> I just get: goinstall: github.com/banthar/Go-SDL: package
has no files
12:10 -!- karpar [~karpar@] has joined #go-nuts
12:12 < nsf> xyproto: goinstall may not work with all packages
12:12 < nsf> it's a hack basically
12:12 < nsf> a try to make a smart build system
12:12 -!- rlab [~Miranda@] has quit [Ping timeout: 252 seconds]
12:13 < nsf> apparently not a very smart idea
12:13 -!- rlab [~Miranda@] has joined #go-nuts
12:15 -!- napsy [~luka@tm.] has quit [Ping timeout:
260 seconds]
12:16 < zozoR> nsf, why does people hate java?
12:17 < nsf> I don't know...  I don't know java
12:17 < nsf> :)
12:17 < nsf> I guess for its oververbosity
12:17 < nsf> public static final int wtf();
12:17 < nsf> srsly?
12:18 -!- photron [~photron@port-92-201-10-205.dynamic.qsc.de] has quit [Read
error: Operation timed out]
12:18 < nsf> C# is the same idea
12:18 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has quit [Ping timeout: 276
12:18 < zozoR> ^^
12:19 < zozoR> well, C# is supposed to be written with visual studio.  ie.
drag and drop code
12:19 -!- aho [~nya@fuld-590c7e54.pool.mediaWays.net] has quit [Quit:
12:19 < zozoR> visual studio writes all the public static final function for
you, so you only need to write actual code
12:21 < zozoR> i dont like programs that writes my code : (
12:22 < nsf> yeah
12:22 < nsf> I've seen a bunch of screencasts about C# and VS
12:22 < nsf> it looks weird really
12:23 < zozoR> well, you can make a lot of code fast
12:23 < nsf> a lot of buggy code
12:23 < zozoR> partial class..  yuck -.-
12:24 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has quit [Ping timeout: 255
12:24 < zozoR> we are taught java on our universities (unless you are to
study software)
12:25 < nsf> yep, I'm aware of that
12:25 < nsf> bad for you
12:25 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has joined #go-nuts
12:26 < zozoR> i once read about a place where they could chose whatever
langauge they wanted
12:26 < nsf> heaven?  :)
12:26 < zozoR> nope xD
12:26 < nsf> lol
12:26 < zozoR> maybe it was just the assignment, but they had to make an
http server
12:26 < zozoR> they could only get help if they used java
12:27 < zozoR> one guy chose python, write "import simplehttpserver" and
"simplehttpserver.start()" or something
12:27 < zozoR> im pretty sure that there is a python lib for that
12:27 < nsf> :)
12:27 < zozoR> and that is why you are not allowed to use whatever language
you want :D
12:28 < aiju> hahahahaahahaha
12:28 < aiju> there is no such thing as a simple HTTP server
12:28 < aiju> HTTP is fucking insane
12:29 < aiju> [12:55:12] <nsf> I think eastern europe is the only
place where teachers still teach pascal in schools
12:29 < aiju> germany is part of eastern europe?
12:29 < zozoR> yea
12:29 < nsf> aiju: I don't think so
12:30 < zozoR> soviet germany
12:30 < aiju> i've been taught Pascal in school
12:30 < nsf> let me check out the map :)
12:30 < aiju> and i'm not an exception
12:30 < nsf> "Germany is a country in Western and Central Europe."
12:30 < aiju> Basic, Pascal, Prolog, Java, Assembler, C are the languages
classically taught at german schools
12:30 < nsf> wiki says it's not
12:31 < aiju> (in decreasing order)
12:31 < nsf> aiju: well, good then, I was wrong about eastern europe only
12:31 < aiju> 13:29 < zozoR> [12:53:29] i am the honored owner of a
t-shirt that says that now :D
12:31 < aiju> hahahahhaahaahahha awesome
12:32 < zozoR> you wont believe how many just stares at my t-shirt for
fifteen seconds, then go "what" xD
12:32 < aiju> C's precedence rules are a relict of B btw
12:34 < mpl> for the record, they still teach pascal in some unis here as
well (.fr).
12:34 < aiju> in some unis?  oh wow
12:34 < aiju> german unis only teach Java and C
12:34 < aiju> i've been talking about high schools
12:35 < aiju> (and functional languages like Scheme ofc)
12:35 < mpl> ah, we don't have any cs courses in high school that I know of.
12:35 < xyproto> they tought Pascal/Delphi at unis here in Norway up until
around 5 years ago
12:35 < aiju> i find it amazing that Prolog made it into the curriculum
12:35 -!- frewsxcv [~frewsxcv@] has joined #go-nuts
12:35 -!- frewsxcv [~frewsxcv@] has quit [Changing host]
12:35 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has joined #go-nuts
12:37 < xyproto> I want to write a small game in Go. Like Tetris or Digger.
Where to start?
12:38 < xyproto> What would you use for graphics?  HTML5+canvas+Go backend?
SDL?  OpenGL?
12:38 < zozoR> ncurses!  :D
12:38 < nsf> https://github.com/nsf/gotris
12:38 < nsf> fix that one
12:38 < xyproto> as much as I like ncurses...  ;)
12:38 < aiju> ncurses is a shame
12:38 < mpl> when I was applying for one of these masters where they were
mainly using pascal as a teaching language, I asked them at the interview why they
were not using a "useful for real life" language like C. maybe that's why I didn't
get accepted :)
12:38 < xyproto> nfs: I'll take a look
12:38 < aiju> ncurses had a point when we all used VT100 to connect to our
12:39 < nsf> xyproto: it's broken because of language changes, I'm not
maintaining it
12:39 < xyproto> ncurses works everywhere, though.  And the
ncurses-interfaces are usually highly responsive.
12:39 < aiju> mpl: hahahahaha
12:39 < nsf> other than that it's fully functional tetris on SDL+OpenGL
12:39 < aiju> xyproto: it doesn't work on my trusty ASR-33 :(
12:39 < Urmel|>
<- simple sdl 1.3 wrapper for great justice
12:39 < xyproto> aiju: I had to google it.  It looks like a printer?
12:40 < Urmel|> although youll have to tweak it a bit for your own use
12:40 < aiju> xyproto: a hardcopy terminal
12:40 < aiju> basically a terminal with a typewriter for output
12:40 < aiju> used in the early days of UNIX
12:40 -!- boscop [~boscop@f050135026.adsl.alicedsl.de] has joined #go-nuts
12:41 < zozoR> nsf, do you know if gosdl is fully functional?
12:41 < nsf> have no idea
12:43 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has joined #go-nuts
12:43 * aiju hopes that his emulator still works
12:43 < schmrkc> zozoR: What do you mean with "fully functional" here
12:43 < aiju> fuck, ofc not
12:43 < aiju> schmrkc: LISPy!
12:43 < zozoR> meaning you can use the library as much as you can use it
from c++ or c
12:44 < aiju> you can use SDL, have i missed something?  ;P
12:44 < aiju> w00t it still works
12:45 < schmrkc> zozoR: Not all of the SDL library is there, no.  But any
extra function that you find missing should be easy enough to add.
12:45 < schmrkc> zozoR: for example the joystick support is not there.
12:45 < aiju> http://phicode.de/git/?p=gb.git;a=summary btw
12:45 < zozoR> who uses joysticks for puters :D
12:46 < schmrkc> zozoR: I use my playstation gamepad all the time.
12:46 < schmrkc> zozoR: It is detected as a joystick device on looniks
12:46 < aiju> - c.F = FLAGZ
12:46 < aiju> + c.F |= FLAGZ
12:46 < aiju> that bug was really fun to find
12:46 < zozoR> oh
12:46 < schmrkc> aiju: haha :D
12:46 < aiju> schmrkc: esp.  since c.F was 0 in 255/256 cases....
12:47 < schmrkc> zozoR: I'm pretty sure there are some other functions with
no go bindings yet..  but SDL is a very easy library, and even with my lack of Go
knowledge I could make some bindings if they were missing.
12:48 < zozoR> true that
12:48 < schmrkc> then again I have written SDL libraries several times for
other random languages ;)
12:48 < zozoR> ill play around with it later perhabs ^^
12:48 < schmrkc> uh
12:48 < schmrkc> SDL bindings.
12:48 < schmrkc> yay.
12:48 < schmrkc> me too.
12:48 < schmrkc> I need it for my hello roguelike.
12:48 < zozoR> because it is time for homework to be done ^^
12:48 < aiju> bleh SDL
12:49 < schmrkc> aiju: You no like the SDL?
12:49 < aiju> not really
12:49 < schmrkc> Is there some better alternative?
12:49 < aiju> no :(
12:49 < schmrkc> :D
12:49 < zozoR> -.-
12:49 < aiju> that's why I end up using it
12:50 < schmrkc> someone suggested allegro to me quite some time ago..  but
it was troublesome.  I forget what the issuew as.
12:50 < aiju> tho some of my programs use libdraw
12:51 < schmrkc> never herad of libdraw
12:51 < aiju> Plan 9 library
12:51 < schmrkc> oho.  only for drawing I imagine?
12:51 < aiju> yeah
12:51 < aiju> i don't use SDL for audio et al
12:51 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has quit [Ping timeout: 246
12:52 < schmrkc> I'd think SDL was mainly used for drawing sprites and such
12:52 < schmrkc> perhaps libdraw does this too.
12:52 < aiju> libdraw has a blit function
12:52 < aiju> http://man.cat-v.org/plan_9/3/draw
12:52 < schmrkc> although it seems now SDL is mostly just used as a
"backend" for getting some openGL context
12:52 < aiju> yuck wrong section
12:52 < aiju> http://man.cat-v.org/plan_9/2/draw
12:52 < aiju> i don't have too many opengl capable machines
12:53 * schmrkc nods nods.
12:53 < schmrkc> it is quite beneficial even for 2d games.
12:53 < aiju> yes
12:53 < aiju> i still don't have any machines for it
12:53 < aiju> well, i have ONE
12:53 < schmrkc> So plan9 eh?  Useable as a "desktop" OS?
12:53 -!- yebyen [~yebyen@martyfunkhouser.csh.rit.edu] has joined #go-nuts
12:53 < aiju> depends what you do with your desktop
12:53 < schmrkc> really dumb question?  :)
12:53 < schmrkc> right.
12:54 < schmrkc> run chrome, read mah mail.  hack code.  transfer stuff on
and off my mp3player and digital camera.
12:54 < schmrkc> ssh and irssi ;)
12:54 < aiju> no multimedia, no real webbrowser (hm you can run Opera in
linuxemu), no office suite
12:54 < schmrkc> ah right.
12:54 < aiju> chrome might work in linuxemu as well
12:54 < Urmel|> only SDL 1.2 is used as mainly a backend for an opengl
context btw
12:54 < aiju> you can code C ;P
12:54 < schmrkc> Urmel|: oh ok.
12:54 < Urmel|> sdk 1.3 has it's own 2d renderer using opengl or directx
(and some other stuff)
12:55 < schmrkc> aiju: Well I'll stay on the looniks then :)
12:55 < Urmel|> sdl*
12:55 < aiju> schmrkc: a Go port is coming ...
12:55 < schmrkc> Urmel|: Sounds cool.  I'm going to check this out.  Is
there much change in the API?
12:55 < schmrkc> hmmm
12:55 < Urmel|> yeah a lot
12:55 < aiju> my PLan 9 machine is probably too slow for Go :D
12:55 < aiju> those frigging 2 MB binaries
12:56 < schmrkc> Urmel|: I think I remember some discussion about this in
#lispgames.  Some license change too is there?
12:56 < schmrkc> 2 MB! crazy!
12:56 < schmrkc> :D
12:56 -!- sauerbraten [~sauerbrat@p508C9E90.dip.t-dialin.net] has joined #go-nuts
12:56 < aiju> i only have 2 MB/s HD access on that machine
12:56 < Urmel|> schmrkc, well you can buy permission to statically link
12:56 < schmrkc> that sounds painful.
12:56 < schmrkc> Urmel|: oh ok.
12:56 < Urmel|> but dynamic linking is still free as always
12:56 < xyproto> When I compile the latest version of Go-SDL, with the
latest version of Go (7647), the executable in the SDL-Go test-directory just
says: zsh: permission denied: ./test
12:56 < aiju> SDL is LGPL?  BLAH
12:56 < xyproto> What could be the reason?
12:56 < aiju> LGPL is the fucking worst
12:57 < schmrkc> Urmel|: I guess people just get their panties in a twist
over nothing then.
12:57 < Urmel|> yup
12:57 < schmrkc> I find LLGPL quite ok.
12:57 < aiju> xyproto: no +x permission?
12:57 < aiju> LGPL is even worse than GPL per se
12:57 < aiju> as it puts dynamic linking over static linking
12:57 < Urmel|> the great thing about sdl 1.3 is that you use the same calls
for both opengl and directx rendering and just easily switch between them
12:57 < xyproto> aiju: -rwxr-xr-x
12:57 < aiju> xyproto: dynamic linker stuff?
12:57 < schmrkc> aiju: GPL is very troublesome for lisp.  (:
12:57 < aiju> xyproto: readelf foo | grep interpreter
12:58 < schmrkc> Urmel|: Sounds very nice indeed.
12:58 < xyproto> aiju: probably, but how do I figure that one out?  ...
I'll try readelf, thanks
12:58 < aiju> eh readelf -a
12:58 -!- ronny [~quassel@p4FF1C0D9.dip0.t-ipconnect.de] has joined #go-nuts
12:58 < xyproto> aiju: there's only one line for that: [Requesting program
interpreter: ../gfx/_obj]
12:59 < aiju> yeah
12:59 < aiju> seems broken to me
12:59 < schmrkc> Urmel|: finding the 1.3 docs a bit lacking :D
12:59 < aiju> should be something like /lib/ld-linux.so.2
12:59 < xyproto> aiju: okay.  Hm, I wonder why.  Does gdb work with Go?
12:59 < aiju> xyproto: more or less
13:01 < Urmel|> yup that is true schmrkc
13:02 < xyproto> My goal is to make a small tetris or digger clone, but the
OpenGL and SDL examples all fail.  Perhaps ncurses really is the way to go.
13:02 < aiju> hahahaha
13:02 < aiju> i've got SDL working here
13:02 < aiju> that 0xf9-something SDL
13:03 < xyproto> aiju: do you have the latest version of Go?
13:03 -!- perdiy [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the
13:03 < aiju> should be relatively new
13:03 < xyproto> aiju: some of the examples have worked sometimes here,
after updating, but they never work all at the same time :)
13:03 < aiju> hahahah
13:05 < xyproto> I wish GPU-hardware were considered important enough to be
supported directly from languages like Go and Python, not being delegated as
special external packages.
13:05 < aiju> hahahahahahahahahaha
13:05 < aiju> i wish not
13:05 < aiju> GPUs are not CPUs
13:05 < aiju> they need a DSL
13:06 < xyproto> aiju: damn small linux?
13:06 < aiju> domain-specific language
13:06 < nsf> :)
13:06 < xyproto> aiju: digital subscriber line?
13:06 < xyproto> they are getting closer, though
13:06 < xyproto> with OpenCL and everything :P
13:06 < xyproto> okay, not closer to not needing a DSL
13:06 < aiju> i'd like to see an APL dialect for GPUs
13:06 < xyproto> but more suitable for general purpose computing
13:07 < aiju> last time i looked they looked *just* like APL hardware
13:08 < schmrkc> hmm..
13:08 < schmrkc> GPU for general purpose computing?  I dunno..
13:08 < aiju> on a side note, i don't have GPGPU capable hardware
13:08 < aiju> y'all are just filthy rich bastards ;P
13:09 < schmrkc> yup.
13:10 < schmrkc> the low end nvidia cards are not that expensive :P
13:10 < schmrkc> It's sad really.  all this fancy hardware and so much
bloat.  Life was better back in the days when one actually *used* the lil
computing power one had :)
13:11 < aiju> i'm currently writing an OS for the 8086 for fun
13:11 < aiju> 640 KB of RAM yay!
13:11 < xyproto> aiju: I work for a company that specializes in utilizing
GPUs for visualizing and converting seismic data.  GPUs are a big deal.
13:12 < aiju> xyproto: i've only looked at opencl and didn't like it
13:12 -!- karpar [~karpar@] has quit [Quit: Bye!]
13:13 < xyproto> aiju: perhaps CUDA is more likeable?  But, OpenCL can
fallback on the CPU, which is nice.
13:13 < schmrkc> aiju: fun hobby (:
13:14 < xyproto> aiju: remember to implement int 19h for reboots ;)
13:14 < aiju> it will have multitasking btw!
13:14 < aiju> just showing how much DOS sucks :>
13:15 < aiju> and that the suckage can't be explained by "the hardware
wasn't good enough"
13:15 < xyproto> at least it was possible to make a tetris game without
installing libraries...  ;)
13:15 < aiju> heh
13:15 < xyproto> good old a000
13:16 < aiju> i actually wrote a tetris in assembly for DOS
13:16 -!- perdix [~mkhl@g227011248.adsl.alicedsl.de] has joined #go-nuts
13:16 < aiju> http://aiju.phicode.de/up/tetris.asm.txt
13:16 -!- perdix [~mkhl@g227011248.adsl.alicedsl.de] has quit [Changing host]
13:16 -!- perdix [~mkhl@sxemacs/devel/perdix] has joined #go-nuts
13:16 < xyproto> aiju: in mode 01, regular text mode?
13:17 < aiju> i think so
13:17 < aiju> look at the code :o)
13:17 < xyproto> aiju: just did.  Just wondered why text mode :)
13:17 < aiju> well, it's simple
13:17 < xyproto> I have fond memories of 16-bit x86 assembly
13:18 < aiju> i need nothing but coloured tiles
13:18 < aiju> i don't like it too much
13:18 < aiju> it's terribly unorthogonal
13:18 < xyproto> true
13:18 < aiju> PDP-11 is much more fun
13:19 < aiju>
13:19 < aiju> very simplified regex compiler in PDP-11
13:20 -!- tensai_cirno [~cirno@] has joined #go-nuts
13:28 -!- mattn_jp [~mattn@s60.BMT-e1.vectant.ne.jp] has joined #go-nuts
13:33 * steven jumps for joy
13:37 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts
13:41 < ww> can we run go on a pdp11?
13:41 < aiju> hahahaha
13:41 < aiju> probably not
13:42 < aiju> 2 MB of runtime don't fit in a 64 KB address space :)
13:42 < steven> i realized a graceful solution this morning for the problem
i had last night, of my data-fetching goroutines not having a way to signal that
they want to quit..
13:43 < steven> they could just close their writing channel!
13:43 < ww> steven: yes!
13:43 < steven> :)
13:44 < ww> for { foo := <- ch; if closed(ch) { break } }
13:44 < steven> no
13:44 < steven> we should not use if closed()..
13:44 < aiju> never ever check closed
13:44 < ww> that's on the reading side
13:44 < aiju> or Pike will rip off your head
13:44 < steven> if foo, ok := <- ch; ok { break }
13:44 < steven> wait, !ok
13:45 < steven> aiju: right?
13:45 < aiju> probably
13:45 < aiju> depends what break does ;P
13:45 < steven> assuming break isnt in question ;)
13:45 < aiju> well, it really depends how you structure your code
13:45 < aiju> if you want to break if it's closed, than it's right
13:46 < ww> "never ever check closed" -- why do we have closed() then?
13:46 < aiju> ww: it'll go
13:46 < steven> ww: because of the way closed() works.
13:46 < steven> "After at least one such zero value has been received,
closed(c) returns true."
13:46 < ww> steven: right, that's why we read from the channel first
13:46 < steven> so closed() will return false after a close() statement,
until its read from at least one more time.
13:47 < steven> which is why the comma ok idiom works perfectly here, since
it does a rad.
13:47 < steven> *read
13:47 < aiju> using closed() is just asking for a race condition
13:47 < steven> right.
13:47 < steven> which i found out the hard way last night.
13:47 < steven> so i have my code working much better now, thanks a lot to
some awesome guys in here last night who didnt kick me for my verbosity
13:47 < ww> hmmm....  actually...  i wonder if my mysterious error that i'm
tracking down right now is such a race...
13:48 * ww fixes and checks...
13:48 < ww> hmmm...  not quite: cannot use multiple-value assignment for
non-blocking receive; use select
13:48 < steven> https://gist.github.com/857298
13:49 < steven> ww: another thing i learned last night;
13:49 < steven> ONLY a goroutine who is allowed to send to a channel should
close it.
13:49 < ww> steven: of course
13:50 < Namegduf> More specifically, closing only works when there's either
only one writer or the writers coordinate to know to stop sending
13:50 < steven> i found out because i was having an error due to this code:
13:50 < steven> Namegduf: right on.
13:50 < Namegduf> If you're not the "writer", you need to communicate with
the writers so they know.
13:50 < steven> which means, i have no idea how to implement a multi-writer
chan that i can close safely
13:51 < steven> (though to be honest, it doesnt seem like a bad thing to
have a non-closed channel, so long as its GC'd properly)
13:51 < Namegduf> It isn't.
13:51 < Namegduf> close() is a useful thing you *can* optionally use to tell
a reader to stop reading.
13:51 < Namegduf> Without making zero values illegal or such.
13:52 < Namegduf> But it's not required, not the equivalent of close() in an
open()/close() where you should have one for every open().
13:53 < Namegduf> Multi-writer the easiest thing to do is not to use close()
in yoru designs
13:53 < Namegduf> *your
13:54 < steven> woo, i just came up with another cool solution..  i can
defer my quit channel being closed instead of manually closing it whenever i
return from my loop..  https://gist.github.com/857298
13:55 < ww> hmmm...  so how do i do a blocking receive then, that should
block until either a value is received or the channel is closed?
13:57 < Namegduf> That's the default.
13:58 < ww> so how do i distinguish between a zero-value and a closed
13:58 < Namegduf> You can call closed().
13:58 < ww> (without using closd())
13:58 < ww> but..  but...
13:58 < aiju> foo, ok := ...
13:58 < Namegduf> foo, ok := is the new syntax for it
13:58 < Namegduf> Not added yet, I think
13:58 < aiju> orly?
13:58 < Namegduf> It used to do a non-blocking receive
13:59 < Namegduf> I don't know, I could be outdated.
13:59 < ww> Namegduf: not added in most recent release anyways: cannot use
multiple-value assignment for non-blocking receive; use select
14:00 < Namegduf> Yeah, they took out non-blocking receive for a while so as
to break existing code
14:00 < ww> right.  so until it is added back, use closed()
14:00 < Namegduf> Before adding foo, ok := <-blah as a way to do a
receive and check closed.
14:00 < xulfer> Speaking of.  Do they have anything implemented or on the
way regarding backgrounding a process?  Other than doing the raw fork syscall of
course (which is risky).
14:00 < ww> (where back means replaced)
14:00 < Namegduf> They'll be removing closed(), I think.
14:00 < Namegduf> People keep trying to do wrong things, like close channels
in the reader
14:01 < Namegduf> To send messages to the writer
14:01 < ww> but in the meantime, the only way to do it is to check closed on
the reader
14:01 < Namegduf> I think ranging over the channel and select might work.
14:01 < Namegduf> But yeah, otherwise...
14:01 < Namegduf> And you're right, there's a race condition with zero
values that way.
14:02 < ww> Namegduf: that changes it into a non-blocking call...  which in
my case i don't want
14:02 < Namegduf> Not automatically.
14:02 < ww> if there is a default:
14:02 < Namegduf> select{} is only non-blocking with a default.
14:02 < steven> wait, why doesnt "input, ok := <- remoteChan" work in a
case statement?
14:03 < aiju> steven: it doens't exist yet haha
14:03 < aiju> sorry for being misinformed
14:03 < Namegduf> It's not added yet.  Planned, but not added so as to let
people realise the old v, ok := <-chan syntax is gone and update.
14:04 < steven> daaaaang.
14:04 < ww> so to summarise, for { x := <- ch; if closed(ch) { break }
...  } is the way to do it on the receiver end until the new syntax is put in
14:04 < steven> well its ok, because having done a receive already in the
select makes closed() safe.
14:04 < Namegduf> Note that with multiple readers there is a race condition.
14:05 < steven> directly after a receive, closed() is safe.  and inside a
select case, you've already done a receive.  so its inherently ok.
14:05 < Namegduf> If you send zeroes.
14:05 < steven> Namegduf: how so?
14:05 < Namegduf> No, it's only safe with only one reader.
14:05 < ww> in my case not a problem...
14:05 < steven> mine too, i only have one reader
14:05 < steven> but im confused.
14:05 < Namegduf> Send zero, send two, close- you receive zero, another
reader gets the two and the close's zero value, context switches back to you.
14:05 < Namegduf> You check closed(), you detect it's closed.
14:06 < Namegduf> You discard the legitimate zero value.
14:06 < steven> touche.
14:06 < steven> the comma ok trick wont solve that problem though, will it?
14:06 < ww> and as it turns out, my problem is interaction between memory
management in c and the go GC...
14:06 * ww refactors
14:06 < Namegduf> It will, because it will be atomic.
14:06 < steven> oh yeah it will becuase it combines them into one statement,
which means they will go hand in hand every single time.
14:06 < Namegduf> Yes.
14:06 < steven> right?
14:06 < Namegduf> Yep.
14:07 < Namegduf> There's no room for that other reader to do an unlimited
amount of stuff between the read and the closed(), so to spea.
14:07 < Namegduf> *speak
14:07 -!- hcatlin [~hcatlin@host86-145-112-33.range86-145.btcentralplus.com] has
joined #go-nuts
14:07 -!- hcatlin [~hcatlin@host86-145-112-33.range86-145.btcentralplus.com] has
quit [Changing host]
14:07 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has joined
14:19 -!- steevel [steevel@yahoe.se] has quit [Quit: leaving]
14:23 -!- napsy [~luka@] has joined #go-nuts
14:23 -!- yugui___ [~yugui@yugui.jp] has quit [Quit: Tiarra 0.1+svn-24729: SIGTERM
received; exit]
14:23 < steven> ha, i wrote this awful stuff months ago..
14:24 -!- yugui [~yugui@yugui.jp] has joined #go-nuts
14:26 < steven> channel-comma-ok idiom is also useful for givin a close-only
channel to one sender and multiple readers.
14:26 < steven> i think
14:30 < skelterjohn> morning
14:30 < xyproto> good afternoon
14:31 < aiju> How are you gentlemen!!
14:31 < skelterjohn> for that kind of thing, steven, i feel like something
from the sync package would be more appropriate
14:31 < skelterjohn> i'm ok
14:35 -!- foocraft [~dsc@dyn-86-36-42-96.wv.qatar.cmu.edu] has quit [Quit:
14:36 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has quit [Quit:
14:42 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has joined
14:46 < tobier> are there any good tutorials for HTMl templates?  the
codelab wiki implementation doesn't work as is
14:47 -!- tensai_cirno [~cirno@] has quit [Ping timeout: 246
14:49 -!- karpar [~karpar@] has joined #go-nuts
14:51 < tobier> actually, there is a bug in the codelab
14:51 < tobier> the paramaters to the template Execute are switched
14:59 -!- nettok [~quassel@] has joined #go-nuts
15:06 -!- karpar [~karpar@] has quit [Quit: Bye!]
15:06 -!- hcatlin [~hcatlin@pdpc/supporter/professional/hcatlin] has quit [Quit:
15:16 -!- rurban [~chatzilla@178-191-149-74.adsl.highway.telekom.at] has joined
15:25 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has joined #go-nuts
15:27 -!- visof__ [~visof@] has quit [Remote host closed the
15:40 -!- saschpe [~quassel@opensuse/member/saschpe] has quit [Remote host closed
the connection]
15:44 -!- skejoe [~skejoe@] has joined #go-nuts
15:51 -!- tensai_cirno [~cirno@] has joined #go-nuts
15:54 -!- brad_ [~brad@cpe-098-026-053-035.nc.res.rr.com] has quit [Quit: leaving]
15:54 -!- rlab [~Miranda@] has quit [Ping timeout: 260 seconds]
16:08 < rurban> Now I have a bit more time to complete my cygwin port
16:09 -!- rlab [~Miranda@] has joined #go-nuts
16:18 -!- sauerbraten [~sauerbrat@p508C9E90.dip.t-dialin.net] has quit [Read
error: Operation timed out]
16:26 -!- DerHorst [~Horst@e176102247.adsl.alicedsl.de] has quit [Remote host
closed the connection]
16:27 -!- mattn_jp [~mattn@s60.BMT-e1.vectant.ne.jp] has quit [Remote host closed
the connection]
16:30 -!- photron [~photron@port-92-201-10-205.dynamic.qsc.de] has joined #go-nuts
16:35 -!- Cromulent [~Cromulent@cpc8-reig4-2-0-cust24.6-3.cable.virginmedia.com]
has joined #go-nuts
16:35 -!- shvntr [~shvntr@] has quit [Ping timeout: 248 seconds]
16:36 -!- Cromulent [~Cromulent@cpc8-reig4-2-0-cust24.6-3.cable.virginmedia.com]
has quit [Quit: Cromulent]
16:38 -!- shvntr [~shvntr@] has joined #go-nuts
16:44 < ww> to what extent is calling into go from c thread safe?
16:52 -!- mutenewt [~mutenewt@adsl-99-22-110-84.dsl.chcgil.sbcglobal.net] has
joined #go-nuts
16:57 < skelterjohn> if you mean a c program invoking go code, doesn't
happen yet
16:57 < skelterjohn> if you mean a go program invoking c code that calls
some go code, can you do that?  i dunno
16:57 < skelterjohn> but if you can, there is nothing inherently
non-threadsafe about it
16:57 < skelterjohn> no more than usual, anyway
16:58 < skelterjohn> what problems do you foresee?
16:58 -!- femtooo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Read error:
Connection reset by peer]
17:00 -!- deso_ [~deso@x0561a.wh30.tu-dresden.de] has joined #go-nuts
17:01 -!- chomp [~ken@c-71-206-216-232.hsd1.pa.comcast.net] has joined #go-nuts
17:22 < ww> skelterjohn: as usual, the hitch is with callbacks...
17:23 < ww> so there's this c library that parses some type of file.
17:23 < ww> you give its parsing function a callback (implemented in go)
17:23 < ww> the callback takes a record and sends it off over a channel
17:24 < ww> so there's a goroutine running the parsing function, and this
parsing function calls back into go
17:25 < ww> "call back into go" -> no guarantee that the called back
goroutine is running in the same OS thread as the parsing function that calls it,
17:25 < chomp> dubious
17:31 -!- ExtraSpice [XtraSpice@78-62-101-194.static.zebra.lt] has quit [Read
error: Connection reset by peer]
17:32 -!- shvntr [~shvntr@] has quit [Quit: leaving]
17:39 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
17:42 -!- espeed [~espeed@] has quit [Quit: Leaving]
17:49 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has joined #go-nuts
17:50 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts
17:53 -!- _nil [~caine@c-67-189-251-116.hsd1.ct.comcast.net] has joined #go-nuts
17:53 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se]
has quit [Read error: Connection reset by peer]
17:54 -!- sauerbraten [~sauerbrat@p508C9E90.dip.t-dialin.net] has joined #go-nuts
17:54 < _nil> hey guys :)
17:55 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 250 seconds]
17:58 -!- zonax9 [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has joined #go-nuts
18:00 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has quit [Ping
timeout: 255 seconds]
18:00 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se]
has joined #go-nuts
18:02 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
18:06 -!- SetupLy [~setuply@] has joined #go-nuts
18:07 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has joined #go-nuts
18:14 -!- ymasory [~ymasory@c-76-99-55-224.hsd1.pa.comcast.net] has joined
18:14 -!- tsykoduk [~tsykoduk@c-98-232-28-167.hsd1.wa.comcast.net] has quit [Ping
timeout: 276 seconds]
18:19 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Ping
timeout: 264 seconds]
18:22 -!- SetupLy [~setuply@] has left #go-nuts []
18:28 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 264 seconds]
18:31 -!- Pete_27 [~noname@110-174-103-31.static.tpgi.com.au] has quit [Ping
timeout: 276 seconds]
18:31 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has joined
18:32 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the
18:33 -!- mutenewt [~mutenewt@adsl-99-22-110-84.dsl.chcgil.sbcglobal.net] has quit
[Quit: Leaving]
18:34 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
18:34 -!- deso_ [~deso@x0561a.wh30.tu-dresden.de] has quit [Read error: Operation
timed out]
18:42 < chomp> How might one go about waiting on either a child process to
exit or a buffered channel to have data
18:43 < chomp> I was trying to avoid polling with WNOHANG, but so far that's
my only solution
18:45 -!- tsykoduk [~tsykoduk@c-98-232-28-167.hsd1.wa.comcast.net] has joined
18:49 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Ping timeout: 260 seconds]
18:49 -!- tsykoduk [~tsykoduk@c-98-232-28-167.hsd1.wa.comcast.net] has quit [Ping
timeout: 252 seconds]
18:55 -!- tsykoduk [~tsykoduk@2001:470:1f04:671:20d:93ff:fe77:1dc4] has joined
18:55 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts
18:56 -!- StoneColdNinja [~idjit@cpe-68-174-246-95.si.res.rr.com] has joined
19:00 -!- StoneColdNinja [~idjit@cpe-68-174-246-95.si.res.rr.com] has quit [Remote
host closed the connection]
19:01 -!- Idjit [~idjit@cpe-68-174-246-95.si.res.rr.com] has joined #go-nuts
19:01 -!- boscop_ [~boscop@g227132192.adsl.alicedsl.de] has joined #go-nuts
19:02 < skelterjohn> chomp: if you launch a child process with exec.Run, you
get back an exec.Cmd that has a .Wait() function
19:02 < skelterjohn> and you can wait on a buffered channel by simply trying
to recv from it
19:02 < skelterjohn> it will block until there is something
19:03 < chomp> I'm using StartProcess, and the returned Process provides a
Wait() function as well - is that effectively the same thing?
19:03 < chomp> right, my goal is to wait on both, and continue when either
condition is met
19:04 < skelterjohn> then, in a goroutine, you call the process's Wait()
function - when it is read you send something over a channel
19:04 < chomp> the best i could think to do is have a goroutine doing the
Wait, and have it send to a second buffered channel, then select on both channels
19:04 < skelterjohn> somewhere else you select on both that channel and the
original buffered channel
19:04 < skelterjohn> well then
19:04 < chomp> heh
19:04 < skelterjohn> that seems like a good idea to me
19:04 -!- boscop [~boscop@f050135026.adsl.alicedsl.de] has quit [Ping timeout: 255
19:04 < chomp> but supposing that i continue on the original channel
condition.  i'd like to terminate the waiting goroutine
19:04 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined
19:05 < skelterjohn> terminating the original process should do so
19:05 < chomp> which i have attemted to accomplish by explicitly killing the
child process with a syscall.  that does not appear to be happening
19:06 < chomp> i might just be sending the wrong signal though, or perhaps
there's a more robust and idiomatic way to kill a process
19:06 < skelterjohn> Process.Release()?
19:07 < chomp> that does it?
19:07 < skelterjohn> guessing
19:07 < chomp> i looked at the implementation, seemed dubious
19:07 < skelterjohn> try it out
19:07 < chomp> will do
19:07 -!- Fish- [~Fish@9fans.fr] has joined #go-nuts
19:08 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host
closed the connection]
19:09 < chomp> hmm no dice
19:09 < chomp> maybe the child process is just being a bastard
19:11 < steven> is it possible in Go to define a sort of "abstract base
class" that one class uses and expects a concrete instance of to be given to it to
19:11 < steven> (if that makes sense)
19:12 -!- Project_2501 [~Marvin@] has joined #go-nuts
19:12 < chomp> nah.  if i manually send SIGUP to the process from the shell,
it dies and the go program operates normally, unblocking on Wait and cleaning up
19:13 < steven> oh, i thnk "interface" is exactly what im looking for
19:13 -!- perdix [~mkhl@sxemacs/devel/perdix] has joined #go-nuts
19:14 -!- __gilles [~gilles@poolp.org] has left #go-nuts []
19:19 < exch> steven: if you need to 'inherit' fields or methods from your
'base' type, you can embed the base type in the new type.
19:21 < exch> http://pastie.org/1640258 like this
19:26 -!- Idjit [~idjit@cpe-68-174-246-95.si.res.rr.com] has left #go-nuts []
19:26 -!- cco3 [~conley@c-69-181-140-72.hsd1.ca.comcast.net] has joined #go-nuts
19:35 < skelterjohn> but you have to be careful - that doesn't give you
19:35 < skelterjohn> if you convert it back to the base class, you'll use
the base class methods again
19:39 < exch> yup.  its the closest thing go has to polymorphism
19:40 < skelterjohn> you can combine that with interfaces to get the
behavior you're looking for
19:48 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has joined #go-nuts
19:54 < steven> exch, skelterjohn: right on
19:54 < steven> thanks
19:55 < steven> i dont want polymorphism..  i just wanted to get "protocol"
(objc terminology) or "interface" (java terminology) behavior
19:55 < steven> so im experimenting with interfaces for a minute
19:55 -!- cco3 [~conley@c-69-181-140-72.hsd1.ca.comcast.net] has quit [Ping
timeout: 252 seconds]
20:02 -!- sauerbraten [~sauerbrat@p508C9E90.dip.t-dialin.net] has quit [Remote
host closed the connection]
20:04 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the
20:07 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has joined
20:07 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4]
20:08 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has quit
[Remote host closed the connection]
20:12 -!- aimxhaisse [~mxs@buffout.org] has quit [Quit: leaving]
20:12 -!- aimxhaisse [~mxs@buffout.org] has joined #go-nuts
20:16 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-165-31.clienti.tiscali.it] has
joined #go-nuts
20:19 -!- exch [~exch@h78233.upc-h.chello.nl] has quit [Quit: leaving]
20:20 -!- Project_2501 [~Marvin@] has quit [Ping timeout: 276 seconds]
20:31 -!- exch [~exch@h78233.upc-h.chello.nl] has joined #go-nuts
20:31 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-170-135.clienti.tiscali.it] has
joined #go-nuts
20:34 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-165-31.clienti.tiscali.it] has
quit [Ping timeout: 248 seconds]
20:36 -!- vsayer [~vivek@c-76-102-205-58.hsd1.ca.comcast.net] has quit [Quit:
20:48 -!- femtoo [~femto@95-89-198-8-dynip.superkabel.de] has quit [Read error:
Connection reset by peer]
20:54 -!- jlouis [jlouis@horus.0x90.dk] has quit [Remote host closed the
21:00 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has quit [Read error:
Operation timed out]
21:00 -!- frewsxcv [~frewsxcv@] has joined #go-nuts
21:00 -!- frewsxcv [~frewsxcv@] has quit [Changing host]
21:00 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has joined #go-nuts
21:01 -!- yugui_zzz [~yugui@yugui.jp] has quit [Ping timeout: 252 seconds]
21:03 -!- yugui_zzz [~yugui@yugui.jp] has joined #go-nuts
21:07 < steven> guys,
21:08 < steven> is it a bad idea to pass around a net.Conn object?  should i
pass a *net.Conn instead?  does passing a plain net.Conn object make extraneous
copies that should be avoided?
21:08 < steven> or worse, does passing around that object between functions
actually create copies of the connection object that dont contain the state of
that object?
21:10 < steven> oh good, its only a pointer.
21:11 < aiju> A wild pointer appears!
21:11 < steven> actually no, net.Conn is an interface
21:11 < steven> the actual object i have is probably *net.TCPConn which is a
ptr to a struct that just has a file descriptor
21:19 -!- perdix [~mkhl@sxemacs/devel/perdix] has joined #go-nuts
21:22 < Namegduf> steven: I'm pretty sure copying an interface will just
copy the two-word thing
21:23 < Namegduf> The thing inside the interface is actually immutable
21:24 < Namegduf> If it's a pointer you can change what it's pointing at but
whenever you do anything to the value inside the interface, you have to call a
method, passing it, or use a type assertion to assign it to something else, and
that copies it.
21:24 -!- foocraft [~dsc@] has joined #go-nuts
21:28 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has quit [Ping
timeout: 260 seconds]
21:29 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has joined #go-nuts
21:37 -!- bXi [bluepunk@irssi.co.uk] has joined #go-nuts
21:41 -!- jlouis [jlouis@horus.0x90.dk] has joined #go-nuts
21:45 -!- TheSeeker2 [~n@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has
joined #go-nuts
21:45 -!- TheSeeker [~n@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has quit
[Disconnected by services]
21:46 -!- ww_ [~ww@river.styx.org] has joined #go-nuts
21:46 -!- zozoR [~Morten@56346ed3.rev.stofanet.dk] has quit [Remote host closed
the connection]
21:48 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has quit [Ping timeout: 246
21:48 -!- madari_ [madari@AM.irc.fi] has joined #go-nuts
21:49 -!- XenoPhoe1ix [~Xeno@cpc13-aztw24-2-0-cust23.aztw.cable.virginmedia.com]
has joined #go-nuts
21:49 -!- enferex_ [~enferex@users.757.org] has joined #go-nuts
21:49 -!- htoothro- [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has joined
21:49 -!- tsung_ [~jon@] has joined #go-nuts
21:49 -!- anticw_ [~anticw@c-67-169-68-180.hsd1.ca.comcast.net] has joined
21:49 -!- kurt_ [kurt@acm.poly.edu] has joined #go-nuts
21:49 -!- grncdr_ [~stephen@sdo.csc.UVic.CA] has joined #go-nuts
21:50 -!- Maxdaman1us [~Maxdamant@203-97-238-106.cable.telstraclear.net] has
joined #go-nuts
21:50 -!- htoothrot [~mux@66-169-185-121.dhcp.ftwo.tx.charter.com] has quit [Ping
timeout: 250 seconds]
21:50 -!- XenoPhoenix [~Xeno@cpc13-aztw24-2-0-cust23.aztw.cable.virginmedia.com]
has quit [Ping timeout: 250 seconds]
21:50 -!- comex_ [comex@c-67-188-10-190.hsd1.ca.comcast.net] has quit [Ping
timeout: 250 seconds]
21:50 -!- tsung [~jon@] has quit [Ping timeout: 250 seconds]
21:50 -!- steven [~steven@unaffiliated/steven] has quit [Ping timeout: 250
21:50 -!- grncdr [~stephen@sdo.csc.UVic.CA] has quit [Ping timeout: 250 seconds]
21:50 -!- Paradox924X [~Paradox92@vaserv/irc/founder] has quit [Ping timeout: 250
21:50 -!- Maxdamantus [~Maxdamant@203-97-238-106.cable.telstraclear.net] has quit
[Ping timeout: 250 seconds]
21:50 -!- tensai_cirno [~cirno@] has quit [Ping timeout: 250 seconds]
21:50 -!- kurt [kurt@pdpc/supporter/active/kurt] has quit [Ping timeout: 250
21:50 -!- madari [madari@AM.irc.fi] has quit [Ping timeout: 250 seconds]
21:50 -!- enferex [~enferex@users.757.org] has quit [Remote host closed the
21:50 -!- anticw [~anticw@c-67-169-68-180.hsd1.ca.comcast.net] has quit [Ping
timeout: 250 seconds]
21:50 -!- ww [~ww@river.styx.org] has quit [Ping timeout: 250 seconds]
21:51 -!- comex [comex@c-67-188-10-190.hsd1.ca.comcast.net] has joined #go-nuts
21:52 -!- skejoe [~skejoe@] has quit [Quit: leaving]
21:52 -!- cco3 [~conley@c-69-181-140-72.hsd1.ca.comcast.net] has joined #go-nuts
21:54 -!- Paradox924X [~Paradox92@c-68-35-229-34.hsd1.fl.comcast.net] has joined
21:55 -!- Paradox924X [~Paradox92@c-68-35-229-34.hsd1.fl.comcast.net] has quit
[Changing host]
21:55 -!- Paradox924X [~Paradox92@vaserv/irc/founder] has joined #go-nuts
21:56 -!- rlab [~Miranda@] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
21:56 -!- steven [~steven@pidsley.praxxium.com] has joined #go-nuts
21:59 -!- Guest95361 [~quassel@p4FF1C0D9.dip0.t-ipconnect.de] has quit [Quit: No
Ping reply in 180 seconds.]
21:59 -!- ronny [~quassel@p4FF1C0D9.dip0.t-ipconnect.de] has joined #go-nuts
22:01 -!- tensai_cirno [~cirno@] has joined #go-nuts
22:01 < steven> guys,
22:02 < steven> how do you expand ~ in code via Go?
22:03 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has quit [Quit:
22:06 -!- cco3 [~conley@c-69-181-140-72.hsd1.ca.comcast.net] has quit [Ping
timeout: 260 seconds]
22:09 < KirkMcDonald> os.Getenv("HOME") perhaps.
22:09 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has quit [Quit: TheMue]
22:09 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has joined #go-nuts
22:09 < steven> thats what im doin, was wondering if it was the idiomatic
22:09 < KirkMcDonald> Though, that's not exactly the same thing.
22:09 < steven> right.
22:09 < KirkMcDonald> Since you can have e.g.  ~username
22:10 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has quit [Client Quit]
22:11 < KirkMcDonald> Go needs to steal more functions from Python's os.path
22:11 < KirkMcDonald>
22:12 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has joined #go-nuts
22:12 -!- TheMue [~TheMue@p5DDF6E8B.dip.t-dialin.net] has quit [Client Quit]
22:15 -!- awidegreen [~quassel@c-eacae555.08-2-73746f39.cust.bredbandsbolaget.se]
has quit [Ping timeout: 248 seconds]
22:17 -!- perdix [~mkhl@sxemacs/devel/perdix] has quit [Remote host closed the
22:18 < steven> i bet it would be really easy to write a competitor to
django and rails in Go
22:18 < steven> a quality competitor too
22:18 -!- dilenger [~dcheney@sydfibre2.atlassian.com] has joined #go-nuts
22:20 < KirkMcDonald> Does Go have a FastCGI library?
22:21 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-170-135.clienti.tiscali.it] has
quit [Quit: E se abbasso questa leva che succ...]
22:21 < dilenger> KirkMcDonald: nearly
22:22 < dilenger> i think someone was working on that very recently on the
22:23 < KirkMcDonald> I wonder if an approximate equivalent to Python's WSGI
would make sense in Go.
22:24 < dilenger> http://godashboard.appspot.com/package
22:24 < dilenger> there is a fastcgi impl there
22:27 -!- kurt [kurt@acm.poly.edu] has quit [Changing host]
22:27 -!- kurt [kurt@pdpc/supporter/active/kurt] has joined #go-nuts
22:29 -!- aho [~nya@fuld-590c62d1.pool.mediaWays.net] has joined #go-nuts
22:30 -!- Fish- [~Fish@9fans.fr] has quit [Quit: So Long, and Thanks for All the
22:38 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has joined #go-nuts
22:39 < cenuij> there are a few that will accept an fcgi request, web.go
22:41 < cenuij> though no working code that I know of in the public domain
to request fcgi from a go server
22:42 -!- photron [~photron@port-92-201-10-205.dynamic.qsc.de] has quit [Ping
timeout: 276 seconds]
22:42 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has quit [Remote host
closed the connection]
22:43 < cenuij> KirkMcDonald: is the overhead of parsing WSGI that much
better thanh FCGI?
22:43 -!- jumzi [~none@c-89-233-234-125.cust.bredband2.com] has joined #go-nuts
22:44 < KirkMcDonald> cenuij: The question suggests you are not familiar
with WSGI.  The two do different things.
22:44 -!- dfr|mac [~dfr|work@ool-182e3fca.dyn.optonline.net] has quit [Remote host
closed the connection]
22:44 < cenuij> KirkMcDonald: WSGI is a python gateway protocol?
22:44 < KirkMcDonald> cenuij: No, it is not.  It is a Python API.
22:44 < cenuij> ah
22:45 < KirkMcDonald> cenuij: The idea being that you can write a web
application against WSGI, then you can host that application using any
WSGI-compliant server.
22:45 < KirkMcDonald> This abstracts the application from the protocol.
22:45 < cenuij> ok, compliant servers being python servers?
22:46 < KirkMcDonald> cenuij: There is an Apache module, mod_wsgi.  There
are a couple of FastCGI-WSGI bridges.
22:46 < KirkMcDonald> There are CGI-WSGI bridges, as well.
22:46 < cenuij> ok, but I don't understand where this is not analagous to
22:46 -!- frewsxcv [~frewsxcv@] has joined #go-nuts
22:46 -!- frewsxcv [~frewsxcv@] has quit [Changing host]
22:46 -!- frewsxcv [~frewsxcv@unaffiliated/frewsxcv] has joined #go-nuts
22:46 < KirkMcDonald> cenuij: FastCGI is a wire protocol.
22:46 < KirkMcDonald> cenuij: WSGI is a Python API.
22:48 < KirkMcDonald> cenuij: Rather than writing a server which listens for
FastCGI requests, you just write some code where some function is written to be a
WSGI request handler.  It is passed a request, and returns a response.
22:48 < KirkMcDonald> Then you plug that into any of the many existing
WSGI-compliant servers.
22:49 < cenuij> I'ts pythong only RPC?
22:49 < KirkMcDonald> WSGI isn't an RPC.
22:49 < KirkMcDonald> It's just a function.
22:50 < dilenger> similar to Rack ?
22:50 < cenuij> I'm confused
22:50 < KirkMcDonald> I am not familiar with Rack.
22:51 < KirkMcDonald> cenuij: Say you have a function you have written.
This function is passed some information defining an HTTP request, and returns
something representing an HTTP response.
22:51 < cenuij> If WSGI is not a protocol, or RPC, how can I communicate
with it outside of python?
22:52 < KirkMcDonald> cenuij: You can't.  Not directly.  You need a server,
either written in Python or using Python's C API, which imports this function, and
knows how to call it.
22:52 < KirkMcDonald> cenuij: There are several such servers: mod_wsgi for
Apache, some simple development servers, Wiseguy...
22:52 < cenuij> ok
22:53 < cenuij> would it not be easier for python servers to use some kind
of RPC?
22:53 < cenuij> or that horrible slow fcgi?
22:53 < KirkMcDonald> So when I say something is a FastCGI-WSGI bridge, I
mean that it is a FastCGI server, written in Python, which can be configured to
import any WSGI application you have sitting around.
22:54 < cenuij> KirkMcDonald: aaah
22:54 < steven> why even bother with bridges or whatnot?  why not just write
your entire server in Go?
22:54 < cenuij> well that's reasonably cunning :)
22:54 < steven> err, app, not server.
22:54 < cenuij> steven: the world doesnt use go, yet...  ;)
22:55 < KirkMcDonald> cenuij: The intent is to have a handy interface which
can be plugged into whatever you actually want to serve the application with.
22:55 < exch> And it never will if someone doesnt start
22:55 < steven> but im saying, Go is so high-level that you can write a
stand-alone webapp in it with little trouble
22:55 < steven> exch: right on
22:55 -!- tensorpudding [~user@] has joined #go-nuts
22:55 < KirkMcDonald> cenuij: So if you invented some new, efficient RPC,
you could just make a WSGI-compliant server, and plug the whole existing ecosystem
of WSGI-compliant web applications into it.
22:56 < steven> serving files is built right into go --
22:56 < cenuij> KirkMcDonald: I'm with you now...  and I see the point of
view of python
22:57 < KirkMcDonald> cenuij: So! It might be handy to have such a standard
interface for Go.
22:57 < cenuij> KirkMcDonald: thanks, i had previously associated wsgi with
22:57 < steven> oh i get why..
22:57 -!- rurban [~chatzilla@178-191-149-74.adsl.highway.telekom.at] has quit
[Ping timeout: 276 seconds]
22:57 < KirkMcDonald> cenuij: This is a depressingly common misconception.
22:58 < steven> because its handy to have the server (and its configuration)
be separate than the webapp itself..
22:58 < steven> ie mongrel/passenger/apache/etc are all separate from
rails/sinatra/etc, and can be interchanged.
22:58 < KirkMcDonald> cenuij: I think it comes about because people see
there is a mod_wsgi and a mod_fcgi, and they assume they represent the same
22:59 < cenuij> KirkMcDonald: is wsgi a supported api in python libs or in
the interpreters?
22:59 < KirkMcDonald> cenuij: In a sense there's nothing that needs
22:59 < KirkMcDonald> cenuij: The standard library has a reference
22:59 < KirkMcDonald> But in any serious production system, you probably
wouldn't use that.
23:00 < cenuij> I don't suppose anyone has some background on fcgi?
23:01 < cenuij> it's almost as annoying as blizzards mpw archive's
23:01 < KirkMcDonald> cenuij: WSGI is a supported API in the sense that the
document defining it is an officially-endorsed PEP:
23:01 < KirkMcDonald> The standard library doesn't enter into it.  It
defines a function to be implemented by web applications, to be called by servers.
23:02 < KirkMcDonald> (This being Python, everything is dynamically typed.)
23:02 < cenuij> KirkMcDonald: thanks, i'll take care to read this.
23:03 < KirkMcDonald> (So you don't need what you'd need in a statically
typed language: Standard base classes or interfaces, or what-have-you.)
23:03 < ww> in principle there si a way of embedding python into go...  so a
little bit of glue should be able to pull in wsgi apps...
23:03 < ww> but why you'd *want* to do that is not clear to me
23:03 < KirkMcDonald> It would buy you very little, heh.
23:03 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit:
23:04 < KirkMcDonald> cenuij: You should also be aware that there are
efforts to revise the WSGI standard, and at least a couple of drafts of new
23:05 < KirkMcDonald> The Python 3 version linked from PEP 333, as I
understand it, is still a little up in the air.
23:05 < ww> somethign to do with working out how to properly treat unicode
23:05 < cenuij> KirkMcDonald: My interest will probably lag behind that
anyway, i'm still fighting having versions of py on dev boxes
23:05 < KirkMcDonald> ww: Just so.
23:05 < aiju> you don't revise standards, you just don't use them …
23:05 < cenuij> So i was reading on the mailing list, an offer to provide a
new hash algo into the go libs.
23:06 < cenuij> and there was some resistance
23:06 < ww> i coincidentally wrote the same one as that guy...  dont see a
real reason why it can't just be an external package...
23:07 < aiju> i should read the mailing list
23:07 < aiju> it's just hilarious sometimes
23:07 < ww> otoh that algorithm is like six lines of code so it wouldn't be
much of a burden to take it in house
23:07 * ww shrugs
23:08 < cenuij> it's hard to say what the "litmus" test should be
23:12 -!- Electro^ [electro@c-bef570d5.033-10-67626721.cust.bredbandsbolaget.se]
has quit [Remote host closed the connection]
23:12 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has quit [Read error:
Operation timed out]
23:15 < cenuij> ww: at the same time we will see lz* creeping into the libs,
is it really so bad to have more hash algos?
23:17 < steven> does it make sense to write a webapp (say, a twitter-clone)
purely in Go, and serve it directly on port 80 on some server?
23:17 < steven> as opposed to going through the whole apache dance, etc
23:21 < cenuij> do you trust go to parse the http request correctly?
23:26 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has quit [Ping
timeout: 264 seconds]
23:28 < ww> i'd almost always put nginx in front for flexibility...  proxy
this, add cors headers to that etc...
23:29 < ww> cenuij: i don't feel very strongly about it.  would tend to err
on the side of keeping stdlib small though...
23:31 < ww> because the core committers will become a bottleneck as it gets
more widely used if they have to gatekeep changes to libraries
23:32 < ww> most likely the real litmus test is whether they use it
themselves and have a vested interest in maintaining it
23:33 < aiju> adding every algo on the planet doesn't seem like a good idea
23:34 < aiju> gosh, the runtime is already 200 KLOC
23:34 < aiju> s/runtime/stdlib
23:36 < cenuij> I'm in agreement.  I will use nginx.  I was tempted to use
varnish as my proxy but henning-kamp's insistance that he had discouvered a new
form of CS made my nano-Dijkstra monitor blow a valve.
23:42 < KirkMcDonald> The main reason, I think, to put a dedicated web
server in front of the web application is to serve static files.
23:43 < dilenger> cenuij: i'd avoid varnish unless you actually need a
caching reverse proxy
23:43 < dilenger> i never had any luck with its stability
23:44 < dilenger> but it does reastart VERY quickly
23:44 -!- boscop_ [~boscop@g227132192.adsl.alicedsl.de] has quit [Ping timeout:
255 seconds]
23:45 * ww is very suspicious of varnish, by default it is not http compliant
(stomps on and ignores cache headers that are presumably set by the application to
tell the cache what to do...)
23:45 < steven> KirkMcDonald: but the idea is that Go has the ability to be
super fast at serving static files, comparable to nginx
23:47 < dilenger> steven: i'd expect go's static speed to be comperable to
nginx, up to the point they are both limited by bandwidth and syscall thoughput
23:47 < ww> KirkMcDonald: i prefer to try to keep apps small and separate.
don't really want them running in one image.  very much not a fan of embedding a
gigantic tree of wsgi apps in apache...
23:48 < ww> so something like nginx just to knit them together.  could
rewrite something in go that does the same thing, but why reinvent that wheel?
23:48 < steven> i can tell you one thing..  at work when one mongrel does,
its nice that they all dont die.  if they were all in one process, that could be
very bad.
23:48 -!- Tuller [~tuller@c-69-143-52-174.hsd1.va.comcast.net] has quit [Quit:
Computer has gone to sleep.]
23:48 < steven> i suppose though that with proper error handling that isnt
really a problem at all
23:49 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has joined
23:51 -!- _nil [~caine@c-67-189-251-116.hsd1.ct.comcast.net] has quit [Ping
timeout: 264 seconds]
23:55 < cenuij> the mongrel http parser is practically a state machine, so
far as I can grok it
23:56 < cenuij> which is nice
23:56 < cenuij> but it's not go
23:56 < cenuij> we have http
23:56 < dfc> the mongrel parser is written in ragel (?)
23:56 < dfc> and I believe that ragel can output a .go file
23:56 < dfc> but that is as far as I've looked into it
23:56 < dfc> the common wisdom is the ragel http parser is solid
23:57 -!- itrekkie [~itrekkie@ip72-211-129-122.tc.ph.cox.net] has joined #go-nuts
23:57 < dfc> and accepted as a semi standard of acceptable http parsing
23:58 < cenuij> dfc: this would make sense to me as the mongrel/mongrel2
http parser is in the C form of a state machine that is hard for me to immediately
23:58 < steven> :)
--- Log closed Mon Mar 07 00:00:49 2011