Thanks very much for your replies. I guess the killer argument is that
finalizers are not guaranteed to run! I didnt know that. Just to be clear,
Im not intending exposing WrappedString to my clients only standard go
strings, everything *should* be freed up when my outer wrapper function
exits
On 17 October 2016 at 17:18, Sokolov Yura wrote:
>
> понедельник, 17 октября 2016 г., 18:12:59 UTC+3 пользователь Roberto Zanotto
> написал:
>>
>> I missed the chance to comment on github...
>>
>> This also works for implementing futures and it's simple, type-safe and
>> can be used with select:
>
go version go1.7.1 darwin/amd64
--
Jiří Šimša
On Mon, Oct 17, 2016 at 8:02 PM, Ian Lance Taylor wrote:
> On Mon, Oct 17, 2016 at 6:20 PM, wrote:
> >
> > The backend of my web server (written in Go) have recently started
> consuming
> > large amounts of CPU. AFAICT, the CPU seems to be consume
On Mon, Oct 17, 2016 at 6:20 PM, wrote:
>
> The backend of my web server (written in Go) have recently started consuming
> large amounts of CPU. AFAICT, the CPU seems to be consumed by the garbage
> collector and I would appreciate any information that would help me track
> down the root cause.
Hello,
The backend of my web server (written in Go) have recently started
consuming large amounts of CPU. AFAICT, the CPU seems to be consumed by the
garbage collector and I would appreciate any information that would help me
track down the root cause.
When I run the web server with gctrace=1,
> On Oct 17, 2016, at 5:03 PM, andrew.sm...@miracl.com wrote:
>
> Hi,
>
> When using cgo its my understanding that strings created with C.CString must
> be freed with C.free, but yet numeric types do not need to be explicitly
> freed.
Yes. This is because strings in C are not first class obje
Hi,
When using cgo its my understanding that strings created with C.CString
must be freed with C.free, but yet numeric types do not need to be
explicitly freed.
Firstly, is CString a special case here, or are there other types that need
to be explicitly freed as well?
Secondly, Im writing a l
Thanks for confirming, I realised this by digging into the go build code.
// Run SWIG on one SWIG input file.
3553 func (b *builder) swigOne(p *Package, file, obj string, pcCFLAGS
[]string, cxx bool, intgosize string) (outGo, outC string, err error) {
3554 cgoCPPFLAGS, cgoCFLAGS, c
No, method 1 preserves "err" if it is not nil.
Tong Sun ezt írta (időpont: 2016. okt. 17., H 20:11):
>
> On Mon, Oct 17, 2016 at 1:20 AM, Tamás Gulácsi wrote:
>
>
>
> The reason that I didn't do it, is because I don't know how to do it. In
> essence, that "f.Close()" that you worried about is wr
I'm currently looking for a developer to join one my largest clients in
Downtown Denver, CO.
This team handles strategic short projects
Specific targeted gap - video distribution team
They are building a product for video stream infrastructure
*Looking for a *
Golang developer - automatio
We are using Hashicorp's mdns library (https://github.com/hashicorp/mdns)
for node discovery, with a frequency of 1 mdns query / minute. The CPU
consumption by the process increases very gradually over a couple of days,
going from 2-3% to 20-30% over 3-4 days. From the runtime instrumentation
w
On Oct 16, 2016 6:03 PM, "Liam Breck" wrote:
>
>
>
> On Sun, Oct 16, 2016 at 5:32 PM, Ian Lance Taylor wrote:
>>
>> On Sun, Oct 16, 2016 at 5:25 PM, Liam wrote:
>> >
>> > On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor
wrote:
>> >>
>> >> On Sun, Oct 16, 2016 at 3:34 PM, Liam w
On Mon, Oct 17, 2016 at 1:20 AM, Tamás Gulácsi wrote:
>
>
>> The reason that I didn't do it, is because I don't know how to do it. In
>> essence, that "f.Close()" that you worried about is wrapped in "defer
>> f.Close()" in SaveState, which in turn wrapped in "defer SaveState" in a
>> function. I.
On 17 October 2016 at 12:31, Sokolov Yura wrote:
>
> понедельник, 17 октября 2016 г., 18:08:43 UTC+3 пользователь
> adon...@google.com написал:
>>
>> Go does not take a strong Erlang-like stance against concurrency with
>> shared variables, so mutexes really are critical to Go's concurrency.
>>
>
On Mon, Oct 17, 2016 at 4:11 AM, wrote:
>
> I have a follow-up question, how can I instrument my go code so that I can
> set the include path that is used to resolve '%include' statements in my
> swig code. Currently I have relative paths in my swig file, and I would like
> to put '/usr/include'
On Mon, Oct 17, 2016 at 8:26 AM, wrote:
> Is there a way in Golang to cache the response from the DNS server? Java
> apps by default cache the DNS info until the app gets restarted.
You can do DNS lookups yourself using `net.LookupHost` and friends.
Ian
> On Sunday, October 16, 2016 at 5:01:44
понедельник, 17 октября 2016 г., 18:08:43 UTC+3 пользователь
adon...@google.com написал:
>
>
> Go does not take a strong Erlang-like stance against concurrency with
> shared variables, so mutexes really are critical to Go's concurrency.
>
Am I mistaken? Golang authors said mutexes are second c
Is there a way in Golang to cache the response from the DNS server? Java
apps by default cache the DNS info until the app gets restarted.
On Sunday, October 16, 2016 at 5:01:44 PM UTC-5, Ian Lance Taylor wrote:
>
> On Sun, Oct 16, 2016 at 9:10 AM, >
> wrote:
> >
> > Getting dail tcp error whi
понедельник, 17 октября 2016 г., 18:12:59 UTC+3 пользователь Roberto
Zanotto написал:
>
> I missed the chance to comment on github...
>
> This also works for implementing futures and it's simple, type-safe and
> can be used with select:
> https://play.golang.org/p/VDT36rC5A-
> Of course the synt
A future is just a special case of an observable. Honestly I'd prefer if
an observable was built-in the language like a channel. You could use it
like a channel in selects and the like, but with the possibility of
receiver observables to be closable. When the list receiver observable is
closed
I missed the chance to comment on github...
This also works for implementing futures and it's simple, type-safe and can
be used with select:
https://play.golang.org/p/VDT36rC5A-
Of course the syntax is not as nice as built-in futures.
On Sunday, October 16, 2016 at 2:40:32 PM UTC+2, Sokolov Yura
On Monday, 17 October 2016 10:10:47 UTC-4, Sokolov Yura wrote:
>
> Mutex needs not to be type-safe.
> And Mutex is not part of concept of "language tailored towards
> concurrency".
>
Go does not take a strong Erlang-like stance against concurrency with
shared variables, so mutexes really are cr
On Sun, 16 Oct 2016 05:40:32 -0700 (PDT)
Sokolov Yura wrote:
> "future" is commonly used synchronization abstraction.
>
> It could be implemented in a library, using mutex, channel and
> interface. Example:
> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>
> But
Konstantin
No, no sync.Cond.
Please, read links before writing answers.
Please.
понедельник, 17 октября 2016 г., 17:12:42 UTC+3 пользователь Konstantin
Khomoutov написал:
>
> On Sun, 16 Oct 2016 05:40:32 -0700 (PDT)
> Sokolov Yura > wrote:
>
> > "future" is commonly used synchronization abstra
Have a hugo blog? Want to give your go packages a custom import url (e.g.
import "npf.io/gorram/run")? You can do it with just a few lines of
templates / frontmatter.
It took some figuring out to get this working, but once you know how to do
it, it's pretty easy.
https://npf.io/2016/10/vani
Mutex needs not to be type-safe.
And Mutex is not part of concept of "language tailored towards concurrency".
But "future" is well known, widely adopted (though, in different ways)
concurrency primitive.
It definitely has right to be part of "language for concurrency".
(ohhh, three lines of text w
Mutex needs not to be type-safe.
And Mutex is not part of concept of "language tailored towards concurrency".
But "future" is well known, widely adopted (though, in different ways)
concurrency primitive.
It definitely has right to be part of "language for concurrency".
(ohhh, three lines of text w
On Monday, 17 October 2016 09:15:33 UTC-4, Axel Wagner wrote:
>
> However, the compiler might be clever enough to optimize that out with
> inlining and escape analysis. And indeed, I'm failing to trigger the
> behavior with any simple testcase. So I might be wrong here. Would be
> interested in
On Sunday, 16 October 2016 08:40:32 UTC-4, Sokolov Yura wrote:
>
> "future" is commonly used synchronization abstraction.
>
> It could be implemented in a library, using mutex, channel and interface.
> Example:
> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
>
>
There is no semantic difference.
Disclaimer: On everything that follows, I'm not an expert (and it seems I'm
wrong. Not sure exactly how, though).
Though there *might* be a (*very*) slight advantage to using a struct{}.
All struct{}'s have the same address in gc, so if you put a struct{} into
an
On 17/10/16 23:09, Kiki Sugiaman wrote:
If N out of 4 error is not nil, N > 0, expect some performance hit from
reflection. If N == 0 (which should be most of the time), the code will
not touch reflection.
Sorry, I was referring to an earlier version that's still stuck in my
head. There's
On 16/10/16 23:48, antoniosun...@gmail.com wrote:
[snip]
The reason that I didn't do it, is because I don't know how to do it. In
essence, that "f.Close()" that you worried about is wrapped in "defer
f.Close()" in SaveState, which in turn wrapped in "defer SaveState" in a
function. I.e., all i
Thanks for confirming my suspicions.
I have a follow-up question, how can I instrument my go code so that I can
set the include path that is used to resolve '%include' statements in my
swig code. Currently I have relative paths in my swig file, and I would
like to put '/usr/include' on the sea
Is there a downside in using `xml.Encode` instead of `xml.EncodeElement`
when implementing the `xml.Marshaler` interface?
I see in the documentation:
Using start as the element tag is not required, but doing so will
enable Unmarshal to match the XML elements to the correct struct field.
Bu
Hi,
I noticed that when io.Discard was introduced in
https://codereview.appspot.com/4426066/, it replaced code like:
type devNull struct{}
With:
type devNull int
Both had the very same implementation of the Write method:
func (devNull) Write(p []byte) (int, os.Error) {
return len(
35 matches
Mail list logo
