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