1 Jul 2010 02:02
Re: Windows Port
> http://gist.github.com/458549 > Lucky, you use proxy, because name resolution doesn't work yet <g> ... Alex
> http://gist.github.com/458549 > Lucky, you use proxy, because name resolution doesn't work yet <g> ... Alex
> It seems that goinstall is becoming more and more the norm for many > package distributions, with good reason; it's a very useful tool. > How much trouble would it be to modify it slightly so that it could > also run a template preprocessor? gotit, for instance, seems fine. I am very wary of doing this, because the generics story in Go is far from settled, and this would commit to using a particular tool. Gotit (I forget its new name) is interesting but it can't be the long term solution, and so I'd prefer not to establish more support for it and grow the amount of code that depends on it. The 'template package' approach is one that we considered early on, but it has significant problems with expressibility. It's not clear to me how to matrix of matrices; maybe that's possible, with a very long import string. The bigger problem is that it is, by definition, impossible to make a matrix whose element type is one that is local to your own package. For example, you might have a type num that makes sense locally but that you'd prefer not to export, or maybe num is defined only inside a particular function. You can't make a matrix of num, because it would come from another package, and other packages can't refer to your num. > The import string could contain the template information. Perhaps > > import matrix32 "gomatrix.googlecode.com/hg/matrix(float32)" > import matrixC64 "gomatrix.googlecode.com/hg/matrix(complex64)" > > Just something simple like that. Then goinstall would put it in the(Continue reading)
I have come up with a sort of ugly but usable solution here is my proof of concept http://github.com/timtadh/goplay/tree/master/generic_stack/ In my proof of concept, I took Rob's suggestion thought about it and came up with this pattern (which I will use until a more permanent solution arrives). I made a generic stack . When I want a typed version of particular methods I simply "override" those methods in my namespace by aliasing the type stack.Stack eg. <code> type StrStack stack.Stack func (s *StrStack) Pop() string { self := (*stack.Stack)(s) i, _ := self.Pop().(string) return i } </code> Hope this idea is useful to someone else as well. Cheers Tim On Jun 30, 4:04 pm, "Rob 'Commander' Pike" <r...@...> wrote: > > However, based on my > > experience with Go (which has been very positive) the developers of Go > > should not so easily dismiss Generics! >(Continue reading)
On Jun 30, 2010, at 6:15 PM, Tim Henderson wrote: > I have come up with a sort of ugly but usable solution here is my > proof of concept http://github.com/timtadh/goplay/tree/master/generic_stack/ > > In my proof of concept, I took Rob's suggestion thought about it and > came up with this pattern (which I will use until a more permanent > solution arrives). I made a generic stack . When I want a typed > version of particular methods I simply "override" those methods in my > namespace by aliasing the type stack.Stack > > eg. > <code> > type StrStack stack.Stack > > func (s *StrStack) Pop() string { > self := (*stack.Stack)(s) > i, _ := self.Pop().(string) > return i > } > </code> That's how the original Vector code was specialized to IntVector. -rob
I have successfully run some simple Go programs under the ARMv7 [1]
architecture but the simple web server [2] off of golang.org produces
a weird allocation bug. The program attempts to do an assignment and
then consumes memory until the system kills the process. The offending
statement is in src/pkg/net/fd.go at line 285 (on tip,
5744:6470c731be0e):
func newFD(fd, ...) {
// ...
var ls, rs string
if laddr != nil {
ls = laddr.String() // program locks here
}
I'm not sure what I can do, if anything, from this point. Any ideas?
Here is a stacktrace from placing a panic() before the line which has
the problematic assignment:
====================================
# ./test
panic: laddr != nil
panic PC=0x40023e98
runtime.panic+0x8c /home/cwvh/src/go/src/pkg/runtime/malloc.c:896
runtime.panic(0x0, 0x40023ec0)
net.newFD+0x394 /home/cwvh/src/go/src/pkg/runtime/chan.c:-721
net.newFD(0xad8e4, 0x40020900, 0xc, 0xad8e4, 0x40020900, ...)
net.socket+0x4b4 /home/cwvh/src/go/src/pkg/syscall/str.go:0
net.socket(0x3, 0xa, 0x1, 0x9f104, 0x3, ...)
(Continue reading)Here comes another package change. The next release will contain a small change to the behavior of the Split function in the bytes and strings packages. They both take a count argument to limit the size of the return. In the original code, a zero or negative count meant 'unbounded'. The next release changes the behavior so 0 is not 'unbounded' but zero. This seems more consistent with the likely needs of programs. Although it's a trivial change, calls to Split with a count of zero are quite common, so please plan ahead and update your code now by changing those zeros to a negative value such as -1. -rob
On 30 June 2010 00:40, Archos <raul.san@...> wrote: > Why I cann't install this package? > > $ sudo -E goinstall -v github.com/kless/gowebto/tree/master/webto > > Output: > > github.com/kless/gowebto/tree/master/webto > goinstall: github.com/kless/gowebto/tree/master/webto: open /var/tmp/ > go/src/pkg/github.com/kless/gowebto/tree/master/webto: no such file or > directory Sometimes sudo can cause environment variables to change. Perhaps GOROOT isn't visible to goinstall in this case, and becomes confused. Try: sudo -E env | grep ^GO and see if all appears well. Andrew
here i have something like this
in libxml c header :::
htmlDocPtr htmlReadDoc (const xmlChar * cur, const char * URL, const
char * encoding, int options)
xmlChar * xmlCharStrdup (const char * cur)
my very simple binding:::
type XmlDoc struct {
Ptr *C.xmlDoc
}
func HtmlReadDoc(content string, url string, encoding string, opts
int) *XmlDoc {
var d *XmlDoc
c := C.xmlCharStrdup( C.CString(content) )
d.Ptr = C.htmlReadDoc( c, C.CString(url), C.CString(encoding),
C.int(opts) )
return d
}
when i call this func from Go, i get invalid memory address or nil
pointer dereference.
can anybody help me with this as im not that good with C , pointer and
such. Thanks
(Continue reading)On Thu, Jul 1, 2010 at 2:41 PM, kar <akmalxxx@...> wrote: > here i have something like this > > in libxml c header ::: > > htmlDocPtr htmlReadDoc (const xmlChar * cur, const char * URL, const > char * encoding, int options) > xmlChar * xmlCharStrdup (const char * cur) > > > my very simple binding::: > > type XmlDoc struct { > Ptr *C.xmlDoc > } > > func HtmlReadDoc(content string, url string, encoding string, opts > int) *XmlDoc { > var d *XmlDoc > c := C.xmlCharStrdup( C.CString(content) ) > d.Ptr = C.htmlReadDoc( c, C.CString(url), C.CString(encoding), > C.int(opts) ) > return d > } > > when i call this func from Go, i get invalid memory address or nil > pointer dereference. > > can anybody help me with this as im not that good with C , pointer and > such. Thanks(Continue reading)
oh thanks again Jessta, i somehow get a hang on pointers now, yes should be as you pointed out. On Jul 1, 1:01 pm, Jessta <jes...@...> wrote: > On Thu, Jul 1, 2010 at 2:41 PM, kar <akmal...@...> wrote: > > here i have something like this > > > in libxml c header ::: > > > htmlDocPtr htmlReadDoc (const xmlChar * cur, const char * URL, const > > char * encoding, int options) > > xmlChar * xmlCharStrdup (const char * cur) > > > my very simple binding::: > > > type XmlDoc struct { > > Ptr *C.xmlDoc > > } > > > func HtmlReadDoc(content string, url string, encoding string, opts > > int) *XmlDoc { > > var d *XmlDoc > > c := C.xmlCharStrdup( C.CString(content) ) > > d.Ptr = C.htmlReadDoc( c, C.CString(url), C.CString(encoding), > > C.int(opts) ) > > return d > > } > > > when i call this func from Go, i get invalid memory address or nil > > pointer dereference.(Continue reading)
RSS Feed2068 | |
|---|---|
2898 | |
2962 | |
3409 | |
3866 | |
2618 | |
2496 | |
3240 | |
3415 | |
2206 | |
2862 | |
2375 | |
2484 | |
3167 | |
3718 | |
2914 | |
1995 | |
1975 | |
2158 | |
2274 | |
1796 | |
1614 | |
1981 | |
2270 | |
2238 | |
1648 | |
1557 | |
1654 | |
1188 | |
1561 | |
1950 | |
1510 | |
1541 | |
1633 | |
1516 | |
1381 | |
1413 | |
1964 | |
1564 | |
1260 | |
1412 | |
2930 | |
3775 |