Go Language Resources Go, golang, go... NOTE: This page ceased updating in October, 2012

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