>
> I have started to work on DOM binding based on WebIDL and a binding
> generator. I don't have full WebIDL support yet, but it does process idl
> from about 80 specifications. See https://gowebapi.github.io for more
> details.
>
Hi Martin,
I'd like to second Tyler's suggestion that you start
With GC off the free will not be called, nor will destructors be executed in
response to finalizers, so many memory corruption errors will not be
experienced (nor detected).
Almost certainly the C memory is not being managed correctly - possibly copying
a pointer between structs and then
Very nice, `xml:",any"` was doing the trick. I've condensed the function
and here's the (currently) final
result: https://play.golang.org/p/G1eGw5gtk7C
func id3(axl []byte) string {
type Return struct {
Response struct {
Return string `xml:"return"`
} `xml:",any"`
}
var ret Return
err :=
HI all,
Error unexpected fault address might be triggered by data race or memory
corruption. After code review, I suspected the reasin is memory corruption
instead
of the data race.
The following code panics occasionally, and yes, when I initialized silces.
package controlcan
import "C"
You don't have to use an xml.Decoder. You may be able to use the
`xml:",any"` tag for this case.
type Response struct {
XMLName xml.Name
Return string `xml:"return"`
}
type Outer struct {
XMLName struct{} `xml:"outer"`
Responses []Response `xml:",any"`
}
Type is also a method set. So even if two types have equal underlying types,
their method sets (the methods defined on them) are different.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
thanks for replay, you said right, i have changed the code, its works fine,
thank you, here is code:
package main
import (
"fmt"
"runtime"
)
func test() {
var zero = 0
_ = 1 / zero
}
func Stack() {
var pc [16]uintptr
n := runtime.Callers(0, pc[:])
fmt.Println(n, pc)
callers := pc[:n]
frames
hi Jake
On Sunday, February 24, 2019 at 11:27:10 PM UTC, Jake Montgomery wrote:
>
> Maybe I'm misunderstanding, but the important thing is that foo never be
> copied. In your example, it is, in fact, *not *copied. See
> https://play.golang.org/p/U5EsDZSO3ce. Note that Foo is copied, but both
>
Maybe I'm misunderstanding, but the important thing is that foo never be
copied. In your example, it is, in fact, *not *copied. See
https://play.golang.org/p/U5EsDZSO3ce. Note that Foo is copied, but both f2
and f3 contain the same foo pointer, so the foo was never copied or moved.
When
On Sun, Feb 24, 2019 at 3:34 PM wrote:
>
> thanks for the suggestion Burak and Jake, however embedding won't do for the
> same reason as aliasing - it allows copying by value, which i want to prevent
> (in my real use case foo.bar is a C pointer).
You could make it 2-layers, with the pointer
thanks for the suggestion Burak and Jake, however embedding won't do for
the same reason as aliasing - it allows copying by value, which i want to
prevent (in my real use case foo.bar is a C pointer).
https://play.golang.org/p/4BcOQTGkPiy works, and it should not (f3 := *f2
is a no as it makes
On Sunday, February 24, 2019 at 4:31:10 PM UTC-5, Deomid Ryabkov wrote:
>
> Why can't Go resolve methods declared on the pointer receiver of the
> destination type?
>
Because that is not how the language was designed. (I'm too busy to look
up the spec here, but it is in there.)
>
> consider:
On Sunday, February 24, 2019 at 9:36:07 PM UTC, rog wrote:
>
> Foo is declared as a new type, and no methods are declared on that that
> type. If you had declared:
>
> type Foo = *Foo
>
> it would have been a different matter.
>
true. however, i don't want a type alias because that would
Foo is declared as a new type, and no methods are declared on that that
type. If you had declared:
type Foo = *Foo
it would have been a different matter.
On Sun, 24 Feb 2019, 10:30 pm , wrote:
> Why can't Go resolve methods declared on the pointer receiver of the
> destination type?
>
>
Why can't Go resolve methods declared on the pointer receiver of the
destination type?
consider:
type foo struct{
bar int
}
type Foo *foo
func (f *foo) GetBar() int {
return f.bar
}
func NewFoo(bar int) Foo {
return {bar: bar}
}
func main() {
f1 := {bar: 123}
fmt.Printf("%d\n", f1.GetBar())
Your function appears to return error text, but it will be much more clear
what's going on when reading the code if you encode your intent in the return
type and return an error instead of a string (which gives me no information
about what that string is supposed to represent: is it an error?
Thanks for the response. I was hoping it would be possible with just
xml.Unmarshal.
I now have this implementation - any comments on that? (I'm okay with
returning the error inline, it's just for logging purposes):
Playground: https://play.golang.org/p/6J8XndWdlv_N
func id2(axl []byte) string
Hi,
I have started to work on DOM binding based on WebIDL and a binding
generator. I don't have full WebIDL support yet, but it does process idl
from about 80 specifications. See https://gowebapi.github.io for more
details.
Martin
Den fredag 28 december 2018 kl. 13:16:22 UTC+1 skrev Chris
18 matches
Mail list logo
