On Sun, May 14, 2017 at 8:12 PM, andrey mirtchovski
wrote:
>
>> the pointer with the finalizer set on it is no longer referenced and the
>> finalizer is eligible to be run when the next GC occurs.
>
> should this constitute an error that requires a panic, or is this not
> panic-ing due to unsafe/
+ all
> the pointer with the finalizer set on it is no longer referenced and the
> finalizer is eligible to be run when the next GC occurs.
should this constitute an error that requires a panic, or is this not
panic-ing due to unsafe/cgo being in use?
--
You received this message because you a
macOS wants to do absolutely everything through their own dylib. it's
a way of keeping control of their ecosystem. they've gone to the
extent of disallowing you to compile statically linked binaries with
their libc. windows is a much more convenient beast in that respect.
On Sun, May 14, 2017 at 4
> > Is it possible to load a dylib without using cgo on macOS?
>
> Not to my knowledge.
>
Does anyone know the technical reason behind this?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
Logically it would be great if I had provided the URL...
https://github.com/luisfurquim/ugarit
Thank you all!
Em domingo, 14 de maio de 2017 17:49:44 UTC-3, Luis Furquim escreveu:
>
> Hello Gophers!
>
> I am publishing a first barely usable version of an EPub eBook generator.
> It still has man
Hello Gophers!
I am publishing a first barely usable version of an EPub eBook generator.
It still has many improvements to be done. Documentation is poor but
exists. There's an example in the epub30 package. Criticism would be a
great help. I know it has much to be done. So, please be gentle! ;)
Thank you so much, that solved our problem! :D
On Sunday, May 14, 2017 at 4:06:12 PM UTC-4, Kale B wrote:
>
> There's a finalizer being set on `*gmp.Int` when `SetString()` is called.
> Since `newnum` is a `gmp.Int` and not a `*gmp.Int` and `newnum` is copied
> into `output_array`, the pointer
There's a finalizer being set on `*gmp.Int` when `SetString()` is called.
Since `newnum` is a `gmp.Int` and not a `*gmp.Int` and `newnum` is copied
into `output_array`, the pointer with the finalizer set on it is no longer
referenced and the finalizer is eligible to be run when the next GC occurs.
Here is a test case below.
In short, it's appending the same number to an array, but after 2500 loops
or so the value changes.
package main
import (
"fmt"
"github.com/ncw/gmp"
// "math/big"
)
func test_gmp_array() {
index := 0
output_array := []gmp.Int{}
for index < 5000
In 1.8, database/sql added support for context cancellation on DB methods
(e.g. QueryContext, ExecContext, etc.). In the godoc, there is a note
stating that "Drivers that do not support context cancelation will not
return until after the query is completed." However, I have not been able
to fi
the comment was for libraries without context parameters but which would
need to have them added.
On Sun, May 14, 2017 at 11:46 AM, Sameer Ajmani wrote:
> Specifically: don't pass nil Contexts. They are not valid, and most code
> that uses Contexts don't check for nil and will panic.
>
> On Sun
Specifically: don't pass nil Contexts. They are not valid, and most code
that uses Contexts don't check for nil and will panic.
On Sun, May 14, 2017 at 11:43 AM Sameer Ajmani wrote:
> Generally I'd suggest passing context.Background() when calling functions
> that need a context from main or test
Generally I'd suggest passing context.Background() when calling functions
that need a context from main or tests.
On Sat, May 13, 2017 at 8:27 AM Peter Weinberger (温博格)
wrote:
> Hi. I was one of the people who failed in an attempt to auto-insert
> contexts in all of google3. I no longer remember
Sure, open an issue, I'll fix that
On Sunday, May 14, 2017 at 10:30:57 AM UTC+3, Frank Schröder wrote:
>
> It's not how other completions work, it's redundant and makes it harder to
> read.
>
> Frank Schröder
>
> > On 14. May 2017, at 09:04, Eyal Posener >
> wrote:
> >
> > currently all rela
Thanks for the suggestion but I'm afraid it didn't work. Any other ideas?
Nicholas Treleaven
-Original Message-
From: Ian Lance Taylor [mailto:i...@golang.org]
Sent: 14 May 2017 14:06
To: Nick Treleaven
Cc: golang-nuts
Subject: Re: [go-nuts] Problem compiling from source
On Sun, May 14
On Sun, May 14, 2017 at 5:56 AM, wrote:
>
> I am trying to compile go version 1.8.1 on a large Linux server that is
> shared with many other users.
>
> Bootstrapping of go1.4 is successful (but the testing fails for the same
> reason as below)
>
> ./all.bash fails for 1.8.1 with the following:
>
Hello,
I am trying to compile go version 1.8.1 on a large Linux server that is
shared with many other users.
Bootstrapping of go1.4 is successful (but the testing fails for the same
reason as below)
./all.bash fails for 1.8.1 with the following:
go build mime/quotedprintable: /compile: resour
On Sunday, May 14, 2017 at 4:01:26 AM UTC+2, Elise Xue wrote:
>
> We're using gmp (library found at https://github.com/ncw/gmp) to run on
> large inputs, and we have arrays with thousands of elements at a time in
> our code. When we write these arrays to files, we find that the values of
> som
looks awesome!!
In this,
https://github.com/posener/complete/blob/master/example/self/main.go
Just wonder why i can t simply do something similar to,
var name string
whatever.StringVar(&name, "name", "", "Give your name", complete.
PredictAnything)
if whatever.Run() {
return
}
Anyway, great s
If DoingStuff() panics, your file won't be closed.
On Wednesday, May 10, 2017 at 12:55:35 PM UTC-3, st ov wrote:
>
> Most examples of opening and closing a file have both calls in the same
> function
>
> func DoFileStuff() {
> file, _ := os.Open("file")
> defer file.Close()
>
> // do stuff
On Fri, May 12, 2017 at 7:54 AM, Nigel Tao wrote:
> On Fri, May 12, 2017 at 3:11 AM, anatoly techtonik
> wrote:
>> I am new to Go and I need a cross-platform value for keyboard key codes to
>> make sure I can react to user key presses regardless of operating system
>> layer.
>
> FYI, there's alr
It's not how other completions work, it's redundant and makes it harder to
read.
Frank Schröder
> On 14. May 2017, at 09:04, Eyal Posener wrote:
>
> currently all relative directories are completed with the `./` prefix, Does
> it make any problems?
--
You received this message because you
On Sunday, May 14, 2017 at 9:06:45 AM UTC+3, Frank Schröder wrote:
>
> I'll look into this. So far I've spent 30 min on this. :) which dir
> pattern should I use for directory completions so that the suggestions
> don't start with ./ ?
>
currently all relative directories are completed with th
23 matches
Mail list logo
