--- Log opened Mon Oct 25 00:00:12 2010 00:01 < electrograv> why not just make a function to add an infinite number of some provided endflag value 00:03 < electrograv> I mean an integrated feature of the language 00:03 < electrograv> not a 'function' 00:05 < electrograv> as opposed to always "0" 00:05 < electrograv> actually nevermind I think i misunderstood the topic 00:08 -!- gnuvince_ [~vince@64.235.204.88] has joined #go-nuts 00:09 < electrograv> this has probably been brought up before... but... 00:10 < electrograv> is there really any debate as to whether generics should still be omitted with code like this: 00:10 < electrograv> (comment) CAUTION: If this file is not vector.go, it was generated automatically from vector.go - DO NOT EDIT in that case! 00:11 < Namegduf> It has, yes. 00:11 < Namegduf> A few dozen times, probably. 00:11 < Namegduf> And yes, there is. 00:11 < electrograv> whats the solution then? if not generics) 00:11 < Namegduf> "generics" is not a well-defined feature proposal in itself 00:12 < electrograv> the FAQ just says "We have slices! and maps!" 00:12 < Namegduf> There are many ways you could implement them and many versions of the syntax you could have. 00:12 < Namegduf> And it's sometimes better to have exceptional cases be complex (but understandable) than to complicate the whole language. 00:13 < Namegduf> No generics proposal has been offered that didn't have serious dowsides. 00:13 < electrograv> ok, lets say I need Vectors, PriorityQueues, TreeMaps, and NonblockingQueues... all used with ints, floats, pointers, and a few structs - all being very important to not store on the heap 00:13 < Namegduf> *downsides 00:13 < uriel> electrograv: lets say I need pigs that fly 00:13 < electrograv> but it happens... 00:13 < uriel> electrograv: what about you tell us what you actually need 00:13 < Namegduf> Go is not presently helpful about keeping things off the heap. 00:14 < uriel> rather than making up hypothetical requirements 00:14 < Namegduf> Besides 00:14 < uriel> one of that makes Go great is that it is designed to deal with *real* problems people have when building *real* software 00:14 < Namegduf> You can implement them and use them the same way you would in C. 00:14 < electrograv> this is not hypothetical 00:14 < Namegduf> Go suffers from lack of generics about as much as C, except slightly less. 00:15 < uriel> Go is not about ticking feature checklists, or fulfilling random academic abstract requirements, it is about making building real software esaier and less painful 00:15 < uriel> Namegduf: considerably less I would say, interfaces cover a huge chunk of what generics are used for in other languages 00:16 < electrograv> I know... but I find it painful to have to define three copies of my Vector class, as an example 00:16 < Namegduf> Okay, true. 00:16 < uriel> but nah, lets complain in the abstract rather than actually trying to use Go and finding out how the features it does have play out in practice 00:16 < Namegduf> Type. 00:16 < Namegduf> Not class. 00:16 < uriel> electrograv: why are you using vectors? 00:16 < Namegduf> You would have to do that in C as well, electrograv. 00:16 < uriel> and that you say Vector class shows you are not very familiar with how Go works 00:16 < electrograv> uriel: thanks for the sarcasm, I'm being perfectly practical here though 00:16 < uriel> electrograv: no you aren't 00:16 < Namegduf> Anyways. 00:16 < uriel> electrograv: slices work just fine ~90% of the time 00:16 < electrograv> Namegduf: thats why a lot of projects use C++ 00:17 < electrograv> ok let me be more specific to a situation then 00:17 < Namegduf> electrograv: Sure, but C++ generics are also very very slow to compile. 00:17 < uriel> most people that use Vectors are people that are new to Go and don't realize how well slices work for most things 00:17 < Namegduf> Generics don't HAVE to be (D, etc) 00:18 < electrograv> aren't slices just a pointer to an array? 00:18 < electrograv> along with size info of course 00:18 < Namegduf> Basically, yes, but it's traditional to accept them instead of accepting arrays, as it lets people use bits of an array in place of a whole thing at will. 00:19 < uriel> and what are vectors? if not just a thin wrapper around arrays? 00:19 < uriel> you still didn't tell us why you had to use Vectors instead of slices 00:19 < electrograv> ok 00:19 < Namegduf> Vectors are slices with code to automatically reallocate the backing array when the slice's size matches the full array's size. 00:20 < Namegduf> And it can't grow anymore. 00:20 < electrograv> reallocate the backing array? 00:20 < electrograv> why do you have to reallocate when theres a max size 00:20 < Namegduf> Because there isn't one. 00:20 < Namegduf> That's the point of vectors. 00:21 < Namegduf> Slices are a chunk of an array you can grow as desired up to the maximum size of the array. 00:21 < electrograv> ok anyway 00:21 < electrograv> let me explain why I need more than just slices 00:21 < Namegduf> A vector is a thin wrapper on that that lets you grow it infinitely. 00:21 < electrograv> well, one reason anyway 00:21 < uriel> now that we have append(), I wonder if container/Vector shouldn't be renamed to something more obscure to keep newbies from using it 00:21 < Namegduf> By reallocating the array whenever necessary. 00:21 < nsf> imho devs should eliminate container/Vector from the std lib 00:21 < electrograv> I know slices are chunks of an array... sometimes people need Vectors that grow though beyond the initial allocation without adding manual code everywhere you add an item to do that 00:22 < nsf> after 'append' gets implemented 00:22 < uriel> nsf: I was considering that, but didn't want to be too radical 00:22 < electrograv> whats append()? 00:22 < nsf> electrograv: it's a recent built-in function, already in the spec, but not yet implemented 00:22 < nsf> allows you to append one or more elements to a slice and reallocates if necessary 00:23 < Namegduf> electrograv: Anyways, the reason is simply that all proposals for generics so far are judged as having a cost above their benefit. 00:23 < nsf> v := make([]int); v = append(v, 1, 2, 3); 00:23 < nsf> v == []int{1, 2, 3} 00:24 < electrograv> ok 00:24 < electrograv> still doesnt remove the need for generics 00:24 < electrograv> let me give a simple example 00:24 < Namegduf> There is no "need" for generics. 00:24 < Namegduf> There is merely a benefit from having them. 00:24 < electrograv> there is no "need" for anything beyond assembly 00:24 < uriel> electrograv: you mean 'let me make up an hypothetical example' 00:24 < electrograv> there is merely a benefit from having those languages 00:24 < nsf> C guys does this rule in their standard acceptance practice 00:24 < Namegduf> Right. 00:25 < Namegduf> That is correct. 00:25 < uriel> electrograv: then why shouldn't every language implement every feature imaginable? 00:25 < nsf> "everything that is not implemented yet and haven't proven to work cannot be proposed to the standard" 00:25 < uriel> after all, features have no cost! 00:25 < electrograv> uriel: why do you keep blaming me for being too hypothetical? 00:25 < electrograv> I KNOW that minimalism is good 00:25 < uriel> electrograv: because you refuse to learn to use Go 00:26 < uriel> electrograv: and because you have yet to point any real problems, much less any 'solutions' that don't cause even bigger problems 00:26 < electrograv> you know just as well that every potential feature has a cost/benefit tradeoff that you have to analyze 00:26 < Namegduf> Right, exactly. 00:26 < uriel> yes, we all know having some kind of 'generics' would be nice, but it is *rarely* needed, and nobody has made a proposal that didn't suck 00:26 < electrograv> I still havent given an example 00:26 < uriel> so this discussion is pointless 00:26 < electrograv> and maybe this example isnt even necessary in Go 00:26 < Namegduf> I don't care about your example. 00:26 < electrograv> if so tell me if theres an easy solution 00:26 < Namegduf> I have read like two dozen on the mailing list 00:26 < Namegduf> This has been talked out to death 00:26 < electrograv> lets say you want to create a class that encapsulates an N-dimensional array 00:26 < uriel> electrograv: if you haven't given us your 'example', why have you started to talk about asm and other nonsense 00:27 < Namegduf> You can't use Go. 00:27 < uriel> electrograv: THERE ARE NO CLASSES 00:27 * uriel facepalms 00:27 < Namegduf> Because *Go does not have classes* 00:27 < electrograv> ok fine a "type" 00:27 < electrograv> with "methods" 00:27 < electrograv> and "member variables" 00:27 < uriel> electrograv: not 'ok', if you think Go has classes, you are completely misunderstanding the core of Go's type system 00:27 < uriel> and it shows you have not written any Go at all 00:27 < uriel> and you are just trolling 00:28 < electrograv> ok... lets say you wanted to make a struct, and functions with which to manipulate an N dimensional array stored in that struct 00:28 < uriel> so, go write some go, tell us when you get stuck and need generics, and then we will try to help you out 00:28 < electrograv> I dont understand why I'm misunderstanding Go's type system to refer to a type as a "class" 00:28 < electrograv> I dont like inheritance hierarchies either 00:28 < uriel> a struc for what? an N dimensional array of what? what kind of manipulations? 00:29 < uriel> again, go write some Go code, and let us know when you run into a *real* situation where you 'need' generics 00:29 < electrograv> an N dimensional array of something -- anything, for example (in my very REAL program): 00:29 < uriel> and then we will try to help you out 00:29 < electrograv> (currently written in C++) 00:29 < Namegduf> electrograv: The problem is that if you apply OO methods to writing Go you will create some hideous code 00:29 < uriel> electrograv: no, write something in Go! don't try to translate some random C++ piece of code into Go 00:29 < electrograv> I have a 3D array of attributes storing spatial partitioning data 00:29 < electrograv> ok fine. 00:29 < electrograv> I need a 3D array of attributes storing spatial partitioning data 00:30 < nsf> then implement it 00:30 < nsf> you don't have to make it in a generic way 00:30 < electrograv> and I dont really want to use array[x*size*size + y*size + z] EVERY TIME I access an element 00:30 < electrograv> I much prefer array(x, y, z) 00:30 < Namegduf> This has nothing to do with generics 00:30 < electrograv> this array is dynamic 00:30 < Namegduf> it has to do with operator overloading. 00:30 < electrograv> no 00:30 < electrograv> ok I prefer array.get(x, y, z) 00:31 < electrograv> no operator overloading 00:31 < Namegduf> Seems like you can define a type for your non-generic 3D array 00:31 < Namegduf> And define a method on it. 00:31 < Namegduf> That said, "I prefer" shouldn't appear in a serious idea. 00:32 < electrograv> I prefer to not change 10,000 lines of code because I make a small change somewhere else in code 00:32 < electrograv> thats a serious idea 00:32 < electrograv> and a very important one in design decisions 00:32 < Namegduf> Good for you. 00:32 < Namegduf> However, that doesn't seem to connect to anything else in this conversation, at all. 00:32 < electrograv> I'm giving an example 00:32 < uriel> how does using array[x*size*size + y*size + z] make you change 10,000 lines of code because of a change somewhere else? 00:32 < electrograv> of why "I prefer" can in fact be important 00:32 < uriel> but anyway, defining a method on your own type is fine 00:32 < Namegduf> No, it isn't. 00:32 < uriel> what is the problem? 00:32 < Namegduf> That's a terrible example. 00:33 < electrograv> for example, I dont prefer unnecessarily complex expressions when I can make functions that simplify my code 00:33 < Namegduf> And "I prefer" is not the important part there. 00:33 < Namegduf> That's still not important. 00:33 < uriel> electrograv: you have yet to get anywhere even remotely close to a need for generics 00:33 < electrograv> for example, I like to make functions that reduce boilerplate code typing 00:33 < Namegduf> Still not, technically speaking, relevant. 00:33 < electrograv> array[x*size*size + y*size + z] 00:33 -!- kingfishr [~kingfishr@c-24-130-147-77.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 00:33 < uriel> Namegduf: nor practically either 00:34 < Namegduf> What's important is that there are legitimate code readability and maintenance arguments true for most people behind these things. 00:34 < electrograv> array[x*size*size + y*size + z] is impractical 00:34 < electrograv> not very readible) 00:34 < Namegduf> Compared to *what*? 00:34 < electrograv> compared to array.get(x,y,z) 00:34 < electrograv> array.set(x,y,z) 00:34 < Namegduf> Good for you, go write that. 00:34 < Namegduf> I don't agree, personally 00:34 < electrograv> I'd like to 00:34 < electrograv> except I have to redefine every time I have a new dimension of array, or new type of data in my array 00:35 < electrograv> unless I have templates 00:35 < nsf> reducing an amount of code you type is just plain stupid, 90% of the time you edit and read the code, not type it 00:35 < electrograv> I mean generics 00:35 < nsf> imho 00:35 < electrograv> nsf: repeated code is error prone 00:35 < Namegduf> You would. 00:35 < Namegduf> How often does this happen? 00:35 < Namegduf> How severe is the "cost" and thus the benefit from generics? 00:35 -!- artefon [~thiago@187.114.53.219] has quit [Quit: bye] 00:35 < nsf> electrograv: removing repeated code and reducing an amount of code you need to type is two different things 00:35 < nsf> s/is/are/ 00:35 < electrograv> combinations of at least (2D, 3D, 4D) x (int, float, struct1, struct2) 00:35 < electrograv> in my code 00:36 < electrograv> 4x3 = 12 different implementations of that array get, and set function 00:36 < uriel> the religious fetish for 'code-reuse' is one of the worst evils in the software industry, worse than premature optimization, and the cause of nonsense like inheritance 00:36 < electrograv> 24 functions 00:36 < Namegduf> That's a nice example, but it isn't data. 00:36 < electrograv> this is from my project 00:36 < Namegduf> It's from a single project, yes. 00:36 < Namegduf> How large is said project? 00:36 < electrograv> I say struct1, struct2 because you probably dont care what my actual structs are for 00:36 < electrograv> currently fairly small 00:36 < uriel> electrograv: 12 implementations of one line functions (and all because you consider the usual way too 'vervose')! wow, how awful! 00:36 < electrograv> only about 20,000 lines 00:36 < Namegduf> Sounds like it's a pretty small percentage of the code, then. 00:36 < electrograv> and I believe there may be more types stored in n-D arrays than that 00:37 < electrograv> probably a lot more than 4 now that I think about it 00:37 < electrograv> I should probably look it up 00:37 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has joined #go-nuts 00:37 < electrograv> urial: there are other generics being used here, n-D arrays is just an example 00:37 < Namegduf> Look, it doesn't matter. 00:37 < electrograv> some which have far more than one line implementations 00:37 < Namegduf> You're trying to elaborate on how much not having generics sucks. 00:38 < electrograv> no I'm trying to elaborate on what my project needs 00:38 -!- kingfishr [~kingfishr@c-24-130-147-77.hsd1.ca.comcast.net] has joined #go-nuts 00:38 < Namegduf> We established that "needs" is wrong and inaccurate here. 00:38 < Namegduf> And that you need very little. 00:38 < electrograv> without requiring me to error prone-ly and tedious-ly retype / maintain MANY copies of the same general behavior 00:38 < Namegduf> You said that yourself, actually. 00:38 < Namegduf> That's an arbitrary condition. 00:38 < electrograv> I NEED a safe, error-reducing, simple, and elegant language 00:39 < nsf> electrograv: also note, in some cases generics are good, but that's not the problem, go devs know that 00:39 < nsf> the right proposal is missing 00:39 < Namegduf> You don't "need" that. 00:39 < Namegduf> It has a benefit. 00:39 < Namegduf> Generics also would have a benefit for you. 00:40 < Namegduf> Unfortunately, actual proposals for generics so far hurt the "simple" and "elegant" parts enough that the benefit from generics is less than the loss of simplicity and elegance. 00:40 -!- MaksimBurnin [~max@44.188-224-87.telenet.ru] has quit [Quit: Leaving.] 00:40 < electrograv> I dont need water 00:40 < electrograv> I need water to live 00:40 < electrograv> I dont need generics 00:40 < electrograv> I need generics to keep maintainable, elegant code 00:40 < electrograv> at least as I see it at this point 00:40 < electrograv> but I will try to reimplement some things in Go and see if theres a different elegant approach 00:41 < electrograv> that does not require writing 24 function variants 00:41 < Namegduf> The way you see it is overly simplistic there; maintainability and elegance is not a binary thing. 00:41 < electrograv> of course they're not binary 00:41 < Namegduf> Generics would give you more maintainable, elegant code, I'll believe that. 00:41 < Namegduf> That does not constitute a "need". 00:41 < electrograv> but 24 > 1 for example 00:41 < uriel> 00:40 < electrograv> I need generics to keep maintainable, elegant code 00:41 < electrograv> that's not binary, it's a huge difference 00:41 < Namegduf> It is, if that's your entire project. 00:42 < electrograv> even if its a subset of my project 00:42 < uriel> and your argument is that writting twelve one line functions is too much work (and you need this at all because you have a rather peculiar requirement regarding how you want your code to look like) 00:42 < electrograv> its still a big difference 00:42 < Namegduf> No, not "even". 00:42 < Namegduf> It is. 00:42 < Namegduf> Is it a bigger difference than the cost of generics? 00:42 < electrograv> I didnt say writing 12 functions is too much work 00:42 < Namegduf> You need to put forward a proposal to even MAKE that comparison. 00:42 < uriel> electrograv: twelve one line functions in a tens of thousands of lines of code project is a 'big different'? is this a joke? 00:43 < uriel> and still you haven't written any real Go code 00:43 < electrograv> its error prone to duplicate code simply for the sake of duplication 00:43 < uriel> and told us where you got to a poin in a *real Go project* where you needed generics 00:43 < Namegduf> It's more error prone, yes. 00:43 < Namegduf> You've said this before. 00:43 < Namegduf> It doesn't change anything. 00:43 < Namegduf> Generics have a benefit. You're simply reiterating this. 00:44 < electrograv> I dont want to rewrite 20,000 lines of code until I'm sure I won't run into serious issues - Im sure you understand 00:44 < uriel> electrograv: again, twelve extrmely trivial one line functions is 'dangerous code duplication'? oh well, then there is no point arguing with somebody that clearly follows the mindless 'code sharing is my God' religion 00:44 < electrograv> I dont follow any principles mindlessly 00:44 < uriel> electrograv: then write some other smaller project, you don't fucking start by rewritting a huge existing project before you even know a new language 00:45 < Namegduf> electrograv: The problem is that everyone, very often on the mailing list, has a feature that has a benefit, and they feel they "need". 00:45 < uriel> electrograv: nobody suggested you rewrite your 20,000 lines of code project in Go before you have written any other Go code, that would be plain stupid thing to do 00:45 < Namegduf> If each one wasn't carefully considered for providing more benefit than cost, then you wouldn't HAVE a simple or elegant alnguage at all. 00:45 < electrograv> I've written programs in both C, which were later ported to C++ 00:45 < electrograv> these are 100,000+ line programs 00:45 < electrograv> C lacks generics 00:45 < electrograv> believe me, I KNOW how much tidier code can be with generics 00:46 < uriel> Namegduf: I don't think electrograv has even made any proposal on how to d generics in Go, so most people in the mailing list are already a step ahead of him (even if they all have failed at providing a proposal that doesn't have serious problems) 00:46 -!- tvw [~tv@e176000000.adsl.alicedsl.de] has quit [Ping timeout: 252 seconds] 00:46 < uriel> electrograv: again, Go is not C 00:46 < electrograv> yes, but couldnt you say that C has a subset of go's features? 00:46 < uriel> electrograv: last I checked, C has no interfaces, no slices, and it is a quite different language from Go 00:46 < Namegduf> Technically 00:47 < Namegduf> *Technically no. 00:47 < Namegduf> Go lacks pointer arithmetic, amongst other things. 00:47 < uriel> electrograv: yes, a subset, which makes your claims regarding C -> C++ translation irrelevant 00:47 < Namegduf> Also a preprocessor. 00:47 < Namegduf> electrograv: The question isn't, though, whether code would be tidier with generics, and whether they wouldn't provide some desirable attributes. It's whether they provide more benefit than cost to the language. This requires a specific proposal to be evaluated. 00:47 < uriel> Namegduf: good point, so C is not even a subset, but if it was a proper subset, it would not help electrograv argument one bit 00:47 < electrograv> this discussion is getting pointless... I guess from this point I should only ask "how" to do something in Go if I get stuck 00:47 < mikhailt> What is the problem to implement generics via interfaces in external package? Somebody already even did something similar 00:47 < uriel> 00:47 < electrograv> this discussion is getting pointless... I guess from this point I should only ask "how" to do something in Go if I get 00:47 < uriel> stuck 00:48 < Namegduf> That's not how generics work, mikhailt. 00:48 < uriel> electrograv: precisely what I was suggesting! 00:48 < electrograv> I know 00:48 < electrograv> it seems if I talk abstractly AT ALL I get attacked viciously for not being able to comprehend Go 00:48 < uriel> ah, yes, I forgot people has already built go preprocessors that do generics, but guess what? almost nobody uses them! 00:49 < electrograv> do these preprocessors link well into debugging / the build phase? 00:49 < Namegduf> You're not "talking abstractly". 00:49 < uriel> why? because one very rarely runs into a situation where generics would be helpful, and after append() is added in the next release (I guess next week or so), there will be even less 00:49 -!- adu [~ajr@pool-173-66-10-221.washdc.fios.verizon.net] has joined #go-nuts 00:50 < uriel> electrograv: yes, they do, still, nobody uses them, because almost nobody has need for them 00:50 < Namegduf> You're going on and on about how much something would help without sufficient detail to the idea that its costs can be analysed. 00:50 < nsf> I hate abstractions 00:50 < nsf> electrograv: so, yes :) 00:50 < Namegduf> It's not a coherent argument. 00:51 < electrograv> ok if I may ask one more abstract question: How would you implement a general-purpose nonstandard queue for containing commands sent between modules, by non-standard I mean requiring features like searching the contents or removing from the middle occasionally 00:52 < electrograv> this queue needs to be used for a variety of non-heap-stored structs containing command data 00:52 < nsf> in go you can't do that 00:52 < nsf> in a type safe manner 00:52 < Namegduf> Sounds like it doesn't require genericness 00:52 < nsf> especially if you're talking about non-heap 00:52 < nsf> non-heap is almost impossible in go :) 00:53 < Namegduf> You can't, yeah. 00:53 < electrograv> well it can be on the heap, as long as the entire queue itself (fixed length) is contiguous 00:53 < electrograv> so the answer is "Go cannot do this. Go use a capable language like C++"? or are you not seriously saying Go is incapable here? 00:53 < nsf> you still can do that in a generic way using low-level hackery with unsafe.Pointer 00:53 < Namegduf> I don't understand what you want to do. 00:53 < electrograv> ok 00:53 < nsf> but you understand that it is pointless 00:54 < electrograv> I want to use a number of custom queues 00:54 < Namegduf> Why does it need to be contiguous? 00:54 < nsf> use C++ 00:54 < electrograv> priority queues, with the added feature of being able to remove items from the middle 00:54 < Namegduf> That seems like an implementation detail. 00:54 < electrograv> it needs to be contiguous because the queus need to hold 1000 items potentially 00:54 < electrograv> well it doesnt need to be contiguous 00:54 < electrograv> just efficient 00:54 < electrograv> true 00:55 < electrograv> ok I will ignore implementation, your right 00:55 < electrograv> I need: 00:55 < uriel> electrograv: again, this is not a hard problem if you realize that you can write some code specific to the problem at hand 00:55 < mikhailt> so you want to implement heap data structure for generic type? 00:55 < nsf> electrograv: use C++, it is efficient and has templates 00:55 < uriel> rather than trying to abstract everything into 'reusable' code 00:55 < uriel> nsf: don't feed the troll ;P 00:55 < electrograv> I need: a custom queue to store many value-type structs, but I need to use this for many different structs 00:56 < uriel> electrograv: if you need a custom queue, writte a custom queue 00:56 < uriel> electrograv: I find your claim that you need this for many different structus questionable 00:56 < uriel> and you can use interface{} if you really need that 00:56 < Namegduf> I would use interface{} if I needed to store multiple different structs in the same one. 00:56 < uriel> (or whatever common interface your types have) 00:56 < electrograv> well yeah 00:56 < Namegduf> interface{} replaces void* 00:56 < electrograv> if I can use interface{} for everything there's no need for generics 00:56 -!- mode/#go-nuts [-o adg] by adg 00:56 < electrograv> because interface{} IS GENERIC 00:56 < electrograv> generics is just a static time version of interface{} 00:56 < uriel> electrograv: so, what is the fucking problem then? 00:57 < electrograv> I need static time allocation! 00:57 < nsf> uriel: I don't, he asks for efficient generic impl, Go can't do that, C++ can, but C++ compiles as slow as hell (but that's another topic of discussion) 00:57 < uriel> electrograv: allocation?!?! wtf does that have to do with the type system 00:57 < Namegduf> C++ also is not elegant, nor simple. :P 00:57 < uriel> Namegduf: but it has generics! 00:57 < Namegduf> How does one allocate time 00:57 < electrograv> I meant static organization of data 00:57 < electrograv> as opposed to allocating 1000 MyObject's 00:57 < uriel> nsf: I guess the generic pre-processors for go can do that, but I never bothered investigating them, because I never had use for them 00:58 < adg> electrograv: for efficiency reasons? 00:58 < electrograv> yes, primarily for efficiency 00:58 < electrograv> you can do anything with interface{} 00:58 < electrograv> but not necessarily efficiently 00:58 < adg> electrograv: what sort of items are you talking about? 00:58 < nsf> uriel: C++ is a better tool for this job currently 00:58 < electrograv> well, lots of things 00:58 < adg> electrograv: would you be storing pointers to values or values? 00:58 < uriel> nsf: depends on your deffinition of 'better' 00:58 < mikhailt> So create interface with can say what is size of the object, then create byte array and implement allocation youtself 00:58 < uriel> nsf: there are huge tradeoffs 00:59 < nsf> uriel: well, creating efficient and generic code in Go is more painful 00:59 < mikhailt> s/with/which 00:59 < electrograv> for example: a queue of commands 00:59 -!- mfoemmel [~mfoemmel@chml01.drwholdings.com] has quit [Ping timeout: 252 seconds] 00:59 < electrograv> and there are literally thousands of commands being generated per second 00:59 < Namegduf> If I needed efficient 00:59 < uriel> nsf: except that everything else is much more painful in C++ 00:59 < Namegduf> And really did have so many instances of the type reimplementing it was impossible 00:59 < adg> electrograv: so you would want to store a copy of the command in the queue? 01:00 < Namegduf> I'd just use compiletime generation outside of Go 01:00 < nsf> uriel: he could use Go for everything else :) 01:00 < electrograv> yes I want to store the command data itself in the queue 01:00 < adg> Namegduf: a technique like that which is used for IntVector/StringVector isn't too objectionable 01:00 < uriel> Namegduf: which is one of the things I suggested, but apparently electrograv isn't interested in any solution to his problem that doesn't fit his preconceptions of what features a language should have 01:00 < electrograv> that is the primary location for the command storage 01:00 < electrograv> ok tell me how to solve this problem 01:01 < electrograv> I have a a few modules that are concurrently processing commands sent through queues 01:01 -!- __david__ [~daviddavi@cpe-98-151-185-99.socal.res.rr.com] has quit [Quit: __david__] 01:01 < adg> electrograv: so you want to have one queue for each type of command? 01:01 < electrograv> commands need to be able to be canceled 01:01 < electrograv> and each module uses different command formats 01:01 < electrograv> (different structs) 01:01 < electrograv> thousands of commands are generated per second 01:01 < adg> i see 01:01 < electrograv> but not all are consumed immediately 01:01 < electrograv> some remain in the queue for a long time 01:01 < electrograv> because it is a priority queue 01:02 < Namegduf> I would use interface{} 01:02 < adg> electrograv: so you have a few different instances of the same queue, but each with a different fundamental data type 01:02 < Namegduf> These are structs. 01:02 < Namegduf> Why is storing a pointer to them so bad? 01:02 < electrograv> interface{}: and allocate multiple thousands of commands per second? 01:02 < Namegduf> Yes, of course. 01:02 < Namegduf> How slow do you think it is? 01:02 < Namegduf> It's basically just a pointer 01:02 < mikhailt> Allocation is slow all right 01:02 < Namegduf> A two-word struct containing a pointer, more precisely 01:02 < electrograv> a few instances of the same queue ALGORITHM but different DATA 01:02 < adg> electrograv: why don't you implement it the stupid way first, and then see how it goes? 01:02 < electrograv> complex algorithm 01:02 < nsf> GC will kill the performance at some point 01:02 < nsf> with 100-500ms pauses 01:02 < adg> electrograv: yes, i understand 01:03 < electrograv> you do NOT want to duplicate this queue algorithm 01:03 < Namegduf> There's no allocation. 01:03 < Namegduf> He has a 10000 entry array of interface{} 01:03 -!- kingfishr [~kingfishr@c-24-130-147-77.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer] 01:03 < electrograv> I have tried dynamic allocation with GC 01:03 < Namegduf> You can set items to be whatever you like when adding commands. 01:03 < Namegduf> And pull stuff out. 01:03 < electrograv> not in Go though 01:03 < Namegduf> Copying commands isn't going to be fast. 01:03 < electrograv> but in very good GC languages 01:03 < electrograv> it completely kills performance 01:03 < nsf> electrograv: Go's GC sucks 01:03 < electrograv> this is a real-time app 01:03 < nsf> electrograv: as I've said earlier, you should use C++ for that task 01:04 < electrograv> all I need is generics so I can define my Queue with multiple data types 01:04 < nsf> because it will give you all the power you want, few problems, but you know that language right? 01:04 < adg> electrograv: Go isn't well-suited to real-time applications at this time 01:04 < electrograv> if I just had that everything would be 'golden' 01:04 < electrograv> GO isnt suited to real-time? WHY is it advertised as a "SYSTEMS" language then? 01:04 < electrograv> sorry for the caps) 01:04 < adg> electrograv: you could do something like this http://golang.org/src/pkg/container/vector/Makefile 01:05 < adg> electrograv: because "systems" != "real time" 01:05 < adg> (obviously?!) 01:05 < nsf> electrograv: also it is an _experimental_ language in early stage of development :) 01:05 < mikhailt> Here is solution skeletion: queue is interface which can operate with another interface of queue element 01:05 < nsf> s/stage/stages/ 01:05 < electrograv> hence my suggestion to add generics to this _experimental_ language 01:05 < adg> nsf: i wouldn't say "experimental", it's very real-world oriented 01:05 < electrograv> mikhailt: ok... how does that eliminiate dynamic allocation 01:05 < nsf> electrograv: do you have a particular proposal for generics? 01:05 < Namegduf> electrograv: Cool, go write up a complete proposal. 01:05 < Namegduf> electrograv: And then it can be actually evaluated. 01:06 < adg> electrograv: did you take a look at my suggestion? 01:06 < electrograv> I could make a proposal... but I'm not that invested in Go at this point 01:06 < mikhailt> phisically it is based on byte array and you manage it 01:06 < Namegduf> Then your suggestion isn't. 01:06 < uriel> electrograv: you have made absolutely no real proposals regarding how to do generics in Go 01:06 < adg> electrograv: your suggestion is therefore "please do what you're already trying to do, but do it now!" 01:06 < adg> electrograv: (we are working on generics proposals) 01:06 < electrograv> no... I'm saying please tell me how I can solve my problem in Go 01:06 < adg> electrograv: http://golang.org/src/pkg/container/vector/Makefile 01:06 < electrograv> and if I can.. I will accept that Go doesnt need generics 01:07 < nsf> adg: FAQ says: "Go is an experiment. We hope adventurous users will give it a try and see if they enjoy it. Not every programmer will, but we hope enough will find satisfaction in the approach it offers to justify further development." 01:07 < electrograv> whats that vector makefile? 01:07 < nsf> so.. it is oficially an experiment :) 01:07 < nsf> officially* 01:07 < uriel> electrograv: so, i really suggest you go back to < electrograv> this discussion is getting pointless... I guess from this point I should only ask "how" to do something in Go if I get stuck 01:07 < electrograv> so you expect me to write up a formal proposal, but officially we're just supposed to "give it a try" 01:07 < electrograv> ok 01:07 < electrograv> I'm stuck 01:07 < adg> electrograv: the 4 lines following "generate" use gofmt to rewrite vector.go for int types, specifically 01:08 < electrograv> I need to implement the problem I mentioned above 01:08 < electrograv> how do I do this in Go? 01:08 < electrograv> the answer I was given was "Use C++" 01:08 < adg> electrograv: you could write up a similar makefile for your queue algorithm, that would seem to solve your problem 01:08 < uriel> electrograv: I suggest you learn Go before you make any proposals 01:08 < nsf> yep, that's still my opinion, you should use C++ :) 01:08 < mikhailt> Learn what is interface first please 01:08 < adg> nsf: that was written almost a year ago, but point taken :) 01:08 < electrograv> I read the specification all the way through 01:08 < nsf> adg: fix it then ;) 01:09 < uriel> electrograv: there have been plenty of proposals already (see the mailing list), including a few from people that have actually used Go, they all have been found to have issues 01:09 < uriel> electrograv: reading the spec is not the same as knowing a language 01:09 < adg> electrograv: can i repeat: the go team themselves are working on generics 01:09 < adg> electrograv: (it is not an easy problem) 01:09 -!- kanru2 [~kanru@61-30-10-70.static.tfn.net.tw] has joined #go-nuts 01:09 < electrograv> adg: ok the team is workingn on generics 01:09 < electrograv> all I need to know. 01:10 < mikhailt> When I first time read about interfaces I thought: damn how cool! I dont need templates and overloading anymore! 01:10 < uriel> electrograv: that you keep refering to 'classes' is not a very good indicator of your familiarity with the language, but that aside, I think it is ridiculous for somebody that has not written at least 5,000 lines of code in a language to make *any* proposals to change that language 01:10 < electrograv> at least they recognize the need for some kind of feature here exists 01:10 < nsf> mikhailt: with exception that they are slow :) 01:10 < adg> uriel: that's true. sadly the case with that recent blog post :( 01:10 < nsf> std::sort > qsort > sort.Sort 01:10 < electrograv> uriel: I've been programming for so long I very often use an "old" term from another language 01:11 < mikhailt> You mean that n^2 sort? 01:11 < uriel> electrograv: you have not been programming in Go at all, which is my point 01:11 < nsf> is it n^2? 01:11 < electrograv> > I think it is ridiculous for somebody that has not written at least 5,000 lines of code in a language to make *any* proposals to change that language 01:11 < mikhailt> Wait a sec 01:11 < electrograv> what if I'm stuck at line 100? 01:11 < uriel> electrograv: and types and structs, which go has, are older than classes, so I find that excuse lame 01:11 < uriel> electrograv: then ask for help 01:11 < nsf> sort.Sort should be a quicksort 01:11 -!- mikespook [~mikespook@219.137.48.14] has joined #go-nuts 01:12 < uriel> electrograv: plenty of people have managed to get well past 100 lines without need for help, but whenever you get stuck, by all means, ask for help 01:12 < nsf> the problem is that it uses interface{} and interface{} means virtual function calls overhead 01:12 < electrograv> uriel: I mean when I use language A for a long time, then learn and use language B, I will be using terms from language A for a while 01:12 < electrograv> just out of habit 01:12 < nsf> + Go has even more function call overhead 01:12 < nsf> because of the dynamic stack 01:12 < electrograv> I didnt mean to say I've been programming since the 70s and still call functions subroutines 01:12 < adg> electrograv: are you just ignoring my suggestion about using gofmt for templating? 01:12 < nsf> I haven't checked, by I'm sure that sort.Sort is much slower than C's qsort 01:13 -!- b00m_chef [~watr@66.183.100.197] has joined #go-nuts 01:13 < uriel> electrograv: yes, and the same that applies to terms applies to thinking about how to solve problems, if you have been using one language with certain features it becomes hard for people to see how to solve the same problems with other features 01:13 < electrograv> "<nsf> the problem is that it uses interface{} and interface{} means virtual function calls overhead" 01:13 < electrograv> *whispers about generics 01:13 < electrograv> as opposed to virtual function cals 01:13 < uriel> electrograv: which is why before complaining/making proposals, you should at least learn to *use* the language 01:13 < mikhailt> not because interface is slow 01:13 < nsf> electrograv: I want generics as you do 01:13 < bnjmn> where can i read about additional function call overhead because of dynamic stack? 01:13 * uriel is happy without generics, specially once append() is in 01:14 < nsf> electrograv: but I understand that devs don't know the right implementation for them and in that case I have nothing to offer, I'm just waiting :) 01:14 < Tv> Namegduf: thank you the multi-reader channel zero explanation.. makes sense, just need to avoid ints etc in a case like that 01:14 < uriel> but hey, if somebody comes up with a sane way to do generics I wont complain if they are added 01:14 < Namegduf> Tv: No problem. 01:14 * electrograv would be happy without generics if it didn't mean implementing a multiple-page queue algorithm for about 5 different use cases 01:14 < adg> electrograv: are you just ignoring me? 01:14 < electrograv> what? 01:14 < electrograv> I missed your message 01:14 < electrograv> sorry 01:14 < electrograv> what did you say? 01:15 < Tv> i guess i just dislike using e.g. 0 as EOF, instead of a special value 01:15 < adg> electrograv: i have described a potential solution to your problem, that does not involve re-implementing your algorithm for different classes, and you haven't responded 01:15 < nsf> adg: sorry, gofmt for generics is a bad joke :) 01:15 < Tv> but Go being a fairly low-level language, i guess that makes sense 01:15 < adg> nsf: it seems like a perfectly valid solution in this guy's situation 01:15 < adg> nsf: he has limited need for generics, a few distinct data types 01:15 -!- skelterjohn [~jasmuth@c-76-124-135-199.hsd1.nj.comcast.net] has joined #go-nuts 01:15 < nsf> especially because gofmt in the current release is broken, although it was fixed in "trunk" 01:15 < adg> nsf: it's what i would do. it's not "pretty", but it is testable, statically verifiable, and it works. now. 01:16 < adg> electrograv: write your algorithm once for one of your data types, then use gofmt to rewrite it for each of your other supported data types. it will work, and should perform well. 01:17 < adg> nsf: well bugs happen, it can't be avoided. 01:17 < adg> nsf: that's not an excuse to discount the approach, though 01:17 < uriel> adg: there are also the other generics preprocessors for Go, in the end, there are plenty of solutions to electrograv's problem, but still before getting to that I think he should learn to use the language first 01:17 < nsf> http://github.com/droundy/gotgo 01:17 < adg> uriel: i think his is one of the few valid use-cases for generics 01:17 < nsf> generics system in a form of preprocessor 01:18 < adg> yep, gotgo is also useful 01:18 < uriel> adg: maybe, but from previous discussion, his requirements seemed based on hypothetical code, not on any actual Go roject he is working on 01:18 < adg> uriel: that may be the case, but i'd rather offer some useful solution to his hypothetical situation than telling him to write something else first 01:19 < uriel> adg: coming up with some contribed example of a situation where generics would be useful is not hard 01:19 < electrograv> well its not from an actual Go project but from an actual project that I'm willing to port to Go if it works 01:19 < electrograv> listen - I'm REALLY "adventurous" if I offer to port ~20k lines of code from C++ to Go 01:19 < uriel> electrograv: again, porting an existing project to Go before learning the language is IMHO a bad idea 01:19 < electrograv> but dont give me a hard time when I dont go and actuall write 10,000 before researching 01:19 < electrograv> to see if I wont waste my time in porting those 10,000 01:20 < adg> electrograv: porting a 10k line project is a bad "first project" idea 01:20 < uriel> I think porting existing code is usually a bad way to learn a new language 01:20 < adg> electrograv: why don't you start exploring Go by using it for smaller tasks first? 01:20 * uriel agrees with adg 01:20 < electrograv> its a hobby... I dont care if porting is a time delay as long as its not a complete waste in the end 01:20 < electrograv> Im not porting to learn 01:20 < electrograv> learning a new language is easy 01:20 < adg> electrograv: it's not that it's a time delay, it just won't be good 01:21 < uriel> electrograv: even if it is not porting to learn, porting before learning is a *BAD* idea 01:21 < adg> electrograv: Go won't be quite what you expect. it encourages a very different style of code 01:21 < electrograv> theres a difference between learning a language and learning the methodologies associated with a language 01:21 < adg> electrograv: the latter is just an aspect of the former 01:21 < electrograv> Im attracted to Go because its code style it encourages is very very similar to my own in C++ 01:21 < adg> electrograv: if you spend a lot of time porting 10k lines of some language to Go, you will have a hard time and come out of it hating Go. it will be a waste of your time. 01:21 < mikhailt> electrograv, did you read Effective Go? Try it 01:22 < electrograv> or at least what I try to emulate 01:22 < uriel> it is very hard to learn 'methodologies' associated with a language without using the language, specially with a language as pragmatic and practical yet different as Go is 01:22 < electrograv> adg: porting will make me hate Go? 01:22 < electrograv> I guess I mean "rewrite" 01:22 < electrograv> as in completely refactor if necessary to accomodate the language 01:22 < uriel> electrograv: whatever, you are playing with terminology 01:22 < adg> electrograv: it will be necessary to refactor 01:22 < electrograv> yes 01:22 < electrograv> I am ok with that 01:23 < nsf> porting is not a correct term in that case 01:23 < electrograv> I'm not gonna do a straight port - that will make you hate any language 01:23 < electrograv> yes 01:23 < nsf> use "reimplementing" :) 01:23 < uriel> anyway, you have been given advice to learn by working on *new* projects, if you don't want to follow our advice fine, but don't be surprised if you are disapointed with the results 01:23 < adg> electrograv: i'm speaking from experience. i have watched talented programmers "port" things from other languages and get very frustrated because they're pushing against the grain 01:23 < electrograv> thats why I "played with termonology" to correct my incorrect use of port 01:23 < electrograv> ok "reimplement" 01:23 < electrograv> like I said, my grain is already very similar to Go 01:23 < uriel> still, "reimplementing" a project you have already implemented in another language usually means you carry a huge baggage of prejudices and preconcived ways of doing things along with you, even if unconciously 01:24 < crazy2be> hmm 2010-10-24T2044:42.156Z seems to have seconds and nanoseconds in the timestamp, but i can't figure out how to create an equivelent timestamp using the time pacakge 01:24 < adg> electrograv: well, give it a try, then 01:24 < uriel> that is why it is best to do something new which you have not done in other languages 01:24 < Tv> well it seems i really didn't miss anything while afk 01:24 < crazy2be> since none of the example time formats have seconds, let alone nanoseconds 01:24 < mikhailt> :D 01:24 < electrograv> uriel: but my task/problem is language independent 01:24 < electrograv> I just need to have a program that accomplishes this task 01:25 < uriel> electrograv: how is that relevant to what I said? 01:25 < mikhailt> You know, there are intranslatable idioms in different human languages too. 01:25 < Tv> crazy2be: it seems the time package as is can't parse sub-second times 01:25 < uriel> electrograv: if you have solved a certain problem using certain tools, you will consciously or unconsciously have a set of expectations regarding how other tools should be used to solve the same problem 01:26 < Tv> crazy2be: specific forms of iso8601 really aren't hard to parse, write your own little function 01:26 < uriel> but I'm starting to repeat myself way too much, do whatever the hell you like, feel free to ignore our advice, but do it at your own peril 01:26 < crazy2be> Tv: I may just write my own time package 01:26 < electrograv> uriel: your basically telling me I need a programming paradigm shift 01:26 < uriel> yes 01:26 < crazy2be> since the builtin one doesn't have much to offer 01:26 < electrograv> like I said, Go is very similar to the methodology I already use or try to emulate in C++ 01:26 < uriel> electrograv: you are wrong 01:27 < crazy2be> since it can't parse my time strings 01:27 < uriel> electrograv: but it is pointless to argue over this with somebody that doesn't even know how to use Go 01:27 < electrograv> uriel: do you have some psychic knowledge of my methodology, or are you just telling me that because you like to say I'm wrong. 01:27 < uriel> so do whatever the heck you want 01:27 < mikhailt> looks like you evaluate language by style guide and syntax 01:27 < electrograv> ok... 01:27 < uriel> electrograv: I'm saying it because Go is not C++, and your claim that you were writting C++ using the same methodologies available in Go is patently ridiculous 01:28 < adg> electrograv: i'm not trying to be argumentative, but i can't see how you could know much about Go idiom without having written anything in Go. 01:28 < uriel> and should be obvious to anyone that has actually used both languages 01:28 < adg> electrograv: but then, i haven't seen your c++ code, so maybe you're making a particularly astute observation 01:28 < electrograv> uriel: not the same.. but very close as far as C++ allows 01:28 < electrograv> I like flat class hierarchies 01:28 < adg> electrograv: i encourage you to try, and if you have specific programming questions to ask them here 01:28 < electrograv> I only use interfaces 01:29 < uriel> electrograv: "very close as far as C++ allows" is not much 01:29 < electrograv> etc 01:29 < uriel> electrograv: and how you know that it is "very close" given that you are clearly very unfamiliar with how Go is used, is very questionable 01:29 < uriel> electrograv: Go interfaces and C++ interfaces are not the same at all 01:29 < electrograv> I know 01:30 < uriel> (hell, I wonder if Go's interfaces shouldn't have been called something else to avoid this confusion, the naming for 'goroutines' was a good idea to avoid this kind of nonsense) 01:30 < uriel> electrograv: you know, yet you make silly claims about Go based on your use of C++, this is plain sily 01:30 -!- mfoemmel [~mfoemmel@chml01.drwholdings.com] has joined #go-nuts 01:30 < electrograv> Go interfaces seem closer to Objective-C than C++ obviously... 01:31 < uriel> obvioulsy not 01:31 < nsf> go interfaces should be named concepts :) 01:31 < nsf> C++ won't have them anyway 01:31 < uriel> and in the time wasted in this pointless discussion you could have already written a multi-hundred-lines go project and actually learned a bit about how to use Go 01:31 < electrograv> ok.. tell me where to read about GO methodology 01:31 < uriel> nsf: haha 01:31 < electrograv> and I will say no more until I have read it all 01:31 < mikhailt> Effective Go 01:31 < uriel> nsf: that would have been evil ;) 01:31 < mikhailt> on golang.org 01:31 < electrograv> I read most of that already 01:32 < electrograv> ok I will finish reading that 01:32 < nsf> uriel: but that's what they do, at runtime though 01:32 < uriel> electrograv: what about saying nothing until you start to write Go code and need some help with an actual Go problem 01:32 < nsf> e.g. io.Reader is a concept 01:33 < uriel> I don't claim to understand C++ (and I doubt anybody does), much less C++0x, so I wont comment on 'concepts' ;) 01:34 < electrograv> a language is just a set of tools to solve problems: based on those tools you will solve problems differently (if given a helicopter or a grappling hook you may choose to climb a mountain differently) 01:34 < electrograv> but I dont think I have to use a helicopter to know how I would use it 01:34 < electrograv> I can read the helicopter specification to realize its better than a grappling hook in most cases 01:34 < uriel> electrograv: programming languages are more like human languages 01:34 < electrograv> but I will code in GO when I get the chance 01:34 < electrograv> I just am at a windows PC at the moment 01:34 < uriel> electrograv: to know how to say something in some language, you really have to understand that language 01:34 < uriel> electrograv: go works on windows just fine 01:35 < crazy2be> eww... windows :P 01:35 < mikhailt> It is that case when metaphores dont fit 01:35 < nsf> crazy2be: :P 01:35 < uriel> (well, mostly fine, the port of the standard libs is not yet complete) 01:35 < uriel> mikhailt: that too 01:35 < electrograv> I learned Objective-C from C++ in one day... while it took more practice to speak it fluently, I understood the methodologies 100% after that one day 01:36 < electrograv> objective-C is similar to C++, more so than Go, but by no means identical in practice 01:36 < crazy2be> electrograv: go is very much different from C++, it took me weeks to properly learn the entirety of it 01:36 < crazy2be> and i still do not completely understand several design aspects 01:37 < Tv> more code less methodologies, please 01:37 < mikhailt> Please dont think so general. It all sound like demagogu 01:37 < uriel> electrograv: I find your claim of learning to *properly use* Objective-C in one day questionable 01:37 < mikhailt> *demagogy 01:37 < electrograv> uriel: its true 01:37 < uriel> electrograv: still, Go is *much* different 01:37 < electrograv> but by all means, call me a liar 01:37 < crazy2be> Some languages, like python, you can pick up in a day if you are clever 01:37 < uriel> electrograv: self-reports regarding language learning/understanding are all suspect 01:37 < uriel> crazy2be: good luck picking up metaclasses in half a day 01:37 < crazy2be> others, like C++, take a lifetime to pick up 01:38 < crazy2be> uriel: Picking up the basics, rather 01:38 < crazy2be> enough to accomplish something 01:38 < uriel> but yea, I agree some languages are easier to pick up than others, and Go is actually easier than most, but it is also very easy to be misleed by expectations one brings from other languages 01:38 -!- tsykoduk [~tsykoduk@184.78.195.79] has quit [Quit: This is Free Trader Beowulf, calling anyone... Mayday, Mayday...] 01:39 < electrograv> anyway 01:39 < uriel> the key is: to pick up a language, hard or difficult, you probably have to *use* it 01:39 < electrograv> I'm gonna get back to reading Effective Go 01:39 < crazy2be> uriel: I would say it is easier than *some*, but not if one comes from a C/C++ background... the reversed type/name defintions take at least a week to get used to 01:40 < crazy2be> although that is being mislead i suppose by expectations from other languages 01:40 < uriel> crazy2be: yup, I completely agree 01:40 < crazy2be> anyway, pointless debate 01:40 < crazy2be> i'm going to write some code now :P 01:40 < electrograv> yeah 01:40 < electrograv> you all are probably right that I am missing something in the Go methodology 01:40 < uriel> (not about the reverse type/name deffinitions, but about the general concepts and style) 01:40 < electrograv> so I will stop being annoying and read as much as I can 01:40 < uriel> (eg., using slices vs. Vectors) 01:41 < mikhailt> Also blog of Russ Cox is very interesting 01:41 < uriel> adg: any chances Vector will be removed/obscured once append() is in? ;) 01:42 < uriel> new users seem to have a tendency towards (ab)using Vector when slices would work much better 01:44 -!- zhaozhou [~zhaozhou@linfast76.bitnet.nu] has quit [Read error: Connection reset by peer] 01:45 -!- kingfishr [~kingfishr@c-24-130-147-77.hsd1.ca.comcast.net] has joined #go-nuts 01:45 < electrograv> is there anything else I shoudl read 01:45 < electrograv> so I dont have questions about something youve heard 100 times 01:46 < mikhailt> FAQ probably 01:46 < uriel> faq, of course, but again, answering questions that we have heard is not such a big deal as long as they relate to actual practical problems found while writting Go code 01:47 < mikhailt> ok I have practical question 01:48 < mikhailt> There is no mechanism to create Go string on top of char* from c library using cgo 01:48 < mikhailt> so we have to copy memory every time we want to call some c method which returns freshly allocated memory 01:49 < mikhailt> I mean pointer to freshly allocated memory 01:50 < mikhailt> Looks like problem for me. It is impossible to implement go-gtk bindings without memcpy overhead 01:56 < uriel> mikhailt: is the memcpy overhead really a problem? 01:57 < uriel> specially for the kind of extremely trivially short strings you have in GUIs and so on 01:57 * uriel doubts this overhead is even measurable in practice 01:58 < uriel> for big chunks of memory, you can always use arrays of bytes, no? 01:59 < mikhailt> Is it possible to convert C char* to Go byte array? 02:00 < crazy2be> Wierd. I get go complainging about an unused import 02:00 < crazy2be> then it complains that the import is undefined 02:01 < mikhailt> uriel: Ok, It makes sense. 02:01 < crazy2be> logger.go:5: imported and not used: time 02:01 < crazy2be> logger.go:14: undefined: time 02:01 < crazy2be> logger.go:23: undefined: time 02:01 < crazy2be> logger.go:27: undefined: time 02:01 < mikhailt> try time.Time 02:02 < mikhailt> u inport time module but calling Time method wrong 02:02 < crazy2be> actually 02:03 < crazy2be> it seems that it was confused by time.go being in the cwd 02:03 < crazy2be> even though it was part of package parsetime 02:03 < crazy2be> not package time 02:03 < mikhailt> All the methods start from capitals 02:03 < mikhailt> time.Go 02:09 < adg> uriel: not sure 02:12 < uriel> mikhailt: all *public* methods ;) 02:12 < uriel> (I'm sure you know, but wanted to clarify) 02:18 < plexdev> http://is.gd/ggRyR by [Fazlul Shahriar] in go/src/cmd/goinstall/ -- goinstall: don't wrongly error out with "multiple package names" 02:21 -!- adu [~ajr@pool-173-66-10-221.washdc.fios.verizon.net] has quit [Quit: adu] 02:33 -!- skelterjohn [~jasmuth@c-76-124-135-199.hsd1.nj.comcast.net] has quit [Quit: skelterjohn] 02:34 -!- bnjmn [~bnjmn@siegel.dreamhost.com] has left #go-nuts [] 02:46 -!- b00m_chef [~watr@66.183.100.197] has quit [Ping timeout: 272 seconds] 02:59 -!- diordna [~diordna@cpe-173-88-147-26.neo.res.rr.com] has joined #go-nuts 03:06 -!- iant [~iant@66.135.114.72] has joined #go-nuts 03:06 -!- mode/#go-nuts [+v iant] by ChanServ 03:11 < diordna> Good evening go-nuts. I'm just starting out after a go-break of 6 months or so, but I can't seem to compile anything that imports fmt. 03:11 < diordna> Error on whatever line "import fmt" is on: "syntax error: unexpected :, expecting }" 03:13 < nsf> you have a version mismatch 03:13 < nsf> compiler is new and libraries are compiled using old compiler 03:13 < diordna> How would that happen? I update according to the tutorial instructions 03:13 < nsf> or variations of that 03:13 <+iant> the binaries are now installed in $GOROOT/bin 03:13 <+iant> you may have to remove your old binaries manually 03:13 <+iant> and then add $GOROOT/bin to PATH 03:13 < diordna> ah, I see 03:13 < diordna> thanks 03:17 < TheSeeker> Are there instructions anywhere on how to properly build Go on Windows? Is linux + cross-compilation required to get windows binaries from source? 03:21 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] 03:25 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3] 03:25 * TheSeeker learns that his msysgit bin dir contains bash.exe -- ooh. 03:32 < crazy2be> TheSeeker: Use linux? :P 03:32 < crazy2be> last i checked, the go builds for windows were still somewhat experimental 03:34 < TheSeeker> they're getting better... eg: goplay works. 03:35 < TheSeeker> I'm not much of a programmer, but I'd like to start playing with go. I might even be able to help debug some stuff if I could figure out how to compile the @#$% thing :P 03:36 < TheSeeker> hmm. I do have an ancient laptop I was given, perhaps I should nuke the OS on that and make it a linux box. 03:37 < TheSeeker> ok, next question: which linux distrobution is best? ;) 03:37 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 276 seconds] 03:37 < crazy2be> haha 03:38 < crazy2be> you should know there is really no good anwser to that 03:38 < crazy2be> i use ubuntu 03:38 < crazy2be> xubuntu is nice for slower boxes 03:38 < crazy2be> kubuntu for faster boxes 03:38 < crazy2be> i'm a 3 year old system with 1GB of ram and integrated graphics 03:38 < crazy2be> so ubuntu works well 03:39 < crazy2be> kubuntu works great on my fast desktop with 3GB of ram 03:39 < crazy2be> and, of course, there are tons of other distros 03:39 < crazy2be> but the debian based ones generally have good support by compinies like google 03:39 < crazy2be> mint is apparently quite good 03:40 < crazy2be> i would try ubuntu first if you are not used to linux 03:40 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has joined #go-nuts 03:40 < TheSeeker> well, all I'd be using linux for is compiling go ... :P 03:40 < crazy2be> haha 03:41 < crazy2be> ubuntu has fantastic notifications 03:41 < crazy2be> kubuntu has all kinds of wonderous features 03:41 < crazy2be> like tabbed windows 03:41 < crazy2be> and easy configuration 03:41 < crazy2be> and cool desktop effects 03:43 < crazy2be> either way, it generally "just works" from install 03:43 < crazy2be> although it's easy to break if you are a geek :P 03:44 < crazy2be> i reinstall mine every 6 months or so because i break stuff 03:45 < crazy2be> what are the machine's specs? 03:47 -!- __david__ [~daviddavi@cpe-98-154-222-65.socal.res.rr.com] has joined #go-nuts 03:47 * crazy2be pokes TheSeeker 03:47 -!- dj2 [~dj2@CPE001f5b35feb4-CM0014048e0344.cpe.net.cable.rogers.com] has quit [Remote host closed the connection] 03:48 < electrograv> hmm.. go is supposed to be a sort of minimalist language, right? 03:49 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has quit [Quit: Leaving] 03:49 < electrograv> I'm wondering why they decided the "select" behavior belongs in the core language 03:50 <+iant> I would say that Go is relatively small, but it's not minimalist 03:50 < plexdev> http://is.gd/ggXMt by [Andrew Gerrand] in go/src/pkg/container/list/ -- container/list: fix Remove bug and use pointer to self as identifier 03:50 < plexdev> http://is.gd/ggXMw by [Andrew Gerrand] in go/src/pkg/container/list/ -- container/list: elide redundant tests and fix comment typo 03:50 <+iant> given that goroutines and channels are in the language, select really has to be in the language 03:51 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has joined #go-nuts 03:52 < electrograv> maybe Im misunderstanding its purpose then 03:52 < TheSeeker> crazy2be: sorry, went and started installing updated mingw64 stuff ... I'll go get the laptop *afk* 03:53 < electrograv> doesn't it just randomly pick a channel to read from, then read from it? 03:53 <+iant> select waits for one of a set of channel operation to be ready, and then runs it 03:53 <+iant> it randomly picks a channel which has data available 03:54 <+iant> it doesn't pick a channel which does not have any data waiting to be read 03:54 < electrograv> is there no way otherwise to determine if a channel has data to read? 03:54 <+iant> you can do a nonblocking read 03:55 < electrograv> oh so you otherwise can't tell if there's something to read from a channel without actually trying to read it? 03:55 < crazy2be> electrograv: I would suggest reading the language specification as well 03:55 < electrograv> I did read the specification 03:55 < crazy2be> electrograv: sortof 03:56 <+iant> you can use the len function, but you risk race conditions 03:56 < crazy2be> _, ok := chan or something like that 03:56 <+iant> no, that reads the data and discards it 03:56 < crazy2be> oh, right 03:56 <+iant> to avoid race conditions, you must read the data if it is available 03:56 < crazy2be> why is that? 03:57 < electrograv> because if you get the length that length might be less by the time you read from it 03:57 < crazy2be> well i guess it makes sence 03:57 <+iant> you check for data; another goroutine checks for data; you read the data; the other goroutine blocks 03:59 < electrograv> I guess you could do: "for all channels if length > 0 add to a list; pick a random item from this list and read from it nonblocking, if read failed remove from list andtry again" 03:59 < electrograv> I'm just trying to think of select() is redundant... but I guess not 03:59 < electrograv> if* 03:59 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has quit [Quit: This computer has gone to sleep] 03:59 < crazy2be> there really is no other way to read from multiple channels 03:59 < crazy2be> at the same time 04:00 < electrograv> yeah 04:01 < TheSeeker> crazy2be: hmm, not as much of a POS as I thought. Toshiba Satellite P15-S420 -- P4 3.0 ghz, 2 GB RAM, GeForce FX Go5100 - 1280x800 native res. 04:01 < electrograv> haha 04:01 < TheSeeker> DVD R/RW 04:01 < crazy2be> TheSeeker: That's actually quite nice 04:01 < electrograv> similar to my old P4 laptop except mine had 512mb ram 04:01 < crazy2be> nicer than my laptop 04:01 < crazy2be> kubuntu or ubuntu then 04:01 < crazy2be> choose one at random 04:01 < crazy2be> lol 04:01 < TheSeeker> XD 04:02 < crazy2be> i would go with kubuntu on that, personally 04:02 < TheSeeker> 75G HDD 04:02 < crazy2be> but i don't know how well it works out of the box 04:02 < crazy2be> never installed it 04:02 < crazy2be> just used kde on ubuntu 04:03 < crazy2be> that's smaller than mine! 04:03 * TheSeeker looks for a liveCD 04:03 < crazy2be> but everything else is better 04:04 < crazy2be> It's also a matter of whether you preffer windows or mac 04:04 < crazy2be> ubuntu is more like mac, kubuntu is more like windows 04:04 < electrograv> select { case: os <-ubuntu; case os <-kubuntu; } 04:04 < electrograv> oops syntax error... nevermind 04:06 < crazy2be> although the first think i usually do on a new ubuntu install is ditch firefox 04:06 < crazy2be> i've always found it sluggish 04:06 < crazy2be> go with midori or chrome 04:06 < crazy2be> easily installable with the software-center on ubuntu 04:06 < crazy2be> not sure what the kubuntu equivilent is 04:07 < crazy2be> anyway 04:07 < crazy2be> have fun with that :P 04:07 < crazy2be> i'm going to sleep 04:08 < TheSeeker> o.O Wubi - Install from Windows 04:08 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has joined #go-nuts 04:09 < crazy2be> yeah, no idea how that works 04:09 < crazy2be> i think it runs in a VM 04:09 < crazy2be> oh, nvm 04:13 -!- crazy2be [~crazy2be@S0106001ac401d400.cg.shawcable.net] has quit [Remote host closed the connection] 04:35 -!- diordna [~diordna@cpe-173-88-147-26.neo.res.rr.com] has quit [Quit: diordna] 04:36 -!- jcao219 [~jcao219@pool-96-226-238-248.dllstx.fios.verizon.net] has quit [Ping timeout: 252 seconds] 04:37 -!- jcao219 [~jcao219@pool-96-226-238-248.dllstx.fios.verizon.net] has joined #go-nuts 04:50 -!- dju_ [dju@fsf/member/dju] has joined #go-nuts 04:53 -!- jcao219 [~jcao219@pool-96-226-238-248.dllstx.fios.verizon.net] has quit [Ping timeout: 252 seconds] 04:53 -!- dju [dju@fsf/member/dju] has quit [Ping timeout: 240 seconds] 04:53 -!- major_majors [~major_maj@108-65-203-205.lightspeed.livnmi.sbcglobal.net] has joined #go-nuts 04:54 -!- __david__ [~daviddavi@cpe-98-154-222-65.socal.res.rr.com] has quit [Quit: __david__] 04:56 -!- cco3 [~conley@c-69-181-138-209.hsd1.ca.comcast.net] has quit [Quit: Leaving.] 05:07 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has quit [Quit: Morten. Desu~] 05:09 -!- fabled [~fabled@83.145.235.194] has joined #go-nuts 05:19 -!- devrim [~Adium@ip-95-223-189-66.unitymediagroup.de] has quit [Quit: Leaving.] 05:22 -!- __david__ [~daviddavi@cpe-98-151-185-99.socal.res.rr.com] has joined #go-nuts 05:25 -!- kingfishr [~kingfishr@c-24-130-147-77.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 05:25 -!- kingfishr [~kingfishr@c-24-130-147-77.hsd1.ca.comcast.net] has joined #go-nuts 05:27 -!- major_majors [~major_maj@108-65-203-205.lightspeed.livnmi.sbcglobal.net] has quit [Quit: major_majors] 05:27 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 05:38 -!- prip [~foo@host97-123-dynamic.53-79-r.retail.telecomitalia.it] has quit [Ping timeout: 240 seconds] 05:38 < plexdev> http://is.gd/gh5ha by [Andrew Gerrand] in go/src/ -- build: only print "You need to add foo to PATH" when needed 05:41 < nsf> goinstall should try to detect cgo packages and tell user that it can't deal with them 05:41 < nsf> there are so many people complaining that they can't install library using goinstall 05:48 < adg> agreed 05:48 < adg> but the questions is how to reliably do so 05:49 < adg> i think rsc has some ideas; i sent in a CL last week but he told me to hold off until he's finished some other bits 05:49 < nsf> detect: import "C" 05:49 < adg> but then which files? 05:49 < adg> read the C include statements? 05:49 < nsf> but I believe goinstall assumes something about directory/package structure anyway 05:50 < nsf> if one of the files contains import "C" then it's a cgo package 05:50 < nsf> most likely 05:50 < adg> yes, that makes sense. i agree 05:50 < adg> but then how you find and build the C files appropriately? 05:51 -!- prip [~foo@host5-194-dynamic.17-79-r.retail.telecomitalia.it] has joined #go-nuts 05:51 < cbeck> Right, but then you could at least give a sensible error message 05:51 < cbeck> for the time being 05:51 < nsf> adg: I'm not saying that you should build them 05:51 < nsf> but yeah 05:51 < adg> oh 05:51 < exch> qBinding often need to be linked against an external lib, and gcc possibly needs some cflags to 05:51 < nsf> give a nice error message to user 05:52 < nsf> like: "this is most likely is a cgo package, goinstall doesn't support cgo packages, build it with make manually" 05:52 < nsf> s/is// 05:52 * cbeck is wrestling with cgo and libavformat as we speak 05:53 -!- mfoemmel [~mfoemmel@chml01.drwholdings.com] has quit [Ping timeout: 265 seconds] 05:53 < exch> I'm sure this has been giving some thought, but personally I still don't get why goinstall doesn't just use any existing makefiles in the project 05:53 < nsf> because people actually write mails to cgo package creators asking why they can't build the package with goinstall 05:53 < nsf> exch: it is unsafe :) 05:54 < nsf> makefile can execute rm -rf / 05:54 < exch> more unsafe than installing 'random' third party sourcecode, compiling it and then running the result? 05:54 < nsf> well, I guess you're right 05:54 < exch> The actual source could also execute that 05:54 < nsf> personally I don't mind doing that (running makefiles via goinstall) 05:54 < nsf> but people will complain 05:56 < nsf> also I think goinstall should track installed packages 05:56 < nsf> and be able to upgrade them as well :) 05:57 < nsf> and here we go, now it's a complex package manager 05:57 < adg> nsf, cbeck: done http://codereview.appspot.com/2701042 05:57 < nsf> adg: nice :) 05:58 < nsf> I think it will be helpful for a lot of Go newbies 05:58 < adg> exch: the main issue is making sure that a goinstalled package installs itself as its correct target 05:59 < adg> ie, goinstall github.com/nf/foo needs to install to $GOROOT/pkg/$GOOS_$GOARCH/github.com/nf/foo.a 05:59 < adg> that way recursive goinstalls will work 05:59 < adg> last week i sent out a CL to inspect the Makefile for the correct TARG string and use it if found 05:59 < exch> That would be my solution as well 05:59 < adg> but I think rsc has a better idea, we'll see 06:00 < exch> Just overwrite TARG if needed 06:00 < adg> i think Russ' concern was locking ourselves in to a particular Makefile format 06:01 < nsf> maybe adding variable to Make.* templates something like GOINSTALL_TARG, which if set will override TARG? Other tools will have to use it as well 06:02 -!- mfoemmel [~mfoemmel@chml01.drwholdings.com] has joined #go-nuts 06:02 < adg> it's an idea 06:02 < nsf> goinstall then will have to simply run GOINSTALL_TARG=<whatever> make 06:05 < nsf> btw, using it that way it will be simpler for people to build custom makefiles 06:05 < nsf> without using Make.* templates 06:05 < adg> again, this assumes a well-behaved Makefile provided by the user 06:05 < nsf> all they have to do is just provide support for GOINSTALL_TARG 06:05 < adg> s/user/package author/ 06:05 < nsf> that's always an issues 06:05 < nsf> an issue* 06:06 < nsf> but hey, goinstall is a part of Go 06:06 < nsf> package developers would love to support it 06:06 < nsf> it it will be easy enough 06:07 < exch> I don't think any of my packages work with goinstall atm. I don't plan to make them compatible either until this makefile stuff is fixed 06:07 < nsf> for example I have 3 packages, 2 of them are cgo packages, 1 uses very complex building scheme (build app, which generates .go, which is required to build the main app) 06:07 < nsf> so, I just can't use goinstall 06:07 < adg> exch: which are yours? 06:08 < exch> http://github.com/jteeuwen these 06:09 < exch> the xmlx, rss and lastfm are the ones I see in godashboard most often. Presumably from people trying to goinstall them 06:09 < nsf> also I think using a repository as a part of a name of the package is a bad idea 06:10 < adg> exch: this works fine: goinstall github.com/jteeuwen/go-pkg-ini/ini 06:10 < nsf> of course it provides a way to install all the packages using no 3rd party database 06:10 -!- photron [~photron@port-92-201-7-153.dynamic.qsc.de] has joined #go-nuts 06:10 < nsf> but something like ruby's gem imho is a better idea 06:11 < nsf> http://rubygems.org 06:11 < nsf> isn't it nice? 06:11 < nsf> :) 06:11 < exch> For something as simple as the ini pkg it will work, since the ini dir is the only one containing actual package source. I have some others with multiple package dirs which need to be built in the proper order and depend on eachother. Goinstall would fail in those cases 06:11 < adg> it's certainly complex... http://docs.rubygems.org/read/chapter/20 06:12 < adg> exch: xmlx works fine too 06:12 < exch> yea, same deal as with ini. Same for lastfm and rss 06:12 < exch> suppose that's an acidental bonus :p 06:12 < exch> oh wel 06:12 < nsf> adg: it can't be simple 06:12 < adg> it's not accidental, it's goinstall working as intended :) 06:12 < nsf> at least I think so 06:13 < adg> nsf: i was skeptical about goinstall at first, but i think it has merit 06:13 < nsf> at the moment I simply don't use it :) because it has no use for me 06:13 < adg> when it doesn't work, the only thing i need to look at to fix it is the actual source 06:13 < nsf> mostly because of a lack of the support for the cgo packages 06:13 < adg> when i've tried to install ruby gems or python eggs and things go b0rk i find myself having to first debug the .gem/egg 06:14 < nsf> I think it's because of the complexity, Go packages will have issues too with time 06:14 < nsf> more people more troubles :) 06:15 < adg> maybe 06:16 < adg> i'd prefer to wait for the complexity to arrive and then deal with it appropriately, rather than pre-empt it 06:16 < nsf> continuing to look for a KISS packages solution is a good idea 06:19 < nsf> although I don't know a solution better than PKGBUILD/ebuild/gems/eggs like (e.g. based on per package descriptions with a predefined format) 06:19 < nsf> but there is another idea 06:19 < nsf> because it is easy to cross-compile libraries using Go tools 06:19 < nsf> maybe we should try to redistribute them in a binary form? 06:20 < nsf> well, source code can be included but no one forces people to use it 06:20 < nsf> I don't know.. 06:21 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Ping timeout: 245 seconds] 06:22 < nsf> building a lib for all major platforms and packing it inside a single file 06:22 < adg> a fat binary 06:22 < adg> or some such 06:22 -!- binarypie [~binarypie@c-24-130-113-34.hsd1.ca.comcast.net] has joined #go-nuts 06:22 < nsf> it is 06:30 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 06:38 < cbeck> adg: Awesome, thanks =D 06:42 -!- binarypie [~binarypie@c-24-130-113-34.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 06:44 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts 06:52 -!- ayo [~nya@fuld-4d00d143.pool.mediaWays.net] has quit [Quit: EXEC_over.METHOD_SUBLIMATION] 06:55 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 06:58 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has joined #go-nuts 06:58 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Quit: Leaving] 06:59 -!- ucasano [~ucasano@host153-182-static.227-95-b.business.telecomitalia.it] has joined #go-nuts 07:09 -!- c9s [~c9s@59-126-64-204.HINET-IP.hinet.net] has joined #go-nuts 07:09 < c9s> hi! 07:09 -!- ronnyy [~quassel@2001:6f8:12c6:1c86:224:1dff:fed7:9541] has joined #go-nuts 07:11 -!- photron [~photron@port-92-201-7-153.dynamic.qsc.de] has quit [Ping timeout: 255 seconds] 07:14 < nsf> margin: -1px; 07:14 < nsf> lol 07:14 < nsf> didn't know that it works in css 07:18 -!- Fish [~Fish@86.65.182.207] has joined #go-nuts 07:27 -!- rlab [~Miranda@91.200.158.34] has quit [Read error: Connection reset by peer] 07:27 -!- Fish [~Fish@86.65.182.207] has quit [Read error: Operation timed out] 07:32 -!- fhs [~fhs@pool-74-101-63-115.nycmny.east.verizon.net] has quit [Quit: leaving] 07:33 < Gertm> wow I really need to change my font when I read 'css' as 'ass' :/ 07:37 < nsf> :D 07:40 -!- electrograv [81d28070@gateway/web/freenode/ip.129.210.128.112] has quit [Quit: Page closed] 07:42 < Gertm> I've been looking for a good programming font for a long time. Any suggestions? 07:43 < napsy> Fixed 07:43 < Gertm> On what platform is that? :) 07:44 < nsf> terminus, proggy 07:44 < taruti> terminus 07:44 < nsf> I use terminus 07:44 < Gertm> so did I, switched to proggy now, but css/ass :/ It's probably too small for me heh 07:46 -!- Fish [~Fish@86.65.182.207] has joined #go-nuts 07:46 -!- Fish [~Fish@86.65.182.207] has quit [Remote host closed the connection] 07:47 -!- Fish [~Fish@86.65.182.207] has joined #go-nuts 07:53 -!- wjlroe [~will@212.169.34.114] has joined #go-nuts 07:55 -!- mfoemmel [~mfoemmel@chml01.drwholdings.com] has quit [Ping timeout: 240 seconds] 07:59 -!- Fish [~Fish@86.65.182.207] has quit [Ping timeout: 272 seconds] 08:01 -!- iant [~iant@66.135.114.72] has quit [Ping timeout: 240 seconds] 08:04 -!- sahid [~sahid@LNeuilly-152-21-22-10.w193-253.abo.wanadoo.fr] has joined #go-nuts 08:08 < cenuij> I find my choice of font tends to vary depending on the display I have available, and how X is setup, and also whether sub pizel hinting is enabled. But currently I think i'm using consolas/inconsolata/pragmata 08:08 -!- jyoshm [~jmissao@unaffiliated/sundial] has joined #go-nuts 08:11 -!- bortzmeyer1 [~bortzmeye@batilda.nic.fr] has joined #go-nuts 08:11 -!- bortzmeyer1 [~bortzmeye@batilda.nic.fr] has quit [Client Quit] 08:12 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Read error: Connection reset by peer] 08:12 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-152-44.clienti.tiscali.it] has joined #go-nuts 08:17 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has quit [Read error: Connection reset by peer] 08:17 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has joined #go-nuts 08:20 -!- Fish [~Fish@86.65.182.207] has joined #go-nuts 08:21 -!- ronnyy [~quassel@2001:6f8:12c6:1c86:224:1dff:fed7:9541] has quit [Remote host closed the connection] 08:24 -!- mfoemmel [~mfoemmel@chml01.drwholdings.com] has joined #go-nuts 08:36 < nsf> http://www.youtube.com/watch?v=HSFbRhXEFdw <- sneak peek for my documentation generator project, although it's far from release, but you somewhat can see the concept 08:40 -!- awidegreen [~quassel@62.176.237.78] has joined #go-nuts 08:46 -!- idr [~idr@g225064094.adsl.alicedsl.de] has joined #go-nuts 08:48 -!- tensorpudding [~user@99.148.202.191] has quit [Remote host closed the connection] 08:48 -!- gabriel9 [~gabriel9@93.157.192.28] has joined #go-nuts 08:55 -!- iomox [~ios@180.191.130.75] has joined #go-nuts 08:59 -!- napsy [~luka@88.200.96.18] has quit [Ping timeout: 240 seconds] 09:06 -!- ExtraSpice [~XtraSpice@88.118.33.48] has joined #go-nuts 09:25 -!- wrtp [~rog@92.16.125.129] has joined #go-nuts 09:29 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has joined #go-nuts 09:31 -!- virtualsue [~chatzilla@nat/cisco/x-tsmdnqrwwhkjjgld] has joined #go-nuts 09:33 -!- mikespook [~mikespook@219.137.48.14] has quit [Read error: Connection reset by peer] 09:39 -!- gabriel9 [~gabriel9@93.157.192.28] has quit [Remote host closed the connection] 09:47 -!- gabriel9 [~gabriel9@93.157.192.28] has joined #go-nuts 09:56 < wjlroe> nsf: ooh, looks very nice 09:57 < wjlroe> nsf: I use something similar for erlang, it's very useful 09:57 < nsf> :) 09:58 < nsf> wjlroe: do you have any links for that thing? is it web-based too? 09:58 < wjlroe> nsf: http://erldocs.com/ 09:59 < nsf> I though there are literally no documentation gens with live fuzzy filtering and I was wondering why, because they are nice to use 09:59 < nsf> hehe, nice 09:59 < nsf> but still it doesn't do fuzzy matching 09:59 -!- fabled [~fabled@83.145.235.194] has quit [Quit: Ex-Chat] 09:59 < wjlroe> also I use apidock 10:00 < nsf> the most interesting part of my project is fuzzy matching 10:00 < wjlroe> ok, I didn't notice the fuzzyness 10:00 < nsf> for example: 'vspec' will find 'ValueSpec' for you 10:00 < wjlroe> well it was a bit out of focus but... 10:01 < wjlroe> ok that's cool 10:01 < KBme> you'd need something like lucene for that no? 10:01 < wjlroe> I don't think I've seen fuzzy search on any api docs 10:01 -!- mfoemmel [~mfoemmel@chml01.drwholdings.com] has quit [Ping timeout: 252 seconds] 10:01 < nsf> KBme: for gowtf no, it runs 100% on client-side using javascript 10:02 < KBme> oh. 10:02 < wjlroe> so it's a custom algorithm for the fuzzyness? 10:02 < KBme> no lucene on javascript yet? 10:02 < nsf> KBme: I don't know 10:02 < nsf> wjlroe: yes 10:02 < nsf> well initially I haven't planned to show you the live example 10:03 < nsf> but looks like no one there anyway :) 10:03 < nsf> http://jiss.convex.ru/gowtf/index.html 10:03 < nsf> that's the app from the video 10:03 < nsf> should work on all latest browsers 10:03 < nsf> ff3.6 is a bit ugly, ff4.0 works fine though 10:04 < nsf> chromium and opera are the best ones (because of a very fast js engine) 10:04 < nsf> http://jiss.convex.ru/gowtf/gowtf-fuzzy.js <- fuzzy matching algo 10:07 < nsf> so.. what do you think? :) 10:07 < wjlroe> yeah it's working fast in chrome 10:07 < wjlroe> so are you indexing the core only? no pkgs? 10:07 -!- tulcod [~auke@z032089.its-s.tudelft.nl] has joined #go-nuts 10:08 < nsf> well it generates documentation for a package, I have plans to do full Go API reference, but currently it wasn't the focus 10:08 < nsf> I was working mostly on the html/css/js template 10:08 < nsf> this week I will improve the generator itself 10:08 < nsf> which collects data from sources and passes it to js 10:08 -!- fabled [~fabled@mail.fi.jw.org] has joined #go-nuts 10:09 < nsf> I'm not sure what you mean by indexing pkgs 10:09 < nsf> I think it will work on a per package basis 10:09 < nsf> (the filtering stuff) 10:09 < nsf> because if you have lots of data it will be slow 10:11 < wjlroe> yeah I mean liike tls/http that kind of thing 10:11 < wjlroe> it could get slower - which you why you wanna try it 10:12 < nsf> I'm afraid it will be slow even on big packages like 'syscall' 10:12 < nsf> that's my main concern 10:13 < nsf> and searching through all the packages at once 10:13 -!- wrtp [~rog@92.16.125.129] has quit [Ping timeout: 240 seconds] 10:13 < nsf> it just won't work 10:13 < tulcod> now that's a pessimistic view 10:13 < nsf> js won't be able to handle that 10:13 -!- mfoemmel [~mfoemmel@chml01.drwholdings.com] has joined #go-nuts 10:14 < nsf> wjlroe: basically I'm targeting people who develop their own packages, and this generator is capable of producing nice static documentation 10:14 < wjlroe> yeah but the main usecase will be to search all the docs that are on the golang site basically - like the erldocs thing (which is all js too) - so it's doable I think 10:14 < nsf> which is easily bundled or can be hosted on a free hosting :) 10:15 < wjlroe> yeah that's cool 10:15 < nsf> I don't think that this is the main usecase 10:15 < nsf> all time I use Go I haven't used packages-wide search 10:15 < wjlroe> I guess you could chain them together... somehow, I haven't thought this through 10:16 < nsf> but for me it's very annoying doing ctrl+f on each package web page 10:16 < nsf> and browser's ctrl+f has problems :) 10:16 < nsf> because obviously it's full text search 10:17 < wjlroe> I always need a pkg wide search - building stuff with Go or anyhing else means delving into the basic packages that already exist to use them for something (I'm not developing low-level pkgs but normal programmes) 10:17 < nsf> well, sure, but you can open all the packages you're interested in in separate tabs 10:17 < nsf> and go on 10:17 < wjlroe> yeah 10:17 < nsf> like I need to know what's in the GenDecl type, I switch to the go/ast tab and typing 'gdecl' 10:18 < nsf> and here I'm looking at the type definition 10:18 -!- victorcoder [~Adium@81.184.2.251] has joined #go-nuts 10:18 < wjlroe> but this has given me a good idea as to how to use the new Riak search ... mmm 10:19 -!- wrtp [~rog@92.16.125.129] has joined #go-nuts 10:19 < nsf> I like erldocs, it has few nice ideas actually 10:21 < nsf> and gowtf needs more usability research 10:21 < nsf> currently I don't like few things 10:22 < nsf> tree on the right is one of them 10:22 < nsf> I think it's useless :) 10:22 -!- mfoemmel [~mfoemmel@chml01.drwholdings.com] has quit [Ping timeout: 276 seconds] 10:28 < TheSeeker> ok, got kbuntu installed, found the package manager and am getting hg (and some games, duh) 10:33 -!- skejoe [~skejoe@188.114.142.231] has joined #go-nuts 10:35 -!- mikhailt [~mikhailt@2001:67c:7c:40d5:2e0:4cff:fe7b:13ff] has quit [Read error: Operation timed out] 10:37 -!- artefon [~thiago@189.59.198.84] has joined #go-nuts 10:38 < nsf> wjlroe: I took a closer look on erldocs 10:38 < nsf> well, yes, it does full docs search (about 7000 entries) 10:39 < nsf> but shows only first 100 10:39 < nsf> and it can do that, because it uses simple search algo, the complexity is linear 10:39 < nsf> I use fuzzy matching, which means: 10:39 < nsf> 1. score each entry 10:39 < nsf> 2. sort all that are matched 10:39 < nsf> 3. do the output 10:40 < nsf> and that kind of thing is quite limiting 10:40 < wjlroe> yeah this is clearly not a good idea for client side js 10:40 < nsf> so I guess I just have to stick to per package basis 10:40 < wjlroe> yeah 10:52 -!- fhs [~fhs@pool-74-101-63-115.nycmny.east.verizon.net] has joined #go-nuts 10:53 < nsf> hehe, go/ast contains just 107 entries 10:53 < nsf> and it was a bit slow on some browsers 10:53 -!- idr [~idr@g225064094.adsl.alicedsl.de] has quit [Read error: Connection reset by peer] 10:53 < nsf> I'm wondering what's the bottleneck 10:54 < nsf> imho it's a DOM modification and not the filtering stuff 10:55 -!- idr [~idr@g225065144.adsl.alicedsl.de] has joined #go-nuts 10:56 < nsf> huh, nice, chromium has a profiler as well for js 10:58 < nsf> and it's freaking awesome :) 10:58 < nsf> it's nice to have good tools 11:06 < nsf> hehe, indeed it's DOM manip 11:06 < nsf> then limiting the output should improve performance a lot 11:08 -!- res99 [~anonymous@201.237.130.70] has quit [Quit: res99] 11:11 < nsf> still.. preparing data: 15%, jquery's replaceWith: 85% 11:11 < nsf> that's quite interesting 11:16 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 11:28 -!- res99 [~anonymous@201.237.130.70] has joined #go-nuts 11:29 -!- mfoemmel [~mfoemmel@chml01.drwholdings.com] has joined #go-nuts 11:59 -!- skejoe [~skejoe@188.114.142.231] has quit [Quit: leaving] 12:08 -!- iant [~iant@66.135.114.72] has joined #go-nuts 12:08 -!- mode/#go-nuts [+v iant] by ChanServ 12:14 -!- iant [~iant@66.135.114.72] has quit [Ping timeout: 250 seconds] 12:17 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.3] 12:27 -!- quag [~quag@121-98-81-61.bitstream.orcon.net.nz] has quit [Ping timeout: 240 seconds] 12:28 -!- quag [~quag@121-98-81-61.bitstream.orcon.net.nz] has joined #go-nuts 12:29 -!- major_majors [~major_maj@108-65-203-205.lightspeed.livnmi.sbcglobal.net] has joined #go-nuts 12:32 -!- mikhailt [~mikhailt@2001:67c:7c:40d5:2e0:4cff:fe7b:13ff] has joined #go-nuts 12:32 -!- major_majors [~major_maj@108-65-203-205.lightspeed.livnmi.sbcglobal.net] has quit [Client Quit] 12:42 -!- DerHorst [~Horst@e176125067.adsl.alicedsl.de] has joined #go-nuts 12:52 -!- _DerHorst_ [~Horst@e176114178.adsl.alicedsl.de] has joined #go-nuts 12:55 -!- DerHorst [~Horst@e176125067.adsl.alicedsl.de] has quit [Ping timeout: 252 seconds] 12:57 -!- ronnyy [~quassel@2001:6f8:12c6:1c86:224:1dff:fed7:9541] has joined #go-nuts 12:59 -!- _DerHorst_ [~Horst@e176114178.adsl.alicedsl.de] has quit [Ping timeout: 252 seconds] 13:00 -!- virtualsue [~chatzilla@nat/cisco/x-tsmdnqrwwhkjjgld] has quit [Ping timeout: 250 seconds] 13:08 -!- skelterjohn [~jasmuth@c-76-124-135-199.hsd1.nj.comcast.net] has joined #go-nuts 13:10 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has joined #go-nuts 13:10 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 13:23 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts 13:26 -!- plainhao [~plainhao@mail.xbiotica.com] has joined #go-nuts 13:39 -!- boscop_ [~boscop@f055160158.adsl.alicedsl.de] has joined #go-nuts 13:40 -!- boscop [~boscop@g229220079.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds] 13:43 -!- wrtp [~rog@92.16.125.129] has quit [Ping timeout: 252 seconds] 13:46 -!- napsy [~luka@88.200.96.18] has joined #go-nuts 13:50 -!- wrtp [~rog@92.16.125.129] has joined #go-nuts 13:54 -!- skelterjohn [~jasmuth@c-76-124-135-199.hsd1.nj.comcast.net] has quit [Quit: skelterjohn] 13:55 -!- dj2 [~dj2@216.16.242.254] has joined #go-nuts 14:04 -!- bjarneh [~bjarneh@1x-193-157-202-52.uio.no] has joined #go-nuts 14:06 -!- gabriel9 [~gabriel9@93.157.192.28] has quit [Ping timeout: 250 seconds] 14:07 -!- artefon [~thiago@189.59.198.84] has quit [Quit: bye] 14:11 < Gertm> struggling with the fmt lib here. I just want a hex number printed out with leading zero padding. The documentation seems to assume you know C printf 14:11 < Gertm> so 'B' needs to become '0B' 14:17 < yiyus> Gertm: %02X for 2 digits 14:19 < Gertm> thanks 14:19 < yiyus> it is similar to C, but the documentation should be understandable without knowing C 14:20 < Gertm> perhaps I read over it, but I didn't know where to put the extra flags 14:21 -!- idr [~idr@g225065144.adsl.alicedsl.de] has quit [Remote host closed the connection] 14:24 -!- kanru2 [~kanru@61-30-10-70.static.tfn.net.tw] has quit [Ping timeout: 250 seconds] 14:28 -!- bjarneh [~bjarneh@1x-193-157-202-52.uio.no] has quit [Quit: leaving] 14:30 < yiyus> Gertm: fill an issue 14:30 < yiyus> of course, who wrote that documentation knows C, so it is easy to overlook these things 14:31 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 240 seconds] 14:33 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 14:36 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has joined #go-nuts 14:39 -!- MaksimBurnin [~max@44.188-224-87.telenet.ru] has joined #go-nuts 14:39 < Gertm> lemme fix my own bug here first, I'll reread the documentation thouroughly and if it really is an issue, I'll report it. 14:48 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has quit [Ping timeout: 255 seconds] 14:49 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has joined #go-nuts 14:56 -!- xash [~xash@d046058.adsl.hansenet.de] has joined #go-nuts 14:58 -!- artefon [~thiagon@150.164.2.20] has joined #go-nuts 14:58 -!- Fish [~Fish@86.65.182.207] has quit [Remote host closed the connection] 14:58 -!- awidegreen [~quassel@62.176.237.78] has quit [Quit: No Ping reply in 180 seconds.] 14:58 -!- awidegreen [~quassel@62.176.237.78] has joined #go-nuts 14:58 -!- Fish [~Fish@86.65.182.207] has joined #go-nuts 14:58 -!- wrtp [~rog@92.16.125.129] has quit [Ping timeout: 240 seconds] 15:04 -!- wrtp [~rog@92.16.125.129] has joined #go-nuts 15:08 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts 15:19 -!- iomox [~ios@180.191.130.75] has quit [Ping timeout: 252 seconds] 15:28 -!- bortzmeyer [~bortzmeye@batilda.nic.fr] has quit [Quit: Leaving.] 15:29 -!- wrtp [~rog@92.16.125.129] has quit [Ping timeout: 276 seconds] 15:30 -!- Venom_X [~pjacobs@74.61.90.217] has joined #go-nuts 15:31 -!- virtualsue [~chatzilla@nat/cisco/x-mwkopgewxgildtld] has joined #go-nuts 15:33 -!- wrtp [~rog@92.16.125.129] has joined #go-nuts 15:34 < gent00r> can someone tell me whats wrong with this code? 15:34 < gent00r> http://pastebin.com/bpVQzQFv 15:35 -!- noktoborus_ [debian-tor@gateway/tor-sasl/noktoborus] has quit [Remote host closed the connection] 15:37 < tulcod> gent00r, "hey, program doesn't work, what's wrong?" 15:38 < gent00r> that is precisely where i am stuck 15:38 < tulcod> well perhaps you could tell us how you've decided it doesn't work? 15:38 < gent00r> i cannot for the life of me figure out how to map methods of an object to a map 15:39 < gent00r> there is a problem with this statement v.umap = urlMap { 15:39 < gent00r> "/vms/home":v.index, 15:39 < gent00r> } 15:40 < gent00r> it works fine if the func index is not a member of object v 15:41 < gent00r> is this fixable? 15:42 < tulcod> gent00r, i don't know if it works like that 15:42 < tulcod> because if index would really be a member of v, then you could probably modify it 15:43 < yiyus> gent00r: is v a type or a value? 15:43 < tulcod> so if you want to do it like that, you should make index a real member (func pointer) of the struct 15:43 < tulcod> yiyus, http://pastebin.com/raw.php?i=bpVQzQFv 15:43 < tulcod> value 15:43 < yiyus> I think it should be a type 15:43 < tulcod> but it is a value ;) 15:44 < tulcod> gent00r, you still there? 15:44 < gent00r> yes 15:44 -!- gabriel9 [~gabriel9@93.157.192.28] has joined #go-nuts 15:45 < yiyus> you want a func(*vmsHandler,*web.Context) string) 15:45 < tulcod> well, what do you think? 15:45 < gent00r> but, i still can't understand why it should be a type 15:45 < tulcod> gent00r, "index" is not a member of your struct 15:45 < gent00r> yiyus, but func (*vmsHandler) index(*web.Context) string isnt the same? 15:45 < tulcod> sure, you can do v.index(...), but index is not a member like it would be in, say, C 15:45 < yiyus> (*vmsHandler).index has that signature 15:46 < yiyus> try to forget about methods notation, v.index is index(v, *web.Context) 15:46 < gent00r> yiyus, ok 15:46 < tulcod> gent00r, what you COULD do is add a member to your struct with the type (func(*vmsHandler, *web.Context) string) 15:47 < tulcod> and name it something like "handler", and set it every time you create a vmsHandler 15:48 < yiyus> or you could use func(*web.Context) string in your map, and then use as the value: func(c *web.Context) string { return v.index(c) } 15:48 < gent00r> yiyus, http://golang.org/doc/go_spec.html#Method_declarations 15:48 < gent00r> here it says both are equal 15:50 < tulcod> gent00r, says what is equal? 15:50 < yiyus> gent00r: see method expressions too 15:51 < gent00r> func (p *Point) Scale(factor float) = func(p *Point, factor float) <- type 15:51 < yiyus> If M is in the method set of type T, T.M is a function that is callable as a regular function with the same arguments as M prefixed by an additional argument that is the receiver of the method. 15:51 < tulcod> gent00r, yes, but where is it stored? 15:51 < tulcod> the "name" of that index function is index, not v.index 15:52 < gent00r> yiyus, tulcod thanks. i`ll read up on it 15:52 < tulcod> k gl 15:53 < yiyus> tulcod: the "name" is not index, then you could have problems with methods of other types, its "name" would be (*vmsHandler).index 15:53 < tulcod> oh, i'm sorry for that 15:53 < tulcod> gent00r, what yiyus said ^ :) 15:53 < tulcod> and yeah, that makes sense 15:58 -!- ukai [~ukai@nat/google/x-cpmscpdnvguxvkho] has quit [Ping timeout: 276 seconds] 15:58 -!- ukai [~ukai@nat/google/x-xojhamiaswzejrrm] has joined #go-nuts 16:02 -!- gzmask [~ray@corwin.cat.uregina.ca] has joined #go-nuts 16:02 < gzmask> when is the regex gonna be rewritten? 16:03 * TheSeeker gets gotris to work *feels accomplished* 16:03 -!- BlaSux [7f000001@69.195.144.4] has joined #go-nuts 16:05 < cbeck> gzmask: As I understand it sre2 is in the final steps for being swapped in for the temp regex package, but I could be wrong 16:05 -!- Fish [~Fish@86.65.182.207] has quit [Remote host closed the connection] 16:05 < uriel> I think sre2 and regex will probably co-exist for a while 16:06 < gzmask> see... thx 16:06 < uriel> but yea, sre2 is in the process of being reviewed and prepared for merging 16:06 < uriel> you can already use sre2 now if you really need something more than regexp 16:07 -!- lmoura [~lauromour@186.212.98.206] has joined #go-nuts 16:08 -!- dj2_ [~dj2@216.16.242.254] has joined #go-nuts 16:10 -!- dj2 [~dj2@216.16.242.254] has quit [Ping timeout: 255 seconds] 16:14 -!- Venom_X [~pjacobs@74.61.90.217] has quit [Quit: Venom_X] 16:15 -!- Venom_X [~pjacobs@66.54.185.131] has joined #go-nuts 16:15 < yebyen_> is there anyone out there? 16:21 < cbeck> maybe. 16:22 -!- skejoe [~skejoe@188.114.142.231] has joined #go-nuts 16:26 -!- gabriel9 [~gabriel9@93.157.192.28] has quit [Remote host closed the connection] 16:29 -!- b00m_chef [~watr@66.183.100.197] has joined #go-nuts 16:36 < uriel> no, nobody is out there, we are all in here 16:37 -!- tensorpudding [~user@99.148.202.191] has joined #go-nuts 16:38 < Tv> i'm going out there 16:40 -!- dj2_ [~dj2@216.16.242.254] has quit [Ping timeout: 240 seconds] 16:43 -!- Tv [~tv@cpe-76-168-227-45.socal.res.rr.com] has quit [Ping timeout: 276 seconds] 16:43 -!- dj2 [~dj2@216.16.242.254] has joined #go-nuts 16:50 -!- virtualsue [~chatzilla@nat/cisco/x-mwkopgewxgildtld] has quit [Ping timeout: 265 seconds] 16:51 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Quit: Leaving] 16:58 -!- wrtp [~rog@92.16.125.129] has quit [Quit: wrtp] 16:59 -!- gabriel9 [~gabriel9@93.157.192.28] has joined #go-nuts 17:01 -!- b00m_chef [~watr@66.183.100.197] has quit [Ping timeout: 240 seconds] 17:02 -!- diordna [~diordna@192.5.109.49] has joined #go-nuts 17:04 -!- enherit [~enherit@cpe-98-149-170-48.socal.res.rr.com] has joined #go-nuts 17:13 -!- ShadowIce [~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has joined #go-nuts 17:13 -!- ShadowIce [~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has quit [Changing host] 17:13 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 17:13 -!- tulcod [~auke@z032089.its-s.tudelft.nl] has quit [Quit: Leaving] 17:14 -!- sacho [~sacho@95-42-106-208.btc-net.bg] has quit [Ping timeout: 245 seconds] 17:15 < gent00r> How do i write multi-line strings ? 17:15 < wjlroe> just use multiple \n's? 17:16 < gent00r> wjlroe, in code. Not as output 17:16 < gent00r> if i were to write a long sql statement 17:16 < wjlroe> oh i see 17:17 < gent00r> any way? 17:18 -!- Tv [~tv@gige.bur.digisynd.com] has joined #go-nuts 17:19 < wjlroe> not sure - seems there's no mention of how to in the spec 17:21 -!- tvw [~tv@e176007115.adsl.alicedsl.de] has joined #go-nuts 17:21 < gent00r> i guess long lines for me then ;) 17:25 -!- victorcoder [~Adium@81.184.2.251] has quit [Quit: Leaving.] 17:26 -!- sacho [~sacho@95-42-106-208.btc-net.bg] has joined #go-nuts 17:30 -!- diordna [~diordna@192.5.109.49] has quit [Quit: diordna] 17:33 < mpl> gent00r: `` 17:34 < mpl> gent00r: http://golang.org/doc/go_spec.html#String_literals 17:36 < gent00r> thanks mpl 17:36 < mpl> np 17:42 -!- dj2_ [~dj2@216.16.242.254] has joined #go-nuts 17:42 -!- fabled [~fabled@mail.fi.jw.org] has quit [Quit: Ex-Chat] 17:43 -!- dj2 [~dj2@216.16.242.254] has quit [Ping timeout: 255 seconds] 17:54 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts 17:56 -!- ronnyy [~quassel@2001:6f8:12c6:1c86:224:1dff:fed7:9541] has quit [Remote host closed the connection] 17:59 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 264 seconds] 17:59 -!- iant [~iant@192.75.139.248] has joined #go-nuts 17:59 -!- mode/#go-nuts [+v iant] by ChanServ 18:03 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 18:05 -!- ucasano [~ucasano@host153-182-static.227-95-b.business.telecomitalia.it] has quit [Quit: ucasano] 18:11 -!- XenoPhoenix [~Xeno@cpc5-aztw24-2-0-cust39.aztw.cable.virginmedia.com] has quit [Ping timeout: 272 seconds] 18:11 -!- iant [~iant@192.75.139.248] has quit [Read error: Connection reset by peer] 18:11 -!- iant1 [~iant@192.75.139.248] has joined #go-nuts 18:13 -!- XenoPhoenix [~Xeno@cpc5-aztw24-2-0-cust39.aztw.cable.virginmedia.com] has joined #go-nuts 18:13 -!- iant1 [~iant@192.75.139.248] has quit [Read error: Connection reset by peer] 18:28 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has joined #go-nuts 18:29 -!- fhs [~fhs@pool-74-101-63-115.nycmny.east.verizon.net] has quit [Quit: leaving] 18:31 -!- Soultaker [~Soultaker@hell.student.utwente.nl] has quit [Ping timeout: 240 seconds] 18:33 -!- gent00r [~haxOr@gw.invnetworks.com] has quit [Quit: Leaving] 18:33 -!- artefon [~thiagon@150.164.2.20] has quit [Quit: Leaving] 18:34 -!- fhs [~fhs@pool-74-101-63-115.nycmny.east.verizon.net] has joined #go-nuts 18:38 -!- ExtraSpice [~XtraSpice@88.118.33.48] has quit [Ping timeout: 240 seconds] 18:45 -!- Soultaker [~Soultaker@hell.student.utwente.nl] has joined #go-nuts 18:49 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts 19:01 -!- photron [~photron@port-92-201-7-153.dynamic.qsc.de] has joined #go-nuts 19:02 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Ping timeout: 240 seconds] 19:04 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has joined #go-nuts 19:05 -!- araujo [~araujo@190.38.50.25] has joined #go-nuts 19:05 -!- araujo [~araujo@190.38.50.25] has quit [Changing host] 19:05 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts 19:08 -!- zozoR [~zozoR@5634798d.rev.stofanet.dk] has quit [Quit: Morten. Desu~] 19:12 -!- tulcod [~auke@wlan-145-94-184-50.wlan.tudelft.nl] has joined #go-nuts 19:16 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has quit [Read error: No route to host] 19:17 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has joined #go-nuts 19:17 -!- artefon [~thiago@189.59.198.84] has joined #go-nuts 19:18 -!- Xurix [~Luixsia@AToulouse-254-1-9-217.w83-203.abo.wanadoo.fr] has joined #go-nuts 19:18 -!- Xurix [~Luixsia@AToulouse-254-1-9-217.w83-203.abo.wanadoo.fr] has quit [Client Quit] 19:29 -!- plainhao [~plainhao@mail.xbiotica.com] has quit [Quit: plainhao] 19:37 -!- wjlroe_ [~will@212.169.34.114] has joined #go-nuts 19:37 -!- wjlroe_ [~will@212.169.34.114] has quit [Client Quit] 19:39 -!- wjlroe [~will@212.169.34.114] has quit [Ping timeout: 264 seconds] 19:42 -!- fabled [~fabled@83.145.235.194] has joined #go-nuts 19:53 -!- jhseu [~jhseu@nat/google/x-gkdttyurbeqbspqx] has quit [Quit: Leaving] 19:53 -!- skejoe [~skejoe@188.114.142.231] has quit [Quit: leaving] 19:57 -!- deso [~deso@x0561a.wh30.tu-dresden.de] has quit [Remote host closed the connection] 20:06 -!- Eridius [~kevin@unaffiliated/eridius] has joined #go-nuts 20:08 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Read error: Operation timed out] 20:30 -!- virtualsue [~chatzilla@nat/cisco/x-buysjdkebtvjuqul] has joined #go-nuts 20:30 -!- aho [~nya@fuld-4d00d64c.pool.mediaWays.net] has joined #go-nuts 20:38 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 20:52 -!- wjlroe [~will@78-86-14-131.zone2.bethere.co.uk] has joined #go-nuts 20:52 -!- hallas [~hallas@x1-6-30-46-9a-b2-c5-1f.k891.webspeed.dk] has joined #go-nuts 20:52 < hallas> evenin' 20:55 -!- skelterjohn [~jasmuth@lawn-gw.rutgers.edu] has quit [Quit: skelterjohn] 20:57 -!- jcao219 [~jcao219@pool-96-226-238-248.dllstx.fios.verizon.net] has joined #go-nuts 21:00 -!- tvw [~tv@e176007115.adsl.alicedsl.de] has quit [Remote host closed the connection] 21:14 -!- rlab [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 21:24 -!- wjlroe [~will@78-86-14-131.zone2.bethere.co.uk] has quit [Quit: Computer has gone to sleep] 21:24 -!- pothos [~pothos@111-240-214-9.dynamic.hinet.net] has joined #go-nuts 21:26 -!- pothos_ [~pothos@111-240-218-60.dynamic.hinet.net] has quit [Read error: Connection reset by peer] 21:31 -!- dj2_ [~dj2@216.16.242.254] has quit [Remote host closed the connection] 21:33 -!- unhygienix [~unhygieni@host86-176-179-197.range86-176.btcentralplus.com] has joined #go-nuts 21:35 -!- p4p4 [~chatzilla@82.113.106.31] has joined #go-nuts 21:35 -!- p4p4 [~chatzilla@82.113.106.31] has left #go-nuts [] 21:35 -!- lavalamp_ [4507d76a@gateway/web/freenode/ip.69.7.215.106] has joined #go-nuts 21:38 -!- jyoshm [~jmissao@unaffiliated/sundial] has quit [Quit: Lost terminal] 21:40 -!- tulcod [~auke@wlan-145-94-184-50.wlan.tudelft.nl] has quit [Quit: Leaving] 21:47 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit: Verlassend] 21:48 -!- mat_ [~mat@mx3.absolight.net] has quit [Read error: Connection reset by peer] 21:50 -!- unhygienix [~unhygieni@host86-176-179-197.range86-176.btcentralplus.com] has quit [Quit: unhygienix] 21:50 -!- Paradox924X [~Paradox92@vaserv/irc/founder] has quit [Ping timeout: 250 seconds] 21:51 -!- Eridius [~kevin@unaffiliated/eridius] has quit [Ping timeout: 240 seconds] 21:52 -!- mat_ [~mat@mx3.absolight.net] has joined #go-nuts 21:54 -!- awidegreen [~quassel@62.176.237.78] has quit [Read error: Connection reset by peer] 21:56 -!- Paradox924X [~Paradox92@c-68-35-229-34.hsd1.fl.comcast.net] has joined #go-nuts 22:15 -!- preflex [~preflex@unaffiliated/mauke/bot/preflex] has quit [Ping timeout: 264 seconds] 22:18 -!- lavalamp_ [4507d76a@gateway/web/freenode/ip.69.7.215.106] has quit [Quit: later guys] 22:20 -!- preflex [~preflex@unaffiliated/mauke/bot/preflex] has joined #go-nuts 22:20 -!- photron [~photron@port-92-201-7-153.dynamic.qsc.de] has quit [Ping timeout: 255 seconds] 22:24 -!- Project_2501 [~Marvin@dynamic-adsl-94-36-152-44.clienti.tiscali.it] has quit [Quit: E se abbasso questa leva che succ...] 22:33 -!- hallas [~hallas@x1-6-30-46-9a-b2-c5-1f.k891.webspeed.dk] has quit [Remote host closed the connection] 22:36 -!- gzmask [~ray@corwin.cat.uregina.ca] has quit [Quit: gzmask] 22:38 -!- gabriel9 [~gabriel9@93.157.192.28] has quit [Remote host closed the connection] 22:41 -!- Eridius [~kevin@unaffiliated/eridius] has joined #go-nuts 22:53 -!- crazy2be [~crazy2be@S0106001ac401d400.cg.shawcable.net] has joined #go-nuts 22:53 < crazy2be> Does anyone know of a web host that provides golang support? 23:06 < KirkMcDonald> Any host that gives you shell access should be able to use Go. 23:07 < KirkMcDonald> I doubt any hosts have explicit support for it. 23:08 -!- steveno [~stevenoli@paludis/cheerleader/steveno] has joined #go-nuts 23:10 < crazy2be> KirkMcDonald: But you would have to set up apache to port-forward? 23:10 < crazy2be> since otherwise the golang program would have to run as root, right? 23:11 < kimelto> can drop privileges after port binding :) 23:11 < crazy2be> how? 23:11 -!- scarabx [~scarabx@c-76-19-43-200.hsd1.ma.comcast.net] has joined #go-nuts 23:12 -!- Paradox924X [~Paradox92@c-68-35-229-34.hsd1.fl.comcast.net] has quit [Changing host] 23:12 -!- Paradox924X [~Paradox92@vaserv/irc/founder] has joined #go-nuts 23:14 < KirkMcDonald> Or implement FastCGI for Go. 23:14 < kimelto> Syscall.Setuid() ? 23:14 -!- iant [~iant@66.135.114.72] has joined #go-nuts 23:14 -!- mode/#go-nuts [+v iant] by ChanServ 23:17 < plexdev> http://is.gd/giUak by [Russ Cox] in go/src/cmd/5c/ -- 5c: implement uint32 -> float 23:18 -!- xash [~xash@d046058.adsl.hansenet.de] has quit [Read error: Operation timed out] 23:24 < crazy2be> how can you do ipc with golang? 23:25 < crazy2be> Can you use channels with other processes? 23:29 < crazy2be> bbl 23:29 -!- crazy2be [~crazy2be@S0106001ac401d400.cg.shawcable.net] has quit [Remote host closed the connection] 23:34 -!- steveno [~stevenoli@paludis/cheerleader/steveno] has quit [Quit: steveno] 23:35 < plexdev> http://is.gd/giVDM by [Russ Cox] in go/src/cmd/5g/ -- 5g: complex "regalloc" 23:35 < plexdev> http://is.gd/giVDX by [Russ Cox] in 3 subdirs of go/src/pkg/ -- arm: fix signal handler 23:50 < nsf> KirkMcDonald: afaik there was a fastcgi library somewhere for Go 23:50 < nsf> http://github.com/jldailey/fcgigo 23:51 < nsf> not sure how reliable it is 23:51 < nsf> ah.. crazy2be has quit :( 23:51 < plexdev> http://is.gd/giX9U by [Robert Griesemer] in go/doc/ -- go_spec: allow copy() to copy bytes from a string into a []byte 23:52 < plexdev> http://is.gd/giXa3 by [Robert Griesemer] in go/doc/ -- go spec: append built-in 23:52 -!- dj2 [~dj2@2002:63ec:1a4e:0:21f:5bff:fe35:feb5] has joined #go-nuts 23:54 < nsf> hehe, I've discovered funny fact yesterday, when you're using Chromium's innerHTML for DOM manip it works faster than anything else, but for some reason it's horribly slow in profiling mode :D 23:55 < nsf> so.. it's faster, but you can't prove that with numbers :D 23:58 -!- skelterjohn [~jasmuth@c-76-124-135-199.hsd1.nj.comcast.net] has joined #go-nuts 23:58 -!- virtualsue [~chatzilla@nat/cisco/x-buysjdkebtvjuqul] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.5.14/20101001164112]] --- Log closed Tue Oct 26 00:00:12 2010