--- Log opened Wed Jun 23 00:00:07 2010
--- Day changed Wed Jun 23 2010
00:00 < Ginto8_> then say there's a c struct blarg
00:00 < Ginto8_> you could do var x C.blarg
00:00 * Freejack nods
00:00 -!- General1337 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has quit
[Ping timeout: 240 seconds]
00:00 < Ginto8_> but you don't really want to
00:00 < Ginto8_> because oftentimes these things use unsafe C stuff
00:00 < Freejack> Ginto8: Alright, how do I want to do it?
00:01 < Ginto8_> so you could do something like type GoBlarg struct {
privateVar C.blarg }
00:01 < Ginto8_> and then write wrapping methods for safe access
00:01 * Freejack nods
00:01 < Ginto8_> that would work with Go's stricter typing system
00:01 < Freejack> Makes sense.
00:02 < Ginto8_> it's better to do that than to do what Go-SDL did
00:02 < Freejack> Ginto8: Havent looked at that package.
00:02 < Ginto8_> it created exact memory mapped go structs that were
converted from the C structs
00:02 < Ginto8_> completely system dependent tho
00:03 < Ginto8_> and it failed with a lot of stuff
00:03 * Freejack nods
00:03 < Ginto8_> which is why I just interface directly to C for my SDL
needs (the C access obscured away)
00:04 < Freejack> I'm comfortable with strict typing.  I do a lot of coding
with Ada+Spark.
00:04 < Ginto8_> if you want to make a useful Go mapping to C functionality,
you have to make it a little different from the original C struct
00:05 -!- skelterjohn [~jasmuth@c-71-230-231-185.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
00:05 < Ginto8_> otherwise it's just an annoying mess that may or may not
work
00:05 < Freejack> Ginto8: Gotcha.
00:06 < Ginto8_> on a side note, I'd recommend against using Go-SDL =P
00:06 -!- ikke [~ikke@unaffiliated/ikkebr] has joined #go-nuts
00:06 < Freejack> Ginto8: Are there any facilities for inline assembler, and
atomic instructions?
00:06 < Ginto8_> uhm
00:06 <+iant> no inline assembler
00:06 <+iant> atomic instructions only via function calls
00:07 * Freejack nods
00:07 < Ginto8_> though if you feel edgy you can add some inline assembler
via cgo
00:07 * Ginto8_ recommends against it though
00:07 < Freejack> Well, I shouldn't need it all that much for this.
00:10 < Freejack> Typically my apps are broken down into a system of
standalone processes, that can continue to function even if all the other ones
puke themselves.
00:10 < Freejack> Even if that only means initiating a graceful shutdown.
00:10 < Ginto8> hmm interesting
00:10 < Ginto8> you sound like a good unix programmer =P
00:11 -!- ender2070 [~ender2070@bas22-toronto12-2925103372.dsl.bell.ca] has joined
#go-nuts
00:12 < Freejack> Ginto8: Well, I "layer" my concurrency.  Several threads
usually make up a process, and several processes usually make up an app.
00:12 -!- skelterjohn [~jasmuth@c-71-230-231-185.hsd1.nj.comcast.net] has joined
#go-nuts
00:12 < Freejack> Goroutines and channels work extremely well within a
process, but their not so adept at working with multiple processes.
00:13 < Ginto8> yeah they do
00:13 < Ginto8> and you have a very good point
00:13 < Ginto8> go is meant primarily for standalone apps
00:14 < Ginto8> though standard out/input can still be used well in the
style of the unix mindset
00:15 < Freejack> Hrrrmm...perhaps instead of defining Go for standalone
"apps" it should be defined for standalone "processes".
00:15 < Ginto8> yeah
00:15 < Ginto8> though you can have an entire multiplexing server in a
single go process
00:16 < Ginto8> with 1000 goroutines doing their thing
00:16 < Ginto8> or you can increase GOMAXPROCS so that the 1000 goroutines
are spread out over multiple threads
00:17 < Freejack> Nonetheless, Go will have to interact with processes
written for other problem domains, using other toolsets.
00:17 < Ginto8> yeah
00:17 < Ginto8> pipes to the rescue!
00:18 < Ginto8> cuz aren't pipes usually asynchronous?
00:19 < Freejack> Ginto8: No, their not.
00:19 < Ginto8> hmm
00:19 < Ginto8> ok then
00:19 < Freejack> Ginto8: Look at http://en.wikipedia.org/wiki/Message_queue
00:20 < Freejack> Ginto8: They might appear to be asynchronous, but they are
in fact the most Synchronous IPC mechanism available on the *nix platform.  Only
signals are more Synchronous.
00:21 < Ginto8> pipes you mean?
00:22 < Freejack> Scroll down to the section on "Synchronous vs
Asynchronous"
00:22 < Ginto8> hmm ok
00:23 < Ginto8> I know the use of asynchronous vs synchronous
00:23 < Ginto8> I'm using sync/async for my game engine
00:23 < Ginto8> I just didn't know that pipes were synchronous
00:25 < Freejack> Ginto8: Queues, due to the inherent structure, can usually
be optimized for more than Pipes/Sockets either by the OS Kernel or the
implementing library.
00:25 < Freejack> s/for/far
00:26 < Ginto8> yeah queues are pretty simple
00:26 -!- thomas_b [~thomasb@cm-84.215.37.40.getinternet.no] has quit [Ping
timeout: 248 seconds]
00:26 < Freejack> Queues can be prioritized.
00:26 < Ginto8> pushBack() popFront()
00:26 < Ginto8> only two main things needed
00:27 < Ginto8> prioritized?
00:27 < Freejack> Move messages around in the queue due to their priority.
00:27 < Freejack> They're "fire and forget".
00:28 < Ginto8> hmm nice
00:28 < Ginto8> so a sort algo
00:28 < Ginto8> yep
00:28 < Ginto8> goes in, sorts, gets taken out
00:28 < Ginto8> end of story
00:28 < Freejack> And typically can be utilized by many processes
simultaneously.
00:28 -!- thomas_b [~thomasb@cm-84.215.37.40.getinternet.no] has joined #go-nuts
00:28 < Ginto8> amirite?
00:28 < Freejack> Ginto8: Yup.  Great for realtime.
00:29 < Freejack> You can have a bunch of processes communicating on the
same Queue.
00:29 -!- Gracenotes [~person@wikipedia/Gracenotes] has quit [Ping timeout: 260
seconds]
00:30 < Ginto8> I'm a bit of a game dev, so what I really see potential for
with queue-type things is NPC AI
00:30 -!- kanru [~kanru@118-168-235-167.dynamic.hinet.net] has quit [Ping timeout:
248 seconds]
00:30 < Freejack> You can pump messages into a Queue, and have the Queue set
and wait for a processes that might not even be running yet.
00:30 < Ginto8> "I want you to do this, this and this, in this order, then
just wait for more"
00:31 < Ginto8> yep
00:31 < Freejack> You cant do that with Pipes, or Sockets/Streams.(At least
not without a major hack.)
00:31 < Ginto8> "When you have an NPC that can do these things, have it do
em"
00:31 < Ginto8> yep
00:31 * Freejack nods
00:31 -!- Gracenotes [~person@wikipedia/Gracenotes] has joined #go-nuts
00:32 < Ginto8> srry about my relating everything to npc's its sorta how I
think atm
00:32 -!- Ginto8 [~Ginto8@pool-72-82-235-34.cmdnnj.fios.verizon.net] has quit
[Quit: Leaving]
00:32 < Freejack> Ginto8: Still there?
00:32 -!- Ginto8 [~Ginto8@pool-72-82-235-34.cmdnnj.fios.verizon.net] has joined
#go-nuts
00:33 < Freejack> Ginto8: Welcome back.
00:33 < Freejack> Synchronous IPC, however, is the better choice if your
doing streaming media.
00:34 < Freejack> Found that out while playing with Esterel Programming
language.
00:34 < Ginto8> yeah synchronous each has advantages depending on the use
00:34 < Ginto8> s/synchronous//
00:34 < Ginto8> esterel?
00:35 < Freejack> Ginto8: I usually try to couple Synchronous and
Asynchronous mechanisms into a coherent whole.
00:36 < Ginto8> yep
00:36 < Freejack> Ginto8: Esterel is a "Synchronous language", designed for
High Integrity apps.(Avionics, DSPs, etc...)
00:36 < Freejack> But anyways, yeah, for this project I'm doing the Message
Queue code right now.
00:37 < Ginto8> hmm sounds interesting
00:37 < Ginto8> ok sounds cool
00:37 < Freejack> Ginto8: Check out http://www.zeromq.org/
00:37 < Ginto8> I think the reason it isn't in the standard package lib is
that windows wouldn't support it
00:37 < Ginto8> I don't think windows has queues
00:38 < Freejack> Ginto8: Doze is broken.  The more mature Go becomes, the
platform interfaces it's gonna need.
00:38 < Freejack> errr...
00:38 < Freejack> It's gonna need more platform specific packages.
00:38 < Freejack> brb
00:39 < Ginto8> yeah
00:39 < Ginto8> and some conditional compilation
00:41 < Freejack> back
00:42 < Freejack> Really, C/Java/Ada are Asynchronous programming languages,
Esterel, Signal, Lustre, are Synchronous.  Go seems to fall right between the two.
00:42 < Ginto8> go has utilities to be both
00:42 < Ginto8> channels can synch it
00:43 < Ginto8> and also allow async communication
00:43 < Freejack> The only domain it needs to add to it's repertoire is that
of Array/Vector programming.  Heh.  Good luck with that.
00:43 < Freejack> APL/ZPL/Sisal
00:44 < Ginto8> array/vector programming?
00:44 < Ginto8> where everything is an array?
00:44 < Freejack> Sort of.  The classic implementations are Fortran and APL.
00:44 < Freejack> Fortunately they've come along way from those days.
00:45 -!- mikespook [~mikespook@219.137.74.178] has quit [Remote host closed the
connection]
00:45 < Freejack> Vector/Array compilers stink at generating interactive
apps, but nothing can beat 'em when doing heavy number crunching.
00:45 < Ginto8> lookin at the wiki article and all I can think of it is that
it does a lot of array transforms
00:47 -!- mikespook [~mikespook@219.137.74.178] has joined #go-nuts
00:47 < Ginto8> hmm it seems that D supposedly has array programming aspects
00:47 < Ginto8> but I'm not fond of D anyway
00:47 < Freejack> Ginto8: Due to the way they handle threads and memory, the
code they generate is usually %50 to %60 faster on huge computations than...
00:47 -!- Kumul [~Kumul@adsl-72-50-76-120.prtc.net] has joined #go-nuts
00:47 < Freejack> The comparable compilers in other domains.
00:48 < Freejack> I visualize the concurrency issue as a triangle, with the
three vertices being (Synchronous, Asynchronous, Vectored).
00:49 < Freejack> And maybe Direct/Green threads being a fourth vertice,
forming a Pyramid.
00:50 < Freejack> Make sense?
00:51 < Ginto8> yep
00:51 -!- iant [~iant@67.218.106.21] has quit [Ping timeout: 260 seconds]
00:51 < Ginto8> you seem well versed when it comes to various programming
paradigms =P
00:52 -!- vhold [~vhold@adsl-67-114-158-146.dsl.sntc01.pacbell.net] has joined
#go-nuts
00:52 < Freejack> Ginto8: That's the thing, I dont think in "paradigms".
"Paradigms" are crap, and lead to fanboism.
00:53 < Freejack> Ginto8: I think in Problem Domains/Solutions.
00:53 -!- napsy [~luka@88.200.96.14] has joined #go-nuts
00:53 < Freejack> Or Domain -> Solution.
00:54 < Freejack> I have no problem mixing up several languages if it'll
give me the best solution to the problem.
00:55 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts
00:55 < vhold> How many operating systems are you willing to mix?
00:55 < Freejack> vhold: What do you mean?
00:56 < vhold> Joke question..  mixing languages I've found to be far less
painful then having systems with multiple parts running across multiple operating
systems
00:56 < Ginto8> vhold, good luck finding a *nix os that you need to mix with
windows to get good functionality
00:57 < Freejack> One thing that I dont like are systems/language
implementations that try to twist my arm into doing it "their" way.
00:58 < Freejack> errm...Java, C#, etc...
00:59 < Freejack> The only VM that actually seemed to suit me was Forth's
and that was because it didnt try to hide anything.
00:59 -!- smw [~smw@pool-96-232-88-231.nycmny.fios.verizon.net] has quit [Ping
timeout: 265 seconds]
00:59 < Ginto8> well every language twists your arm like that, sometimes
unconciously
00:59 * Freejack nods
01:00 < Freejack> The difference is in how easy it is to boot the language
out of the way when necessary.
01:00 < Freejack> Ada, for example, is very beauracratic, but I can kick it
out of the way, runtime and all, whenever the situation calls for it.
01:01 < Freejack> Java is another story.
01:01 < KirkMcDonald> D is good about this, too.
01:01 < Ginto8> and go has an unsafe package that just throws away the
strict typing
01:01 < Ginto8> and garbage collection
01:01 < Freejack> Go looks like it'll be great, as long as it sticks to the
"Runtime" and not the "Virtual Machine".
01:02 < Ginto8> Freejack, if it goes for anything close to vm, it'll be llvm
01:03 < Freejack> Ginto8: Well, I'm getting addicted to GoRoutines, so I'm
gonna have to add Go to my regular repertoire.
01:04 < Ginto8> Go is overall amazing I think
01:04 < Ginto8> I'm pretty much a C/++ fanboy
01:04 < Ginto8> but Go just flipped my thinking on its head and it's just so
FUN to program in
01:05 < Freejack> If Go can develop a nice balance between the
Synchronous/Asynchronous/Vectored domains, I'll make it a permanent part of my
toolkit.
01:05 < KirkMcDonald> Ginto8: Heh.  That was my reaction when I went from
C++ to Python.
01:05 -!- Mana|Linux [~mana@142.46.164.30] has joined #go-nuts
01:05 < Ginto8> all it needs is good array operations
01:05 -!- aho [~nya@g227085141.adsl.alicedsl.de] has quit [Quit:
EXEC_over.METHOD_SUBLIMATION]
01:06 < Freejack> KirkMcDonald: Ever tried Pike?
01:06 < Ginto8> KirkMcDonald, I dunno if I'd like python...  I'm a pretty
low leveled programmer at heart
01:06 < Ginto8> but Go is like C (which I prefer to C++) with a lot of
really useful functionality
01:06 -!- skelterjohn [~jasmuth@c-71-230-231-185.hsd1.nj.comcast.net] has quit
[Read error: Connection reset by peer]
01:06 -!- SecretofMana [~mana@142.46.164.30] has quit [Ping timeout: 276 seconds]
01:06 < KirkMcDonald> Freejack: No.
01:06 < KirkMcDonald> Despite appearances, Python is fairly C-like.
01:07 < Ginto8> KirkMcDonald, I'll make sure to try it sometime
01:07 < KirkMcDonald> And, you know, despite running on a VM.
01:07 < Ginto8> yeah
01:07 < Freejack> Thinking about using Pike for my runtime CMS.
01:07 < KirkMcDonald> And being dynamically typed.
01:08 < Freejack> It's like Python, but more C like.
01:08 -!- Luixsia [~Luixsia@AToulouse-254-1-5-26.w83-203.abo.wanadoo.fr] has quit
[Quit: Leaving]
01:08 < KirkMcDonald> So despite the vast, fundamental differences between
Python and C, Python is fairly C-like.
01:08 < Freejack> And more Go like.
01:08 < Freejack> Thinking Pike and Go would work well together.
01:09 < Freejack>
http://en.wikipedia.org/wiki/Pike_%28programming_language%29
01:09 < Ginto8> go is fairly unique and quite useful
01:09 * Freejack nods
01:10 < Freejack> It's a systems language.
01:10 < Freejack> Works great at that level.
01:10 < KirkMcDonald> The comparison to D is interesting.
01:11 < Freejack> D has a lot in common with Modula and Ada.  I think it's
what Java would have been had it been done right.
01:11 < KirkMcDonald> Maybe.  But the reality of D has its own issues.
01:11 < Freejack> Really...Java/D/Ada/CSharp, etc...  Niklaus Wirth is
influencing everyone.
01:11 -!- perdiy [~perdix@sxemacs/devel/perdix] has joined #go-nuts
01:12 < Ginto8> KirkMcDonald, yes, and lots of em
01:12 < KirkMcDonald> D also suffers from a problem which Go manages to
avoid.
01:12 < Ginto8> D was very good in concept though
01:12 < KirkMcDonald> And which C++ suffers from worst of all...  You see,
C++ is really approximately four languages.
01:12 < KirkMcDonald> And D is about three.
01:13 < Ginto8> KirkMcDonald, huh?
01:13 < KirkMcDonald> In C++, you have C, C++, the preprocessor, and
template metaprogramming.
01:13 < KirkMcDonald> These are basically four entirely different
programming languages, all in one place.
01:13 < Ginto8> hmm yeah
01:13 < Freejack> Really...When I wanna do lots of OOP, I just switch over
to Modula3 and/or Ada.  It's what C++/ObjC/Java were aiming for.
01:14 < Ginto8> well how is D three?
01:14 < KirkMcDonald> In D, you have D, template metaprogramming, and CTFE.
01:14 < Ginto8> it integrates template very well
01:14 -!- perdix [~perdix@sxemacs/devel/perdix] has quit [Ping timeout: 276
seconds]
01:14 < Ginto8> ctfe?
01:14 < KirkMcDonald> Ginto8: Sorrrt of.  It's still an entirely different
world.
01:14 < KirkMcDonald> Ginto8: Compile-time function execution.
01:14 < Freejack> D borrows bigtime from Ada/Modula.
01:14 < KirkMcDonald> It is a subset of the language which may be executed
at compile-time.
01:14 < Ginto8> oic
01:14 < Ginto8> yeah I know
01:14 < Ginto8> where as go is just go =P
01:14 -!- tokuhirom [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has quit [Ping
timeout: 240 seconds]
01:15 < KirkMcDonald> Go (and Python, and so on) is just one language.
01:15 < KirkMcDonald> Yeah.
01:15 < Freejack> Go is C for the modern age.
01:15 -!- skelterjohn [~jasmuth@c-76-116-181-134.hsd1.nj.comcast.net] has joined
#go-nuts
01:15 < KirkMcDonald> C is still about two languages.
01:15 < Freejack> Which is a good thing IMHO.
01:15 < KirkMcDonald> (C and the preprocessor.)
01:15 < Ginto8> though interfaces and goroutines make the language itself
VERY interesting
01:16 < Ginto8> yeah C/++ dont have very good code partitioning
01:16 < Ginto8> .h's are a nightmare
01:16 < Ginto8> but Go does it all pretty amazingly, while still maintaining
a C-like feel
01:16 < Freejack> Really.  C/C++ is libc/compiler/preprocessor.  All held
together by convention(and only by convention).
01:16 < Ginto8> I'm glad they took more from C than from C++/Java
01:17 < Freejack> That's why I always say, if you want OOP, the Wirth family
of languages is where you look for it.
01:17 < Freejack> Rigorous
01:18 < Ginto8> well Go has some functionality similar/reminiscent of OOP
01:18 < Freejack> Ginto8: True, true.  I just hope the developers dont start
tacking on a bunch of crap and ruin it.
01:19 < Ginto8> but is still distant enough that it doesn't suffer the same
problems
01:19 < Ginto8> they're actually being very conservative with what they add
01:19 < Freejack> Ginto8: Eventually you get to point where the
overabundance of features requires an entire language redesign.
01:20 < Ginto8> they're not even going to add generics until they find a way
of doing it without messing up the core language concepts
01:20 -!- Mana|Linux [~mana@142.46.164.30] has quit [Read error: Connection reset
by peer]
01:20 < Ginto8> I mean, look at how long it took to add panic()/recover()!
01:20 < Freejack> Ginto8: If they could do Shared Generics, I'd be a happy
camper.
01:22 < KirkMcDonald> There's another thing which annoys me about C++.
01:22 < KirkMcDonald> Which are reference parameters.
01:23 < KirkMcDonald> C has precisely one kind of function parameter, which
are values.
01:23 < Ginto8> reference parameters only exist because of ->
01:23 < KirkMcDonald> Python has precisely one kind of function parameter,
which are...  whatever you choose to call it.  Let's say "references-by-value."
01:23 < Ginto8> if they didn't have that annoying operator there would be no
need for the confusion that references cause
01:23 < Freejack> You wanna see what real generics look like?
http://en.wikibooks.org/wiki/Ada_Programming/Generics
01:24 < Freejack> It's large, but also extremely powerful.
01:24 < KirkMcDonald> Freejack: There's also a lot to like about D's
implementation of templates.
01:25 < KirkMcDonald> Anyway, I am pleased that Go uses only value
parameters...  mostly.  The one caveat is that using an interface can obfuscate
whether the contained value is a pointer or not, but I have not found this to be a
problem, in practice.
01:25 < Freejack> Shared Generics, the ability to emit one instance of the
object code for all instiations of the Generic.
01:26 * Freejack has to go.  Gotta get some work done.
01:26 < Ginto8> KirkMcDonald, yeah that's actually not a major issue.  The
gc helps =P
01:27 < Freejack> I'll let yah know how that Queue implementation turns out.
01:27 < Ginto8> Freejack, ok sounds good =D
01:27 < Freejack> Laters.
01:27 -!- Freejack [~dimonax@75-48-217-250.lightspeed.gdrpmi.sbcglobal.net] has
quit [Quit: Leaving]
01:28 < jessta> I quite like how gotgo goes generics in GO
01:29 < Ginto8> jessta, I haven't seen that, could you send me a link?
01:29 < jessta> http://github.com/droundy/gotgo
01:30 -!- tokuhirom [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has joined #go-nuts
01:30 -!- ikke [~ikke@unaffiliated/ikkebr] has quit []
01:30 < jessta> it's just a templates with replacable types
01:32 < jessta> you do: import list "list(int)"
01:32 < Ginto8> hmm
01:33 < Ginto8> so it adapts to whatever type you want
01:33 < jessta> and it generates an int version of the list from the list
template, and makes a package called list(int)
01:34 < jessta> you get some duplicate code, depending on how you write the
template
01:36 < Ginto8> ok sounds neat
01:39 < jessta> interface{} can be a bit troublesome
01:40 < jessta> especially for code that isn't well documented
01:41 < jessta> i.e you can't tell if they are expecting a pointer or the
value type
01:46 -!- General13372 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has quit
[Ping timeout: 265 seconds]
01:47 -!- General1337 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has joined
#go-nuts
01:52 -!- cco3 [~conley@c-69-181-138-209.hsd1.ca.comcast.net] has joined #go-nuts
01:55 -!- KinOfCain [~KinOfCain@rrcs-64-183-61-2.west.biz.rr.com] has quit [Remote
host closed the connection]
01:59 -!- General13372 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has joined
#go-nuts
02:03 -!- General1337 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has quit
[Ping timeout: 272 seconds]
02:04 -!- perdix [~perdix@sxemacs/devel/perdix] has quit [Quit: A cow.  A
trampoline.  Together they fight crime!]
02:07 -!- General13372 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has quit
[Ping timeout: 260 seconds]
02:09 -!- Brutus [~bellropa@c-76-125-210-57.hsd1.pa.comcast.net] has joined
#go-nuts
02:11 -!- General13372 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has joined
#go-nuts
02:15 -!- General1337 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has joined
#go-nuts
02:16 -!- General13372 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has quit
[Ping timeout: 265 seconds]
02:17 -!- General13372 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has joined
#go-nuts
02:20 -!- General1337 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has quit
[Ping timeout: 240 seconds]
02:30 -!- tokuhirom [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has quit [Quit:
Tiarra 0.1: SIGTERM received; exit]
02:32 -!- tokuhirom [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has joined #go-nuts
02:36 -!- Brutus [~bellropa@c-76-125-210-57.hsd1.pa.comcast.net] has quit []
02:43 -!- Ginto8 [~Ginto8@pool-72-82-235-34.cmdnnj.fios.verizon.net] has quit
[Ping timeout: 265 seconds]
02:43 -!- b00m_chef [~watr@d64-180-44-79.bchsia.telus.net] has joined #go-nuts
02:46 -!- sladegen [~nemo@unaffiliated/sladegen] has quit [Disconnected by
services]
02:46 -!- sladegen [~nemo@unaffiliated/sladegen] has joined #go-nuts
02:52 -!- Eridius [~kevin@unaffiliated/eridius] has quit [Ping timeout: 260
seconds]
02:56 -!- napsy [~luka@88.200.96.14] has quit [Ping timeout: 252 seconds]
03:00 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 260 seconds]
03:00 -!- skelterjohn [~jasmuth@c-76-116-181-134.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
03:03 -!- bmizerany [~bmizerany@dsl081-064-072.sfo1.dsl.speakeasy.net] has quit
[Remote host closed the connection]
03:06 -!- 36DAASGYR [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has quit [Quit:
Tiarra 0.1: SIGTERM received; exit]
03:07 -!- tokuhiro_ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has joined #go-nuts
03:22 < jer> can anyone point me at some half decent parsing library
(go-parse doesn't qualify, need something with at least SOME documentation); my
needs are interpreting a simple context free grammar which needs to discern a few
different types of tokens, and that's it.
03:22 -!- OpenSpace [~ja@93.87.144.247] has quit [Ping timeout: 265 seconds]
03:23 < jer> tried hand crafting one, but i must be stupid or something, but
i can't handle properly cases like: 2) where 2 and ) need to be separate tokens,
just get infinite loops because i have no idea how many bytes of text each char is
going to be, so i can't use any look-ahead cheating type of stuff in my routines
03:25 -!- alc [~arx@222.128.147.191] has joined #go-nuts
03:27 -!- alc [~arx@222.128.147.191] has quit [Remote host closed the connection]
03:30 -!- alc [~arx@222.128.147.191] has joined #go-nuts
03:35 < exch> don't iterate over bytes, but over runes
03:37 < jer> that's what i'm doing, it's giving my grief.  doing this, it
things that 2) is a valid number token type, when it should think that 2 is one
type, and ) is another.  this is what's been giving me problems all day, i'm about
ready to beat myself senseless with a pair of toe nail clippers over it.
03:37 -!- nvictor [~nvictor@pool-71-179-215-46.bltmmd.east.verizon.net] has joined
#go-nuts
03:37 < nvictor> hola
03:37 < nvictor> :)
03:37 < jer> so i'm admitting defeat in that my code is wortheless, looking
for some documented library i can peruse and potentially replace my broken pos
with
03:37 < nvictor> h0w t0 get g0 0n wind0ws?
03:40 < nvictor> i can't install go on windows?
03:41 -!- nettok [~quassel@200.119.180.157] has joined #go-nuts
03:42 < exch> you can.  Not sure if the windows version is as far ahead as
the official release though.  It's only being maintained by community members
03:42 < exch> http://code.google.com/p/go/wiki/WindowsPort
03:45 < jessta> jer: paste code?
03:45 < exch> jer: I have no commented parser, but perhaps this can be of
some help.  It's the parser for my tinyscript library.
http://github.com/jteeuwen/Tinyscript/blob/master/tinyscript/parse/tokenizer.go#L76
03:46 < exch> it tokenizes a language which is based on postscript.  It has
no problem with things like '2]'
03:53 -!- pfroehlich [~chatzilla@c-98-204-215-206.hsd1.md.comcast.net] has joined
#go-nuts
03:54 -!- napsy [~luka@88.200.96.14] has joined #go-nuts
03:54 -!- pfroehlich [~chatzilla@c-98-204-215-206.hsd1.md.comcast.net] has quit
[Client Quit]
03:54 -!- pfroehlich [~chatzilla@c-98-204-215-206.hsd1.md.comcast.net] has joined
#go-nuts
03:58 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has joined #go-nuts
03:58 -!- mode/#go-nuts [+v iant] by ChanServ
03:58 -!- werdan7 [~w7@freenode/staff/wikimedia.werdan7] has joined #go-nuts
04:04 -!- ExtraSpice [~ExtraSpic@78-62-86-161.static.zebra.lt] has joined #go-nuts
04:07 -!- nsz [nsz@morecp.net] has quit [Ping timeout: 260 seconds]
04:07 -!- nsz [nsz@morecp.net] has joined #go-nuts
04:11 -!- InaVegt_ [~InaVegt@dsl-087-195-206-242.solcon.nl] has joined #go-nuts
04:13 -!- InaVegt [~InaVegt@dsl-087-195-206-242.solcon.nl] has quit [Ping timeout:
265 seconds]
04:16 -!- rv2733 [~ron@c-98-242-168-49.hsd1.fl.comcast.net] has joined #go-nuts
04:16 -!- alc [~arx@222.128.147.191] has quit [Ping timeout: 260 seconds]
04:24 -!- iant [~iant@adsl-71-133-8-30.dsl.pltn13.pacbell.net] has quit [Ping
timeout: 240 seconds]
04:35 -!- jesstatest [~jesstates@124-148-162-135.dyn.iinet.net.au] has joined
#go-nuts
04:36 -!- jesstatest [~jesstates@124-148-162-135.dyn.iinet.net.au] has quit
[Remote host closed the connection]
04:37 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has quit [Quit:
Leaving]
04:39 -!- iant [~iant@216.239.45.130] has joined #go-nuts
04:39 -!- mode/#go-nuts [+v iant] by ChanServ
04:44 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has joined
#go-nuts
05:00 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has quit [Quit:
This computer has gone to sleep]
05:01 -!- scm [justme@d018081.adsl.hansenet.de] has quit [Ping timeout: 264
seconds]
05:01 -!- nvictor [~nvictor@pool-71-179-215-46.bltmmd.east.verizon.net] has quit
[]
05:02 -!- scm [justme@d019227.adsl.hansenet.de] has joined #go-nuts
05:08 -!- pizza_ [pizza@poipu/supporter/pizza-milkshake] has left #go-nuts []
05:11 < plexdev> http://is.gd/d03Dq by [Christopher Wedgwood] in go/src/pkg/
-- Build draw/x11.  Skip for test.
05:19 -!- tsykoduk [~tsykoduk@2001:470:1f04:671:20d:93ff:fe77:1dc4] has quit [Ping
timeout: 248 seconds]
05:20 -!- Gracenotes [~person@wikipedia/Gracenotes] has quit [Ping timeout: 240
seconds]
05:20 < jer> jessta, exch, nevermind, i worked around my issue
05:20 -!- tsykoduk [~tsykoduk@2001:470:1f04:671:20d:93ff:fe77:1dc4] has joined
#go-nuts
05:34 -!- eikenberry [~jae@ivanova.zhar.net] has quit [Ping timeout: 265 seconds]
05:43 -!- b00m_chef [~watr@d64-180-44-79.bchsia.telus.net] has quit [Ping timeout:
240 seconds]
05:46 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Quit: WeeChat
0.3.2]
05:47 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts
05:48 -!- zozoR [~zozoR@0x5da69cf2.cpe.ge-0-1-0-1105.hsnqu1.customer.tele.dk] has
joined #go-nuts
05:57 -!- napsy [~luka@88.200.96.14] has quit [Ping timeout: 276 seconds]
06:08 -!- h43 [xfsz@193.219.39.203] has joined #go-nuts
06:09 -!- Freejack [~dimonax@75-48-217-250.lightspeed.gdrpmi.sbcglobal.net] has
joined #go-nuts
06:09 < Freejack> What's up?
06:10 < Freejack> I need some tips.  http://pastebin.com/7Y34zZ6p
06:12 * Freejack is lurking
06:18 -!- Kumul [~Kumul@adsl-72-50-76-120.prtc.net] has quit [Quit: gone]
06:26 < Freejack> This one is a little better...
http://pastebin.com/A8cmCgAg
06:33 -!- napsy [~luka@88.200.96.14] has joined #go-nuts
06:38 < Freejack> This one is closer....http://pastebin.com/m3PxR3t0
06:46 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-181-238.clienti.tiscali.it] has
joined #go-nuts
06:52 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
06:55 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
06:55 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
06:56 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
06:56 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
06:56 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
06:57 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
06:58 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
06:58 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
06:58 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
06:59 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
06:59 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
07:01 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:01 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
07:01 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:01 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
07:04 < Freejack> Bah!
07:04 * Freejack is about to hang it up for the night.
07:05 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:06 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
07:06 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:06 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
07:08 -!- ikaros [~ikaros@f052190112.adsl.alicedsl.de] has joined #go-nuts
07:08 -!- ampleyfly [~ampleyfly@h-148-139.A163.priv.bahnhof.se] has quit [Ping
timeout: 264 seconds]
07:08 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:11 < Freejack> bbl
07:11 -!- Freejack [~dimonax@75-48-217-250.lightspeed.gdrpmi.sbcglobal.net] has
quit [Quit: Leaving]
07:12 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
07:13 -!- Shyde [~shyde@HSI-KBW-078-043-070-132.hsi4.kabel-badenwuerttemberg.de]
has joined #go-nuts
07:18 -!- ita [~waf@kde/developer/tnagy] has joined #go-nuts
07:22 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:22 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
07:24 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts
07:24 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Client Quit]
07:25 -!- ampleyfly [~ampleyfly@h-148-139.A163.priv.bahnhof.se] has joined
#go-nuts
07:27 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
07:33 -!- monteslu [~monteslu@ip68-109-175-168.ph.ph.cox.net] has quit [Read
error: Operation timed out]
07:33 -!- monteslu [~monteslu@ip68-109-175-168.ph.ph.cox.net] has joined #go-nuts
07:36 -!- tux21b [~christoph@90.146.60.30] has quit [Ping timeout: 276 seconds]
07:38 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.2]
07:42 -!- cco3 [~conley@c-69-181-138-209.hsd1.ca.comcast.net] has quit [Ping
timeout: 240 seconds]
07:43 -!- tvw [~tv@212.79.9.150] has joined #go-nuts
07:51 -!- Surma [~bzfsurma@gooseberry.zib.de] has joined #go-nuts
08:05 -!- Surma [~bzfsurma@gooseberry.zib.de] has quit [Quit: Leaving.]
08:08 -!- photron [~photron@port-92-201-83-202.dynamic.qsc.de] has joined #go-nuts
08:15 -!- rv2733 [~ron@c-98-242-168-49.hsd1.fl.comcast.net] has quit [Quit:
Leaving]
08:23 -!- wrtp [~rog@92.16.114.245] has joined #go-nuts
08:33 -!- wrtp [~rog@92.16.114.245] has quit [Ping timeout: 248 seconds]
08:37 -!- MizardX [~MizardX@unaffiliated/mizardx] has joined #go-nuts
08:37 -!- HKVN [~JBouncer@222.255.29.8] has left #go-nuts ["Leaving"]
08:45 -!- wrtp [~rog@92.16.114.245] has joined #go-nuts
08:46 -!- InaVegt_ [~InaVegt@dsl-087-195-206-242.solcon.nl] has quit [Ping
timeout: 240 seconds]
08:54 -!- pfroehlich [~chatzilla@c-98-204-215-206.hsd1.md.comcast.net] has quit
[Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401074458]]
08:58 -!- Shyde [~shyde@HSI-KBW-078-043-070-132.hsi4.kabel-badenwuerttemberg.de]
has quit [Remote host closed the connection]
09:06 -!- smw [~smw@pool-96-232-88-231.nycmny.fios.verizon.net] has joined
#go-nuts
09:19 -!- napsy [~luka@88.200.96.14] has quit [Ping timeout: 240 seconds]
09:19 -!- wrtp [~rog@92.16.114.245] has quit [Quit: wrtp]
09:30 -!- nettok [~quassel@200.119.180.157] has quit [Remote host closed the
connection]
09:31 -!- Garen [~garen.p@69.76.18.3] has quit [Read error: Connection reset by
peer]
09:32 -!- Garen [~garen.p@69.76.18.3] has joined #go-nuts
09:35 -!- mikespook [~mikespook@219.137.74.178] has quit [Quit: Leaving.]
09:36 -!- mxweas [~max@c-98-225-102-170.hsd1.az.comcast.net] has joined #go-nuts
09:48 -!- napsy [~luka@88.200.96.14] has joined #go-nuts
09:50 -!- visof [~visof@unaffiliated/visof] has joined #go-nuts
10:05 -!- OpenSpace [~ja@77.46.185.191] has joined #go-nuts
10:06 -!- perdix [~perdix@sxemacs/devel/perdix] has joined #go-nuts
10:09 -!- wrtp [~rog@92.16.114.245] has joined #go-nuts
10:30 -!- wrtp [~rog@92.16.114.245] has quit [Ping timeout: 260 seconds]
10:34 -!- boscop_ [~boscop@f055121022.adsl.alicedsl.de] has left #go-nuts []
10:34 -!- boscop [~boscop@f055121022.adsl.alicedsl.de] has joined #go-nuts
10:37 -!- wrtp [~rog@92.16.114.245] has joined #go-nuts
10:40 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has joined #go-nuts
10:44 -!- Garen [~garen.p@69.76.18.3] has quit []
10:48 -!- wrtp [~rog@92.16.114.245] has quit [Ping timeout: 276 seconds]
10:48 -!- napsy [~luka@88.200.96.14] has quit [Read error: Operation timed out]
10:49 -!- napsy [~luka@88.200.96.14] has joined #go-nuts
10:54 -!- wrtp [~rog@92.16.114.245] has joined #go-nuts
10:55 -!- lux` [~lux@151.71.215.184] has joined #go-nuts
10:56 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 276 seconds]
10:57 -!- Boney [~paul@203-217-82-244.dyn.iinet.net.au] has quit [Ping timeout:
252 seconds]
11:00 -!- Boney [~paul@210-84-34-43.dyn.iinet.net.au] has joined #go-nuts
11:04 -!- wrtp [~rog@92.16.114.245] has quit [Ping timeout: 265 seconds]
11:06 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has quit [Remote host closed the
connection]
11:09 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has joined
#go-nuts
11:12 -!- wrtp [~rog@92.16.114.245] has joined #go-nuts
11:13 -!- skelterjohn [~jasmuth@c-76-116-181-134.hsd1.nj.comcast.net] has joined
#go-nuts
11:19 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts
11:20 -!- skelterjohn [~jasmuth@c-76-116-181-134.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
11:22 -!- wrtp [~rog@92.16.114.245] has quit [Ping timeout: 240 seconds]
11:23 -!- thiagon [~thiagon@150.164.2.20] has joined #go-nuts
11:25 -!- adu [~ajr@pool-71-191-173-125.washdc.fios.verizon.net] has joined
#go-nuts
11:28 -!- wrtp [~rog@92.16.114.245] has joined #go-nuts
11:28 -!- kanru [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Quit: WeeChat
0.3.2]
11:39 -!- photron [~photron@port-92-201-83-202.dynamic.qsc.de] has quit [Ping
timeout: 276 seconds]
11:42 -!- cenuij [~cenuij@base/student/cenuij] has quit [Remote host closed the
connection]
11:52 -!- jdp [~gu@24.238.32.162.res-cmts.segr.ptd.net] has joined #go-nuts
11:53 -!- Gracenotes [~person@wikipedia/Gracenotes] has joined #go-nuts
11:59 -!- napsy [~luka@88.200.96.14] has quit [Ping timeout: 240 seconds]
12:04 -!- wrtp [~rog@92.16.114.245] has quit [Quit: wrtp]
12:09 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
12:20 -!- skelterjohn [~jasmuth@c-76-116-181-134.hsd1.nj.comcast.net] has joined
#go-nuts
12:28 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has quit [Quit:
This computer has gone to sleep]
12:29 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-181-238.clienti.tiscali.it] has
quit [Quit: E se abbasso questa leva che succ...]
12:30 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-181-238.clienti.tiscali.it] has
joined #go-nuts
12:37 -!- wrtp [~rog@92.17.70.156] has joined #go-nuts
12:37 -!- wrtp [~rog@92.17.70.156] has quit [Client Quit]
12:38 -!- wrtp [~rog@92.17.70.156] has joined #go-nuts
12:45 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
12:57 -!- kanru [~kanru@118-168-235-167.dynamic.hinet.net] has joined #go-nuts
13:09 < nsf> um..  is there any difference defining global [...] array or
global [] slice?  I mean they both are being allocated at runtime, right?
13:16 < bartbes> a slice merely points to other memory and doesn't actually
have memory, right?
13:19 < smw> bartbes, right
13:20 < smw> nsf, it does matter if you care whether it is an array or slice
13:21 -!- eikenberry [~jae@ivanova.zhar.net] has joined #go-nuts
13:21 < bartbes> well then, the slice is not being allocated, is it?
13:21 < bartbes> unless you use make, but you know when that allocates..
13:22 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has quit [Quit: Coyote finally
caught me]
13:22 < smw> bartbes, I am not sure what you mean
13:22 -!- napsy [~luka@88.200.96.14] has joined #go-nuts
13:23 < bartbes> I was trying to answer nsf's question
13:23 < smw> ok
13:23 < smw> it looked like a question
13:23 < bartbes> since a slice doesn't own memory there is no allocation to
do (no implicit allocation, that is)
13:24 -!- Xurix [~Luixsia@AToulouse-254-1-5-26.w83-203.abo.wanadoo.fr] has quit
[Read error: Connection reset by peer]
13:27 -!- iant [~iant@216.239.45.130] has quit [Ping timeout: 248 seconds]
13:28 -!- ivan` [~ivan@unaffiliated/ivan/x-000001] has joined #go-nuts
13:28 -!- vdrab [~vdrab@cap012-213.kcn.ne.jp] has joined #go-nuts
13:52 -!- napsy [~luka@88.200.96.14] has quit [Ping timeout: 248 seconds]
13:56 < nf> bartbes: depends how you create teh slice
13:56 < nf> if you make() a slice, an underlying array of the specified
length (or capacity) is created
13:56 < nf> s/created/allocated/
13:57 < bartbes> yeah, but that's explicit
13:57 < bartbes> and then you know when it is allocated
13:57 -!- iant [~iant@67.218.107.123] has joined #go-nuts
13:57 -!- mode/#go-nuts [+v iant] by ChanServ
13:57 -!- InaVegt [~InaVegt@dsl-087-195-206-242.solcon.nl] has joined #go-nuts
13:57 < nf> but if you create a slice by taking a sub-slice of an existing
slice, it only creates a pointer to that original slice's array
13:57 < nsf> well, yep, I meant this: var table = [...]T { ...  } vs.  var
table = []T { ...  }
13:57 < nf> nsf: they're equivalent
13:58 < nf> unless the number you put in [n]T{...} is shorter than the
number of elements you specify
13:58 < nf> s/shorter/longer/
13:58 < nsf> and I was interested particularly in allocation
13:58 < nsf> there is a type difference of course
13:58 < nsf> one is array and the other is slice :)
13:59 < nf> eg: s := [10]int{1,2,3} is the same as s := make([]int, 10);
s[0], s[1], s[2] = 1, 2, 3
13:59 < nf> ah, yes, of coruse :)
13:59 < nf> course :)
14:08 -!- pfroehlich [~chatzilla@c-98-204-215-206.hsd1.md.comcast.net] has joined
#go-nuts
14:17 -!- General1337 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has joined
#go-nuts
14:20 -!- tvw [~tv@212.79.9.150] has quit [Remote host closed the connection]
14:21 -!- General13372 [~support@71-84-50-230.dhcp.mtpk.ca.charter.com] has quit
[Ping timeout: 260 seconds]
14:24 -!- Shyde [~shyde@HSI-KBW-078-043-070-132.hsi4.kabel-badenwuerttemberg.de]
has joined #go-nuts
14:26 <+iant> are people here as troubled by the semicolon rules as Peter
Williams is?
14:28 < Project_2501> O.o?
14:29 <+iant>
http://groups.google.com/group/golang-dev/browse_thread/thread/99b28bdbfac84693#
14:30 < pfroehlich> iant: I never liked the current system of doing this
14:30 < pfroehlich> iant: it seemed like a hack when it first arrived
14:30 < skelterjohn> i am fine with it the way it is
14:30 < skelterjohn> i think the way it's implemented is silly
14:30 < skelterjohn> but the way my code looks is fine
14:30 < pfroehlich> iant: and ruling out perfectly sane syntax is ...  iffy
14:30 < skelterjohn> i have no problem with enforcing style
14:30 < pfroehlich> skelterjohn: i think that's not the point, gofmt can do
that
14:31 < skelterjohn> gofmt can do that
14:31 < skelterjohn> but people can ignore it
14:31 < skelterjohn> can't ignore the semicolon rule.  ie it is enforced
style
14:31 < pfroehlich> imho the syntax needs to either be free form or not, the
way things are now it's neither
14:31 < plexdev> http://is.gd/d0DjR by [Andrew Gerrand] in 2 subdirs of
go/misc/dashboard/godashboard/ -- godashboard: add Projects page
14:31 < skelterjohn> to me it's all philisophical
14:31 < skelterjohn> i have no problems writing code in the current system
14:32 <+iant> pfroehlich: I would say that a newline is currently a
syntactic element
14:32 < skelterjohn> took me a while to figure out why if { }\n else { }
didn't work
14:32 <+iant> which is also true in other languages
14:32 <+iant> some other languages
14:33 < pfroehlich> skelterjohn: one can get used to just about anything :-D
14:33 < pfroehlich> skelterjohn: one doesn't have to like it though, that's
what I am expressing
14:33 < skelterjohn> right.  and i don't care much about idiosyncracies of
style
14:33 < skelterjohn> sure, i respect your right to not like it, hehe
14:33 < skelterjohn> just saying it doesn't bother me, and it also doesn't
bother me that it upsets some people
14:33 -!- boscop [~boscop@f055121022.adsl.alicedsl.de] has quit [Ping timeout: 265
seconds]
14:34 < pfroehlich> sadly I get the feeling that some people simply don't
appreciate the fact that they didn't find a better rule/implementation :-/
14:34 < skelterjohn> it's all under the hood, though
14:34 < exch> the current implementation does seem a bit arbitrary at times
14:34 <+iant> I think we're open to a better rule
14:34 < skelterjohn> i just pretend that the syntax of the language is what
i have to type, and forget that it goes through this weird semicolon pipe first
14:35 < pfroehlich> iant: i think you are, not sure about rsc :-D
14:35 < skelterjohn> i don't mind the rule, but i agree that the
implementation of the rule seems really weird
14:35 <+iant> I think rsc would be more convinced by a clear spec, which
Peter Williams hasn't written yet
14:36 < pfroehlich> of course you don't want to put me in charge of syntax,
I'd go for ALL CAPS KEYWORDS like in Oberon :-D
14:36 <+iant> ha
14:36 -!- rhelmer [~rhelmer@adsl-69-107-87-67.dsl.pltn13.pacbell.net] has quit
[Ping timeout: 265 seconds]
14:36 < skelterjohn> a lot of half formed ideas come to the list with the
expectation that the go team figures out the other half
14:36 <+iant> when discussing semicolons we were really concerned by
Javascript
14:36 <+iant> because we've heard from many people that their semicolon rule
is incomprehensible
14:37 <+iant> so we steered far away from that by making ours purely lexical
14:37 <+iant> so it may be odd, but it is clear
14:37 < skelterjohn> i like the idea of having semicolons only used in
multi-statement lines
14:37 < pfroehlich> skelterjohn: sounds like Python :-D
14:37 < skelterjohn> python has a lot of good aspects
14:37 < skelterjohn> originality is not the most important thing
14:37 < exch> javascript lends itself to evil tricks like: return /* \n */ {
id: 0} whereas this will not work: return \n { id: 0 }
14:38 < exch> commenting invisible code ftw
14:38 < bartbes> lua has multiple statements without semicolons
14:39 < bartbes> but semicolons make it more readable
14:39 < skelterjohn> i think having semicolons only used to separate the
different parts of control statements is a good idea
14:39 < skelterjohn> ie for a;b;c and if a;b
14:39 -!- perdix [~perdix@sxemacs/devel/perdix] has quit [Quit: A cow.  A
trampoline.  Together they fight crime!]
14:39 < skelterjohn> at least, i can't think of any other ways i use them
right now
14:39 < bartbes> I think the biggest disadvantage for me is having to use {}
for single-line if statements
14:40 -!- perdix [~perdix@sxemacs/devel/perdix] has joined #go-nuts
14:40 <+iant> that is not a consequence of the semicolon rule per se
14:40 < skelterjohn> i just don't do single line if statements
14:40 < skelterjohn> i don't feel like removing carriage returns adds
readability
14:41 < skelterjohn> i wish xcode would do some auto-indenting for me,
though
14:41 < skelterjohn> i miss that about other IDEs
14:41 < nf> iant: peter's comments are hyperbolic in the extreme IMO
14:41 <+iant> emacs is auto-indenting pretty well these days, it must be
possible to do it with xcode
14:41 < skelterjohn> i don't like using emacs for multiple files, really :\
14:41 <+iant> nf: yeah, I'm glad to hear that people here don't see it has a
showstopper
14:42 < nf> i've never once encountered an issue because of Go's current
semicolon-insertion scheme
14:42 <+iant> although I think we can all agree it is a bit weird
14:42 < nf> i think it's suboptimal, but its behaviour is predictable (As
has been pointed out by you and others)
14:42 < nf> i think that's the most important thing
14:42 < exch> every language has it's own peculiarities I suppose.  I doubt
you can prevent getting rid of all of them
14:42 < nf> and certainly a core tenant of Go's design - predictability
14:43 < bartbes> sure, every language has it quirks, and I prefer my quirks
defined
14:43 < pfroehlich> nf: a language with a syntax this close to C and Java
that is not free form, that's unpredictable
14:43 < exch> and I agree, the current behaviour is clearly defined.  Which
pretty much makes it a non issue as far as I'm concerned
14:43 * nsf doesn't care about semicolons much..  it's just a matter of habit,
unlikely plays big role in doing more work
14:43 < pfroehlich> but i agree with an earlier comment that this is mostly
philosophical
14:44 < skelterjohn> pfroehlich: i don't see go as borrowing anything from
java except maybe the interface keyword
14:44 < nf> pfroehlich: once you accept that it's not free form, it's no
longer confusing
14:44 < pfroehlich> it doesn't impede writing go code once you realize that
it's not really free form
14:44 < nf> skelterjohn: i think he's referring to the algol-esque curly
brace block style
14:44 < pfroehlich> it just becomes a pain when you have to switch styles
between C and Go and stuff
14:45 < skelterjohn> algol is before my time, but does java have any curly
brace stuff you don't see in C or C++?
14:45 < pfroehlich> nf: algol didn't use curly braces :-D
14:45 < nf> pfroehlich: buh, where did i get that from?
14:45 < nsf> pfroehlich: or it's a good way to forget about C :)
14:45 < exch> If you really want to get rid of expression/line terminators
then go for a RPN language :)
14:45 < pfroehlich> nf: bcoz you're right to some extent, if you replace
being and end with { and } you're there
14:46 < pfroehlich> exch: FORTH++ :-D
14:46 < skelterjohn> exch: there was someone rambling about FORTH
14:46 < skelterjohn> lol
14:46 < exch> hehe RPN sure has it's own peculiarities and is definitely not
for everyone
14:46 < skelterjohn> something about how it was the most perfect language,
and the reason why more people didn't use it was because they weren't smart enough
14:47 <+iant> on the other hand I always very productive in Scheme which is
guess is just plan PN
14:47 <+iant> Forth I always found rather painful, but perhaps I'm just not
smart enough
14:47 < skelterjohn> scheme takes me a long time to write
14:48 < skelterjohn> or debug, rather
14:48 < nf> the small amount of scheme i wrote left me feeling very
satisfied indeed
14:48 < nf> but it just wasn't practical for most stuff i needed to do
14:49 < exch> I have that with postscript :p Nice to write something that
actually works, but beyond printable documents, it's not very useful
14:50 <+iant> thanks; biab
14:51 -!- iant [~iant@67.218.107.123] has quit [Read error: Connection reset by
peer]
14:51 < exch> I managed to make it a bit more versatile as a go scripting
language, but it needs a lot of work.  A fibonacci sequencer isn't particularly
ground breaking
14:51 < exch>
http://github.com/jteeuwen/Tinyscript/blob/master/doc/scripts/fibonacci.tsc still.
it'
14:52 < exch> *it's sexy to behold :)
14:52 < nf> exch: cute!
14:53 -!- skelterjohn [~jasmuth@c-76-116-181-134.hsd1.nj.comcast.net] has quit
[Quit: skelterjohn]
14:54 -!- cbeck [~cbeck@c-67-170-181-181.hsd1.or.comcast.net] has quit [Ping
timeout: 260 seconds]
14:57 -!- emmanueloga [~emmanuelo@190.247.41.202] has quit [Ping timeout: 245
seconds]
14:59 -!- emmanueloga [~emmanuelo@190.247.41.202] has joined #go-nuts
15:00 -!- emmanueloga [~emmanuelo@190.247.41.202] has quit [Excess Flood]
15:01 -!- vdrab [~vdrab@cap012-213.kcn.ne.jp] has quit [Quit: vdrab]
15:02 -!- emmanueloga [~emmanuelo@190.247.41.202] has joined #go-nuts
15:03 < plexdev> http://is.gd/d0Fs3 by [Russ Cox] in 2 subdirs of go/ -- gc:
fix crash for nested complex division
15:04 -!- iant [~iant@nat/google/x-yojemxhtcgpnvbuf] has joined #go-nuts
15:04 -!- mode/#go-nuts [+v iant] by ChanServ
15:14 -!- maht [~maht__@85-189-31-174.proweb.managedbroadband.co.uk] has quit
[Ping timeout: 265 seconds]
15:22 < nf> so, i'm hosting a Go hackathon in London this saturday
15:22 < nf> and i'm trying to think up project ideas to suggest
15:22 < nf> there's a lot of library stuff that can be done, but i don't
have a particular itch to scratch so i'm feeling a little stuck for ideas
15:23 < nf> anyone got stuff they'd like to see?  or just ideas in general?
15:24 -!- zozoR [~zozoR@0x5da69cf2.cpe.ge-0-1-0-1105.hsnqu1.customer.tele.dk] has
quit [Quit: Morten.  Desu~]
15:24 < MizardX> Extend the regex library.  It is missing a few features
that makes it a little unconfortable to use.
15:24 -!- LeNsTR [~lenstr@unaffiliated/lenstr] has joined #go-nuts
15:24 -!- maht [~maht__@85.189.31.174.proweb.managedbroadband.co.uk] has joined
#go-nuts
15:25 < nf> i have a friend that is already working on an implementation of
re2
15:25 < nf> http://code.google.com/p/re2/
15:26 < MizardX> He's making an implementation in Go?
15:26 < nf> yes
15:27 -!- skelterjohn [~jasmuth@lawn-net168-in.rutgers.edu] has joined #go-nuts
15:29 -!- kanru [~kanru@118-168-235-167.dynamic.hinet.net] has quit [Read error:
Operation timed out]
15:31 -!- emmanueloga [~emmanuelo@190.247.41.202] has quit [Ping timeout: 245
seconds]
15:33 < MizardX> Another idea: A collection framework, รก la Google
Collections.
15:34 < skelterjohn> I think a well put together library for collections of
types other than the primitives would be a good idea
15:34 -!- tvw [~tv@e176003052.adsl.alicedsl.de] has joined #go-nuts
15:35 < skelterjohn> for now, can do things like map[string]bool to do a set
15:36 < skelterjohn> there was some discussion on the list about people
doing experiments in this direction
15:37 < skelterjohn> don't recall how it turned out
15:38 < skelterjohn> should ask around on the list.
15:38 -!- plainhao [~plainhao@mail.xbiotica.com] has joined #go-nuts
15:39 -!- ShadowIce [pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts
15:46 -!- pfroehlich [~chatzilla@c-98-204-215-206.hsd1.md.comcast.net] has quit
[Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401074458]]
15:49 -!- emmanueloga [~emmanuelo@190.247.41.202] has joined #go-nuts
15:51 -!- pjm0616 [~user@61.250.113.98] has quit [Ping timeout: 240 seconds]
15:52 -!- pjm0616 [~user@61.250.113.98] has joined #go-nuts
15:54 -!- Atlas2070 [~ender2070@bas3-toronto63-1096719434.dsl.bell.ca] has joined
#go-nuts
15:58 -!- visof [~visof@unaffiliated/visof] has quit [Ping timeout: 264 seconds]
15:58 -!- h43 [xfsz@193.219.39.203] has left #go-nuts []
15:58 -!- mxweas [~max@c-98-225-102-170.hsd1.az.comcast.net] has quit [Quit: Mac
has gone to sleep]
16:00 -!- mxweas [~max@c-98-225-102-170.hsd1.az.comcast.net] has joined #go-nuts
16:00 -!- emmanueloga [~emmanuelo@190.247.41.202] has quit [Quit: WeeChat
0.3.3-dev]
16:01 -!- mxweas [~max@c-98-225-102-170.hsd1.az.comcast.net] has quit [Client
Quit]
16:01 -!- MizardX [~MizardX@unaffiliated/mizardx] has quit [Read error: Connection
reset by peer]
16:02 -!- MizardX [~MizardX@unaffiliated/mizardx] has joined #go-nuts
16:05 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 260 seconds]
16:09 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts
16:13 -!- sahid [~sahid@lev92-4-88-164-132-26.fbx.proxad.net] has quit [Quit:
Ex-Chat]
16:15 -!- InaVegt_ [~InaVegt@dsl-087-195-206-242.solcon.nl] has joined #go-nuts
16:15 < mpl> nf: I'd like at least a resize function for images.  if not
native, cgo bindings to imagemagick would do I guess.
16:15 -!- InaVegt [~InaVegt@dsl-087-195-206-242.solcon.nl] has quit [Read error:
Connection reset by peer]
16:16 < nf> mpl: that's a nice idea
16:16 < mpl> nf: no worries though, I'll get to it if noone does ;)
16:16 < nsf> first of all we need good image.Image interface
16:17 < nsf> current abstraction sucks
16:18 < nf> nsf: what do you dislike about it?  (i haven't used it much)
16:18 < nsf> pixel-based access to image data
16:19 < nsf> it should provide some kind of linear access, because it's how
the data is in the memory
16:19 < nf> like a [b]yte ?
16:19 < nf> []byte ?
16:19 < nsf> []byte or []Pixel or whatever
16:19 < nsf> but not like GetPixel(x, y int) Pixel
16:21 < nsf> I like QImage interface from Qt
16:21 < manveru> hmm
16:21 < nsf> maybe there are better variants to consider
16:21 < nf> there already is
16:21 < nf> you just need to use NRGBA
16:21 < nf> or RGBA
16:22 < nsf> nf: the problem is
16:22 < nf> or Paletted, or some other explicit image type
16:22 < nsf> let's say png loader
16:22 < nsf> returns image.Image
16:22 < nsf> maybe I should convert that interface to a concrete type
16:23 < nf> yeah i think that's the key
16:23 < nsf> but I don't see a point why I should do that
16:23 < nf> you can do a type switch on it
16:23 < wrtp> nsf: with the current scheme, you can slice a rectangle out of
an image without copying the pixels
16:24 < wrtp> so the data is not necessarily linear
16:24 < nf> nsf: they each have different representations for Pixel
16:24 < nf> nsf: your app still needs to know how to use it
16:24 < nsf> wrtp: it should be linear
16:24 < wrtp> why?
16:24 < nsf> because it's efficient
16:25 < wrtp> the current scheme can be efficient too
16:25 < nsf> let's say for example how would you do generic blit algorithm
with image.Image
16:25 < wrtp> you don't have to do two array lookups for each pixel
16:25 < nsf> copying pixel by pixel or type switching?
16:25 < nsf> neither are good
16:26 < nsf> there is only one array lookup always
16:26 < nsf> y * width + x
16:26 < nsf> per pixel
16:26 < nsf> and in a lot of algos you can avoid that too
16:26 < nsf> by processing everything line by line
16:26 < wrtp> sure, but currently you can do: row := image.Pixels[y] and
then do direct access into the row
16:27 < nsf> http://golang.org/pkg/image/#Image I can't see Pixels there
16:27 < nsf> wrtp: another case..  I want to upload an image to the OpenGL
api?
16:27 < nf> RGBA.Pixels[y][x] is just as efficient as pixels[y*width+x]
16:27 < nsf> now your [][] sucks
16:27 < wrtp> i can't see anything that specifies linear vs not linear in
the Image interface either
16:28 < nsf> actually I don't see a need for 2d arrays in go, I think they
are not necessary
16:28 < wrtp> there's nothing stopping you doing y*width + x behind the
scenes
16:28 < skelterjohn> in http://code.google.com/p/gomatrix for the dense
matrix implementation, i show how you can still use linear data access while
looking at subsections of your whole thing
16:28 < skelterjohn> whether its a matrix or an image
16:28 < skelterjohn> ryanne dolan showed me how to do it, i don't know if it
is a common trick or not
16:28 < nsf> wrtp: exactly!  there is no info simply about that
16:28 < nsf> that's the problem
16:28 < nsf> imaging is always about accessing memory fast
16:28 < nsf> and linear is fast
16:28 < nf> wrtp: not in the image interface, its in the types that satisfy
Interface
16:28 < nsf> if image abstraction doesn't specify this
16:28 < nsf> it sucks
16:29 < skelterjohn> and if you have a [][] you have to take tons of slices.
if you do the trick in gomatrix, you take only one slice
16:29 < wrtp> i don't see why that's a problem.  it's a high level
interface.
16:29 < nsf> it is useless
16:29 < nsf> why do you need that interface?
16:29 < nf> skelterjohn: looks cool
16:29 < wrtp> if you want access to the raw pixels, you specify the type of
the image e.g.  image.RGBA
16:29 < nsf> building "generic" algorithms on top of it?
16:29 < nsf> you will be able to do them, but they will be slow
16:30 < wrtp> the speed comes from the inner loop, and the row access is not
in the inner loop
16:30 < nsf> Go suffers a lot from interfaces everywhere I think
16:31 < skelterjohn> nsf - i think that you should make a new version of the
image package and submit it for inclusion
16:31 < nsf> skelterjohn: I won't ever do that :D
16:31 < skelterjohn> no one is going to do it just from you complaining ;)
16:31 < nsf> and you're right
16:31 < nsf> so I'm stopping
16:31 < skelterjohn> that's not what i meant
16:32 < skelterjohn> a lot of things in the standard library are "first try"
implementations of something in a new language
16:32 < skelterjohn> a lot of things could probably be done better
16:32 < nsf> exactly
16:32 < wrtp> nsf: what would a "linear" version of the image interface look
like?
16:32 < nsf> what I'm trying to say
16:32 < wrtp> or would you eschew the interface entirely?
16:32 < nsf> if someone will try to write image stuff, please consider
changing the interface
16:32 < nsf> wrtp: QImage
16:32 < wrtp> that's what i want to know: what would your interface look
like?
16:33 < nsf> I would like to see functions like: bytes() []byte
16:33 < nsf> scanLine(i int) []byte
16:33 < skelterjohn> what if your image format can't hold a pixel in a byte?
16:34 < nsf> it always can hold all the pixels in []byte
16:34 < nsf> because it's a memory primitive
16:34 < skelterjohn> well, sure.  i suppose that was a silly question.
16:34 < nsf> you see there are a lot of APIs that use that fact when working
on images
16:34 < nsf> and we're not inventing here anything
16:34 < nsf> image.Image should be able to interact with those
16:34 -!- jsj_ [~jsj@cust-IP-245.data.tre.se] has joined #go-nuts
16:35 < skelterjohn> eh, i downplay the idea that things done in go should
mesh cleanly with existing software
16:35 < wrtp> i'm not sure why []byte is faster than []image.RGBAColor
16:35 < nsf> no one do things like: RGBA8888 : public Image; RGBA4444 :
public Image
16:35 < skelterjohn> there are more reasons than "good design" for a library
to become popular
16:36 < nsf> wrtp: it's not
16:36 < nsf> you don't need array of Pixels
16:36 < nsf> because there are things like image padding (for fast memory
access)
16:36 -!- jsj [~jsj@c83-252-23-207.bredband.comhem.se] has quit [Ping timeout: 260
seconds]
16:36 < nsf> and array of a data structure can't do that
16:36 < nsf> []byte can
16:37 < skelterjohn> what is image padding
16:37 < skelterjohn> and why can you do it with []byte and not
[]struct{uint16,uint16,uint16,uint16}?
16:37 < nsf> when image lines are located in aligned memory regions
16:38 < wrtp> there's nothing stopping the image lines being located in
aligned memory regions in the current implementation
16:38 < nsf> skelterjohn: you can, but it's just one case
16:38 < nsf> wrtp: ugh..
16:38 < skelterjohn> well, this is over my head, so i'm gonna be quiet
16:38 < wrtp> doesn't seem too bad to me.  each slice points to a different
subslice of the whole array, each aligned appropriately
16:39 < nsf> I won't argue with you guys simply because I'm not able to
explain all this to you
16:39 < wrtp> the underlying data is linear
16:39 < wrtp> i just don't see where your performance gain comes from.
16:39 < nsf> it's not only about performance
16:39 < wrtp> only on operations that span multiple lines, AFAICS
16:39 < wrtp> oh
16:39 < nsf> a) usability, you need to be able to interact with extern APIs
like OpenGL
16:40 < nsf> b) performance, if you do generic interface it should be
possible to express fast generic algorithms based on it
16:40 < nsf> and that's for the start
16:40 < wrtp> why can't you do a) with the current implementation?
16:40 < cgo|sucks> nsf++
16:41 < nsf> wrtp: well, you can, if you cast underlying image.Image to a
concrete type with a known data layout
16:41 < wrtp> nsf: that's common practice
16:41 < cgo|sucks> wrtp: compile extensions cleanly for a start (add your
stars here http://code.google.com/p/go/issues/detail?id=857)
16:41 < nsf> my point is you don't need even that kind of abstract
image.Image
16:42 < nsf> simply because this abstract image.Image does nothing usual
16:42 < nsf> useful*
16:43 < wrtp> the abstract image.Image is useful for a slow fallback.  there
are lots of places where image operations do not have to be blindingly fast.
16:43 < nsf> the have to, because it's solved problem
16:43 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:c80a:5a88:d1c1:44f3] has joined
#go-nuts
16:43 < nsf> we have processors now and special ones (GPUs) that rely on the
fact how images are presented in the memory
16:44 < wrtp> nsf: that's fine.  implement GPUImage.
16:44 < nsf> even SSE instructions and current CPU architecture in general
about that
16:44 < nsf> wrtp: I can, but then why do I need image.Image?
16:45 < nf> nsf: you don't
16:45 < wrtp> nsf: because it means it's easy to write a simple generic
algorithm that will work on all images.  it won't be fast, but it often doesn't
need to be.
16:45 < nf> nsf: but you can implement it, so that anything that uses
image.Image can use your new type :)
16:45 < nsf> wrtp: if it's not fast, I won't use it, I'll continue to write
my own C libraries for that :D
16:46 < nsf> nf: well, I do understand that image.Image is not forced
anywhere
16:46 < nsf> like type hierarchy in C++
16:46 < nsf> but I do think it's useless
16:46 < wrtp> nsf: if you're creating an image (e.g.  a sprite) at the start
of your code that will be used many times when running, then it doesn't matter
much how fast that initial operation is
16:47 < wrtp> for instance, it might be slow doing a truetype render of a
character, but if you render into an alpha mask, then you only have to do it once
16:47 < nsf> image.Image is just a broken abstraction..  there is no pixel
"At", there are pixels and there are many of them
16:48 < mpl> how about stenography?  you need to be able to access the 100th
pixel to encode your letter there ;)
16:49 < nsf> anyway, these are just my thoughts..  I'm not writing
anything..  maybe someone will come up with a good idea for image library
16:51 < nsf> mpl: you need access to pixels, I'm not saying that you don't
16:51 < wrtp> nsf: you could suggest how you'd *like* to be able to access
images
16:51 < wrtp> the only alternatives i can think of are really quite complex
16:51 < nsf> wrtp: I've said many times that..  see QImage class in Qt
library
16:51 < wrtp> and unnecessarily so.
16:52 < nsf> I had pleasure to work with QImage in the past, the only thing
I don't like about that they tend to use premultiplied alpha format too much
16:52 < wrtp> nsf: they don't support >32bit pixels
16:52 < wrtp> AFAICS
16:53 < nsf> you can add support for that
16:53 < nsf> why not
16:53 < wrtp> setPixel ( const QPoint & position, uint index_or_rgb )
16:54 < wrtp> uint is not usually >32 bits
16:54 -!- ni| [~james@users.vu.union.edu] has joined #go-nuts
16:54 < nsf> I didn't say that it's perfect and suits 100% needs
16:54 < nsf> I like it
16:54 < nsf> though
16:54 < wrtp> anyway, i still don't see the problem.  you can still work
with something like QImage under the covers if you wish
16:55 < wrtp> QImage itself more or less satisfies the Image interface :-)
16:55 -!- Atlas2070 [~ender2070@bas3-toronto63-1096719434.dsl.bell.ca] has quit
[Remote host closed the connection]
16:55 < wrtp> and if the DrawMasker patch i submitted a while ago is
accepted, it can do its own draw ops if it likes
16:56 < nsf> I just don't need an "abstraction" here
16:56 < nsf> I don't like abstractions
16:56 -!- rhelmer [~rhelmer@adsl-69-107-91-225.dsl.pltn13.pacbell.net] has joined
#go-nuts
16:56 < wrtp> i don't like inappropriate abstractions either.  but
image.Image seems ok to me.
16:57 < wrtp> the pixel operations underneath can still be quick.
16:57 < wrtp> no one ever calls Image.At in seriousness
16:57 < nsf> and you can't implement them using abstraction
16:57 < nsf> you always will have to type switch
16:57 < nsf> wrtp: exactly
16:57 < wrtp> you can implement them using abstraction - it's just slowish
16:58 < nsf> if no one do, why do we have it?
16:58 < wrtp> nsf: because it's silly having an image type where you can't
find out what colour is at a given point
16:59 < wrtp> even QImage has it: QRgb pixel ( int x, int y ) const
16:59 < nsf> it's silly for a newbie student, every graphics programmer
knows that accessing pixels directly one by one is stupid
16:59 < wrtp> are you saying that function shouldn't exist?
16:59 < wrtp> it depends on the operation!
16:59 < nsf> it should, but there should be more of them
17:00 < nsf> current image.Image has only this function and nothing else
(more or less)
17:00 < nsf> the abstraction is too abstract I'd say
17:00 < wrtp> you can't have more in the image interface without dictating a
particular underlying storage strategy.  the whole point of Image is that it
abstracts away from the storage strategy.
17:00 < mpl> that is quote worthy
17:01 < wrtp> if you want lower level, then type switch
17:01 < mpl> "the abstraction is too abstract" :)
17:01 < nsf> wrtp: you don't need that :)
17:01 -!- ExtraSpice [~ExtraSpic@78-62-86-161.static.zebra.lt] has quit [Quit:
Leaving]
17:01 < wrtp> then you know exactly how your pixels are stored
17:01 < nsf> as you even said before, no one uses At function
17:01 < wrtp> and you can access them as quickly as you like
17:02 < nsf> why do we have an interface where mostly used function that no
one uses is "At"
17:02 < nsf> :)
17:02 < wrtp> "mostly used"?
17:02 < nsf> well, sort of
17:03 < nsf> my point is that interface is useless
17:03 < nsf> it serves more or less like {}interface
17:03 < mpl> nsf: why don't you ask directly to the devs on go-nuts?  we'd
all like to know the answer to that :)
17:03 -!- jsj_ [~jsj@cust-IP-245.data.tre.se] has quit []
17:04 < nsf> mpl: I don't want to try, bad experience with that..  I'd
rather flame a bit, and tomorrow everyone will forget about that talk :)
17:04 < mpl> well we shouldn't forget about it if it's valid.
17:05 < nsf> it it's valid point, then the time will fix that sooner or
later
17:05 < nsf> it's how open source projects live :)
17:05 < mpl> true.
17:05 < nsf> and you know, I'm complaining yes, but I don't have anything to
offer too
17:06 < mpl> nf: anyway, please keep me posted if you start something about
images in your hackathon, I'd like to follow that closely.
17:06 < nsf> people don't like that in general
17:06 < wrtp> so...  we seem to have moved on to a philosophical objection
to the Image interface, which is more or less impossible to argue with.  i was
more interested in your assertion that the current scheme is necessarily
inefficient.  are you still saying that?
17:06 < wrtp> because that's more of a problem if so
17:07 -!- terrex [~terrex@226.38.222.87.dynamic.jazztel.es] has joined #go-nuts
17:07 < nsf> wrtp: nope, I'm saying that image.Image is inefficient, because
obviosly if you need speed you will type switch
17:07 < wrtp> ok, that's fine then
17:07 < wrtp> BTW, if i wanted an image resizer, i'd phrase it in terms of
image.RGBA not image.Image
17:07 < nsf> and because it has that property, I consider it as useless
17:08 < wrtp> nsf: speed isn't everything...
17:08 < nsf> sometimes yes, sometimes it's important
17:08 < wrtp> yup.  so "useless" is a bit strong there
17:09 < nsf> ok, image.Image has very limited use :)
17:10 < wrtp> it's useful for offline image processing.  it's a lowest
common denominator that ensures that any Image can talk to any other Image
regardless of the underlying implementation.
17:10 < wrtp> when you need speed, you can ensure that.
17:10 < nf> mpl: great
17:12 < nsf> I can't say it's "useful"
17:12 < nsf> image libraries like PIL are more useful to me :)
17:12 < nsf> but that's in general about "image" packages
17:14 < wrtp> sure.  there's a lot to be done yet...
17:14 -!- rhelmer [~rhelmer@adsl-69-107-91-225.dsl.pltn13.pacbell.net] has quit
[Quit: rhelmer]
17:14 < wrtp> but i personally don't think the current stuff is a bad place
to start
17:16 -!- rv2733 [~ron@c-98-242-168-49.hsd1.fl.comcast.net] has joined #go-nuts
17:17 < nsf> maybe, maybe
17:18 < nsf> but I still think what I think :D
17:19 < nsf> wrtp: btw!
17:19 < nsf> have you seen my mandelbrot demo?
17:20 < nsf> even though it has no panning yet it works quite fast with 1024
iterations
17:23 * skelterjohn wonders about the bug he was having before getting rog-go
working
17:24 < nsf> oh and yes, on a single core :D
17:24 < nsf> I have two goroutines basically one is drawing OpenGL and other
is rendering mandelbrot
17:25 < skelterjohn> what do you render to?
17:25 < nsf> a texture
17:25 < skelterjohn> so everything is rasterized off the gpu?
17:25 < nsf> yes
17:26 < nsf> because I will eventually do the same thing with tiles and
multiple goroutines
17:26 < wrtp> nsf: i can't use the opengl stuff
17:26 < skelterjohn> i'd really like to get some basic opengl functionality
working on this machine
17:26 < nsf> :(
17:26 < nsf> skelterjohn: you have Mac aren't you?
17:26 < skelterjohn> yeah
17:26 < skelterjohn> haven't been able to get any of the go-sdl/go-opengl
stuff i've tried working
17:26 < nsf> in the ML someone describe a lot how to set these things up
17:27 < wrtp> me neither
17:27 < exch> gosdl is working fine for me
17:28 < skelterjohn> exch: which implementation?  and you mean on os x?
17:28 < exch> ah nope.  on Linux.
17:28 < nsf> skelterjohn: in this thread see second message:
http://groups.google.com/group/golang-nuts/browse_thread/thread/0b4a50771ad2398d
17:28 < skelterjohn> thanks, nsf
17:29 < nsf> looks complicated to me
17:29 < exch> i have this version http://github.com/manveru/Go-SDL
17:30 < exch> it's a fork from banthar's project
17:30 < nsf> interestring, what's different here?
17:30 < nsf> interesting*
17:30 < exch> not sure really.  I haven't compared the two.  I'm just glad
this one works :p
17:31 < nsf> looks like the same
17:31 < nsf> the "release" branch
17:31 < nsf> there are few changes in "master" branch however
17:31 -!- marsu [~marsu@93.12.59.164] has joined #go-nuts
17:37 -!- ExtraSpice [~ExtraSpic@78-62-86-161.static.zebra.lt] has joined #go-nuts
17:38 < manveru> exch: he merged all my changes already
17:39 < exch> fair enough
17:39 -!- gnrfan [~gnrfan@lab.aureal.com.pe] has joined #go-nuts
17:39 < manveru> no idea about why osx is so broken
17:40 < manveru> anw, you might enjoy
http://github.com/manveru/opengl-go-tutorials
17:40 -!- napsy [~luka@88.200.96.14] has joined #go-nuts
17:40 < manveru> haven't had time to do more, but it should give you a good
start
17:45 -!- Fish [~Fish@9fans.fr] has joined #go-nuts
17:46 -!- ikke [~ikkibr@unaffiliated/ikkebr] has joined #go-nuts
17:55 -!- tvw [~tv@e176003052.adsl.alicedsl.de] has quit [Ping timeout: 265
seconds]
17:59 -!- photron [~photron@port-92-201-83-202.dynamic.qsc.de] has joined #go-nuts
18:00 -!- pfroehlich [~chatzilla@c-98-204-215-206.hsd1.md.comcast.net] has joined
#go-nuts
18:03 -!- ioricloud [~henrique@unaffiliated/ioricloud] has joined #go-nuts
18:03 -!- kixgo [~renato.be@89-201-147-159.dsl.optinet.hr] has joined #go-nuts
18:05 -!- sheb [~seb@AToulouse-152-1-24-190.w82-125.abo.wanadoo.fr] has joined
#go-nuts
18:15 -!- terrex [~terrex@226.38.222.87.dynamic.jazztel.es] has quit [Remote host
closed the connection]
18:18 -!- terrex [~terrex@226.38.222.87.dynamic.jazztel.es] has joined #go-nuts
18:28 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.2]
18:30 -!- cenuij [~cenuij@78.112.253.165] has joined #go-nuts
18:30 -!- cenuij [~cenuij@78.112.253.165] has quit [Changing host]
18:30 -!- cenuij [~cenuij@base/student/cenuij] has joined #go-nuts
18:32 -!- thomas_b [~thomasb@cm-84.215.37.40.getinternet.no] has quit [Ping
timeout: 240 seconds]
18:34 -!- thomas_b [~thomasb@cm-84.215.37.40.getinternet.no] has joined #go-nuts
18:38 -!- emmanueloga [~emmanuelo@190.247.41.202] has joined #go-nuts
18:43 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has joined #go-nuts
18:44 -!- napsy [~luka@88.200.96.14] has quit [Ping timeout: 258 seconds]
18:48 < ioricloud> lol
18:49 < ioricloud> procedure for install go-lang in ubuntu lynx is the same
18:51 < ioricloud> or has something different
18:57 -!- tsykoduk [~tsykoduk@2001:470:1f04:671:20d:93ff:fe77:1dc4] has quit [Ping
timeout: 260 seconds]
18:58 -!- tsykoduk [~tsykoduk@2001:470:1f04:671:20d:93ff:fe77:1dc4] has joined
#go-nuts
19:01 -!- Eridius [~kevin@unaffiliated/eridius] has joined #go-nuts
19:02 < smw> ioricloud, nothing is different
19:02 -!- KinOfCain [~KinOfCain@rrcs-64-183-61-2.west.biz.rr.com] has joined
#go-nuts
19:03 -!- adu [~ajr@pool-71-191-173-125.washdc.fios.verizon.net] has quit [Quit:
adu]
19:08 -!- emmanueloga [~emmanuelo@190.247.41.202] has quit [Quit: WeeChat
0.3.3-dev]
19:11 < ioricloud> smw, ok thanks
19:33 -!- plainhao [~plainhao@mail.xbiotica.com] has quit [Quit: plainhao]
19:52 -!- terrex [~terrex@226.38.222.87.dynamic.jazztel.es] has quit [Ping
timeout: 264 seconds]
19:52 -!- cgo|sucks [~waf@kde/developer/tnagy] has quit [Remote host closed the
connection]
19:55 -!- thiagon [~thiagon@150.164.2.20] has quit [Read error: Connection reset
by peer]
20:00 -!- thiagon [~thiagon@150.164.2.20] has joined #go-nuts
20:08 -!- thiagon [~thiagon@150.164.2.20] has quit [Quit: Leaving]
20:13 -!- circlingthesun [~rickert@196-215-40-64.dynamic.isadsl.co.za] has quit
[Ping timeout: 240 seconds]
20:13 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts
20:18 -!- Ginto8 [~Ginto8@pool-72-82-235-34.cmdnnj.fios.verizon.net] has joined
#go-nuts
20:23 -!- sheb [~seb@AToulouse-152-1-24-190.w82-125.abo.wanadoo.fr] has left
#go-nuts []
20:25 -!- tvw [~tv@e176003052.adsl.alicedsl.de] has joined #go-nuts
20:27 -!- circlingthesun [~rickert@196-210-241-174.dynamic.isadsl.co.za] has
joined #go-nuts
20:27 -!- emmanueloga [~emmanuelo@190.247.41.202] has joined #go-nuts
20:35 -!- skelterjohn [~jasmuth@lawn-net168-in.rutgers.edu] has quit [Quit:
skelterjohn]
20:43 -!- Chryson [~Chryson@c-71-61-11-114.hsd1.pa.comcast.net] has quit [Quit:
Leaving]
20:46 -!- wobsite [~wobsite@68-112-244-225.dhcp.oxfr.ma.charter.com] has joined
#go-nuts
20:50 -!- emmanuel_oga [~emmanuelo@190.247.41.202] has joined #go-nuts
20:51 -!- emmanueloga [~emmanuelo@190.247.41.202] has quit [Ping timeout: 245
seconds]
20:54 -!- artefon [~thiago@189.107.172.68] has joined #go-nuts
21:03 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:c80a:5a88:d1c1:44f3] has quit
[Quit: Leaving.]
21:08 -!- mbarkhau [~koloss@dslb-084-059-163-201.pools.arcor-ip.net] has joined
#go-nuts
21:13 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-181-238.clienti.tiscali.it] has
quit [Quit: E se abbasso questa leva che succ...]
21:16 -!- ExtraSpice [~ExtraSpic@78-62-86-161.static.zebra.lt] has quit [Quit:
Leaving]
21:20 -!- InaVegt [~InaVegt@dsl-087-195-206-242.solcon.nl] has quit [Read error:
Connection reset by peer]
21:24 -!- ikke [~ikkibr@unaffiliated/ikkebr] has quit []
21:24 < cw> iant: is building line-number structures for dwarf[2] very
messy?
21:24 -!- rv2733 [~ron@c-98-242-168-49.hsd1.fl.comcast.net] has quit [Quit:
Leaving]
21:27 -!- micrypt [~micrypt@94-195-127-212.zone9.bethere.co.uk] has joined
#go-nuts
21:34 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller,
Faster, Easier.  http://miranda-im.org]
21:40 -!- Shyde [~shyde@HSI-KBW-078-043-070-132.hsi4.kabel-badenwuerttemberg.de]
has quit [Quit: Shyde]
21:40 -!- ShadowIce [pyoro@unaffiliated/shadowice-x841044] has quit [Quit:
Verlassend]
21:41 -!- wrtp [~rog@92.17.70.156] has quit [Quit: wrtp]
21:42 -!- Xurix [~Luixsia@AToulouse-254-1-5-26.w83-203.abo.wanadoo.fr] has joined
#go-nuts
21:45 -!- bmizerany [~bmizerany@99.13.242.166] has joined #go-nuts
21:49 -!- ioricloud [~henrique@unaffiliated/ioricloud] has quit [Quit: Ex-Chat]
21:50 -!- nsz [nsz@morecp.net] has quit [Ping timeout: 260 seconds]
21:58 -!- Adys [~Adys@unaffiliated/adys] has quit [Ping timeout: 245 seconds]
21:59 -!- Fish [~Fish@9fans.fr] has quit [Remote host closed the connection]
21:59 -!- tvw [~tv@e176003052.adsl.alicedsl.de] has quit [Remote host closed the
connection]
21:59 -!- Xurix [~Luixsia@AToulouse-254-1-5-26.w83-203.abo.wanadoo.fr] has quit
[Quit: Leaving]
22:00 -!- nsz [nsz@morecp.net] has joined #go-nuts
22:02 <+iant> cw: the DWARF line number encoding is basically a mapping from
PC to location
22:02 <+iant> the mapping is encoded to make it efficient: you say things
like "advance N bytes to the next location"
22:03 <+iant> it's not trivial but it's not too bad
22:03 <+iant> the specs are at http://dwarfstd.org/
22:03 -!- Adys [~Adys@unaffiliated/adys] has joined #go-nuts
22:04 <+iant> in the GNU binutils gas/dwarf2dbg.c is a relatively simple
DWARF line number generator, to get debugging info for assembler source
22:06 < cw> ok, ill go look over that
22:06 <+iant> cool
22:06 <+iant> that would be nice
22:07 < cw> i did once before and for some reason recall it was a lot more
thorny than i thought it would be
22:07 < cw> does line number information also contain reference to the
filenames?  (i assume it must)
22:07 <+iant> well, it is more thorny than what one might naively expect,
but since you already expect that you should be OK
22:07 <+iant> yes
22:07 <+iant> I forget the exact details
22:08 < cw> i assume with line information details gdb will work in so far
as step, until, etc
22:08 <+iant> yes, it should
22:08 <+iant> also breakpoints
22:08 < cw> which whilst a far-cry from being great is better than nothing
22:08 < cw> yeah, i do b *0x...  now :-)
22:08 < cw> using 6nm
22:08 <+iant> me too
22:08 < cw> in truth it's not nearly painful enough to really care that much
about in some cases
22:09 <+iant> yeah, the compilation turnaround is so fast that fmt.Printf
debugging becomes reasonable
22:09 <+iant> but still a debugger would sometimes be nice
22:09 < cw> but a debugger would need so much more
22:09 < cw> type/variable inspection
22:09 <+iant> well, true
22:09 < cw> i think for gdb that will be hard (maybe not possible w/o gdb
hacks)
22:09 < cw> also some idea of runtime internals
22:10 < cw> gdb knows about threads ...  go doesn't really have threads
though
22:10 <+iant> in principle 6g could generate DWARF type and variable
location information
22:10 <+iant> gdb has an abstract interface for thread, so it could learn
about goroutines
22:10 <+iant> in principle
22:10 <+iant> I once taught gdb about threads in RTEMS
22:10 <+iant> which was entirely different from threads in Unix
22:11 < cw> are they?  i assumed it was one stack per thread, local
registers, etc
22:11 < cw> from an OS PoV and application
22:11 <+iant> yeah, that part is the same, but what is different is finding
the current set of threads, discovering when a new thread is created, when one
goes away, etc.
22:12 -!- nsz [nsz@morecp.net] has quit [Ping timeout: 240 seconds]
22:12 < cw> sure, but w/ Go a goroutine doesn't have a 1:1 relationship with
an OS thread
22:12 < cw> the only think that definitively knows about goroutine
boundaries in the runtime
22:12 < cw> s/think/thing/
22:12 <+iant> right, but gdb's thread support could be adjusted for the "go"
target to use goroutines instead of OS threads
22:12 -!- wobsite [~wobsite@68-112-244-225.dhcp.oxfr.ma.charter.com] has quit
[Quit: Leaving]
22:12 <+iant> it would probe runtime internals to find the goroutines
22:12 < cw> gdb would have to grovel about in some exported structures
22:12 <+iant> that's how it worked for RTEMS, I think
22:12 <+iant> yes
22:12 < cw> smells hard
22:13 <+iant> it's not too crazy because gdb actually knows exactly what
those structures look like
22:13 <+iant> assuming we first get 6g to generate the type information
22:13 < cw> you've hacked on gcc/gdb/binutils for what, a decade or more
now?
22:13 < uriel> iant: what is the status of garbage collection with gccgo?
22:13 <+iant> I onl ywish
22:13 <+iant> it's two decades now
22:13 <+iant> gccgo still has no garbage collectoin, that is my next task
after I update the library to current
22:14 <+iant> SWIG took far longer than I thought it would
22:14 < cw> iant: what gc are you planning to use?  a port of the one in the
runtime?
22:14 <+iant> yes, I'm using the same memory allocation as the 6g runtime,
I'll just use the same garbage collector
22:14 <+iant> then when that one gets better it will be easy to move the
better one into gccgo
22:14 < cw> do you have to beat up the existing runtime badly to make it
work?
22:15 < cw> i assume in places you do, calling convention differences and
all
22:15 <+iant> I'm only really using the memory allocation, and that only
required minor changes
22:15 < uriel> iant: I see, keep up the good work :)
22:15 <+iant> using the rest of the runtime would be hard
22:15 < cw> it would be nice to find a way to unify them ...  and i like the
n:1 model in 6g in some ways
22:15 <+iant> yeah, that is a long-term goal
22:15 <+iant> but hard
22:16 < uriel> iant: what is the status of the 'new' GC for gc?  (pun not
intended ;))
22:16 < uriel> still trying to figure out the right approach?
22:16 < cw> i'm surprised someone hasn't started another Go compiler in Go
by now
22:16 <+iant> Russ is tackling it, I'm not sure what the state is
22:16 <+iant> the fact that Go permits interior pointers is a problem
22:17 <+iant> because it makes it slow to go from a pointer to the memory
block
22:17 < cw> that's so nice though
22:17 <+iant> yeah, it's a desirable feature
22:17 <+iant> but most GC languages don't have it
22:17 < cw> i've thought about that myself ...  and really, they are really
nice
22:17 < cw> i've abused them all over the place because i can, it makes
referencesto subarrays wonderful
22:17 <+iant> I don't think Russ has decided exactly how to deal with it
22:18 < cw> but it only makes hte pointer lookup _slower_ surely?  not
fundamentally different
22:18 <+iant> right, only slower, but since GC has to be fast that counts as
a problem
22:18 < cw> use more cores
22:18 * cw waves hands and tells lies
22:18 <+iant> indeed
22:19 < uriel> hehe
22:19 < cw> well, like it or no, you won't get your 10GHz CPU ...  nor will
i ...  but you might get 16 cores in your laptop
22:19 <+iant> very true, and we are happy to dedicate a core to GC
22:20 < cw> are you serious?
22:20 < cw> if the core was working a lot of the time that would be
*HORRIBLE*
22:20 < cw> you would drag cache lines about all over the place
22:20 <+iant> well, it would only be working a lot of the time if there were
a lot of garbage
22:20 <+iant> the cache lines are an issue, that is true
22:21 < cw> i already have hacks to minimize pain from numa effects right
now
22:21 < cw> (everything is numa now)
22:21 < cw> well, everything that's 2+ sockets
22:21 < cw> so not laptops
22:22 < cw> iant: a counting gc would amortize the interior pointer costs
over the users not the GC
22:23 <+iant> yes, and we may still go that way
22:23 < cw> that would probably be nicer for lotsacores systems
22:23 < cw> that's going to screw up all my code that makes heavy use on
unsafe
22:23 < cw> s/on/of/
22:24 <+iant> an unsafe.Pointer should still be a pointer
22:24 <+iant> but if you convert to uintptr then there may be trouble
22:24 < cw> i have syscall wrappers ...  mmap for hugetlbfs and some other
things
22:24 -!- skelterjohn [~jasmuth@c-76-116-181-134.hsd1.nj.comcast.net] has joined
#go-nuts
22:24 < cw> even just mmap of RO file-data to get efficiently at bit-packed
db structures
22:25 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has quit [Remote host closed the
connection]
22:32 -!- ikaros [~ikaros@f052190112.adsl.alicedsl.de] has quit [Quit: Leave the
magic to Houdini]
22:35 -!- welterde [~welterde@not.welterde.de] has quit [Read error: Operation
timed out]
22:35 -!- pfroehlich [~chatzilla@c-98-204-215-206.hsd1.md.comcast.net] has quit
[Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401074458]]
22:36 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has joined
#go-nuts
22:39 -!- smw [~smw@pool-96-232-88-231.nycmny.fios.verizon.net] has quit [Ping
timeout: 265 seconds]
22:46 -!- adu [~ajr@pool-71-191-173-125.washdc.fios.verizon.net] has joined
#go-nuts
22:58 -!- soul9 [~none@unaffiliated/johnnybuoy] has quit [Ping timeout: 276
seconds]
22:58 -!- mbarkhau [~koloss@dslb-084-059-163-201.pools.arcor-ip.net] has quit
[Quit: Leaving.]
23:00 -!- kanru [~kanru@118-168-235-167.dynamic.hinet.net] has joined #go-nuts
23:06 -!- soul9 [~none@unaffiliated/johnnybuoy] has joined #go-nuts
23:07 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Read error:
Connection reset by peer]
23:07 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts
23:09 -!- marsu [~marsu@93.12.59.164] has quit [Quit: Leaving]
23:13 -!- Atlas2070
[~ender2070@CPE00222d6e3608-CM00222d6e3605.cpe.net.cable.rogers.com] has joined
#go-nuts
23:13 -!- ender2070 [~ender2070@bas22-toronto12-2925103372.dsl.bell.ca] has quit
[Disconnected by services]
23:13 -!- Atlas2070
[~ender2070@CPE00222d6e3608-CM00222d6e3605.cpe.net.cable.rogers.com] has left
#go-nuts []
23:17 -!- micrypt [~micrypt@94-195-127-212.zone9.bethere.co.uk] has quit [Ping
timeout: 264 seconds]
23:24 -!- iant [~iant@nat/google/x-yojemxhtcgpnvbuf] has quit [Ping timeout: 260
seconds]
23:33 -!- welterde [~welterde@not.welterde.de] has joined #go-nuts
23:34 -!- rhelmer [~rhelmer@adsl-71-139-219-78.dsl.snfc21.pacbell.net] has joined
#go-nuts
23:36 -!- lux` [~lux@151.71.215.184] has quit [Read error: Connection reset by
peer]
23:38 -!- slashus2 [~slashus2@74-137-24-74.dhcp.insightbb.com] has joined #go-nuts
23:43 -!- nsz [nsz@morecp.net] has joined #go-nuts
23:46 -!- tasklist7 [~tasklist@c-98-208-175-116.hsd1.fl.comcast.net] has joined
#go-nuts
23:46 -!- tasklist7 [~tasklist@c-98-208-175-116.hsd1.fl.comcast.net] has quit
[Client Quit]
23:47 -!- tasklist7 [~tasklist@c-98-208-175-116.hsd1.fl.comcast.net] has joined
#go-nuts
23:48 -!- rhelmer [~rhelmer@adsl-71-139-219-78.dsl.snfc21.pacbell.net] has quit
[Quit: rhelmer]
23:49 -!- tasklist7 [~tasklist@c-98-208-175-116.hsd1.fl.comcast.net] has quit
[Client Quit]
23:50 -!- tasklist19 [~tasklist@c-98-208-175-116.hsd1.fl.comcast.net] has joined
#go-nuts
23:52 -!- iant [~iant@67.218.106.106] has joined #go-nuts
23:52 -!- mode/#go-nuts [+v iant] by ChanServ
23:52 -!- photron [~photron@port-92-201-83-202.dynamic.qsc.de] has quit [Ping
timeout: 260 seconds]
23:54 -!- tasklist19 [~tasklist@c-98-208-175-116.hsd1.fl.comcast.net] has quit
[Client Quit]
23:55 -!- tasklist19 [~tasklist@c-98-208-175-116.hsd1.fl.comcast.net] has joined
#go-nuts
--- Log closed Thu Jun 24 00:00:12 2010