I love this. I write some data analysis code and for ease of development
and speed I keep the tables I build in memory. Generating those tables
takes lots of memory and CPU, so I disabled the GC and manually run GC when
the runtime memory stats start to get close to the system limit. Seems to
be w
You must not set GOROOT when building from source. It is not necessary and will
lead to confusing error messages if you at GOROOT
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, s
yes; after the failed api check I issued 4 commands:
"go env"
"env | grep GO"
"which go"
"go -version"
output of those follow:
admin1@tp13:/csspc/etc$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/mnt/data1/admin1/gocode"
GORACE=""
GOROOT="/
Do you have GOROOT set? This error can occur when GOROOT is set incorrectly.
On Sunday, 29 January 2017 03:06:18 UTC+11, gocss wrote:
>
> building in xubuntu 16.04 LTS
>
> # API check
> stat /csspc/etc/go/src/cmd/api/run.go: no such file or directory
> 2017/01/28 10:51:46 Failed: exit status 1
There are a bunch of examples of where they are *useful* (some in this
thread). It's just, that you can not *rely* on them for correctness. If you
are setting a finalizer, because something needs to happen before some
value gets GCed/falls out of scope, you are doing it wrong, don't do it. If
you a
On Sun, Jan 29, 2017, 10:35 AM John Souvestre wrote:
> > If you find a piece of code that uses a finaliser for the correct
> operation of that program, that code is broken.
>
> Does that include using a finalizer with CGO code? From what I read, that
> seems to be where they are most often used
> If you find a piece of code that uses a finaliser for the correct operation
> of that program, that code is broken.
Does that include using a finalizer with CGO code? From what I read, that
seems to be where they are most often used.
> https://groups.google.com/forum/#!topic/golang-dev/DM
> If finalizers were indeed totally useless, it would obviously be totally
useless to implement support for them.
If someone described a few cases where finalizers were useful perhaps it would
help understand them.
John
John Souvestre - New Orleans LA
--
You received this message becaus
If you find a piece of code that uses a finaliser for the correct operation of
that program, that code is broken.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
* Will Faught [170127 21:58]:
> Variable shadowing is rarely, if ever, a problem for me too; but what about
> for newcomers?
>
> I think my copy/paste point stands, though; everyone has those problems, at
> least occasionally.
I agree with you. See my earlier post for my reasoning:
https://gro
On Sunday, January 29, 2017 at 1:04:35 AM UTC+8, Axel Wagner wrote:
>
> On Sat, Jan 28, 2017 at 4:05 PM, T L >
> wrote:
>
>>
>>
>> On Saturday, January 28, 2017 at 10:46:50 PM UTC+8, Dave Cheney wrote:
>>>
>>>
>>>
>>> On Sunday, 29 January 2017 01:42:08 UTC+11, T L wrote:
On
On Sat, Jan 28, 2017 at 4:05 PM, T L wrote:
>
>
> On Saturday, January 28, 2017 at 10:46:50 PM UTC+8, Dave Cheney wrote:
>>
>>
>>
>> On Sunday, 29 January 2017 01:42:08 UTC+11, T L wrote:
>>>
>>>
>>>
>>> On Saturday, January 28, 2017 at 10:33:08 PM UTC+8, Dave Cheney wrote:
On
building in xubuntu 16.04 LTS
# API check
stat /csspc/etc/go/src/cmd/api/run.go: no such file or directory
2017/01/28 10:51:46 Failed: exit status 1
2017/01/28 10:51:46 FAILED
doing an ls of above directory:
admin1@tp13:/csspc/etc/go/src$ ls /csspc/etc/go/src/cmd/api
ls: cannot access '/csspc
On Sat, 28 Jan 2017 07:05:13 -0800 (PST)
T L wrote:
[...]
> My understanding is finalisers are guaranteed to run for some cases,
> but not for some other cases, for a long running program.
> If any cases are not guaranteed to run, then SetFinalizer would be
> totally useless.
[...]
Many of your
On Saturday, January 28, 2017 at 10:46:50 PM UTC+8, Dave Cheney wrote:
>
>
>
> On Sunday, 29 January 2017 01:42:08 UTC+11, T L wrote:
>>
>>
>>
>> On Saturday, January 28, 2017 at 10:33:08 PM UTC+8, Dave Cheney wrote:
>>>
>>>
>>>
>>> On Sunday, 29 January 2017 01:25:20 UTC+11, T L wrote:
On Sunday, 29 January 2017 01:42:08 UTC+11, T L wrote:
>
>
>
> On Saturday, January 28, 2017 at 10:33:08 PM UTC+8, Dave Cheney wrote:
>>
>>
>>
>> On Sunday, 29 January 2017 01:25:20 UTC+11, T L wrote:
>>>
>>>
>>>
>>> On Saturday, January 28, 2017 at 9:33:51 PM UTC+8, C Banning wrote:
Fr
On Saturday, January 28, 2017 at 10:33:08 PM UTC+8, Dave Cheney wrote:
>
>
>
> On Sunday, 29 January 2017 01:25:20 UTC+11, T L wrote:
>>
>>
>>
>> On Saturday, January 28, 2017 at 9:33:51 PM UTC+8, C Banning wrote:
>>>
>>> From the doc: "The finalizer for obj is scheduled to run at some
>>> arbit
On Saturday, January 28, 2017 at 10:25:20 PM UTC+8, T L wrote:
>
>
>
> On Saturday, January 28, 2017 at 9:33:51 PM UTC+8, C Banning wrote:
>>
>> From the doc: "The finalizer for obj is scheduled to run at some
>> arbitrary time after obj becomes unreachable. There is no guarantee that
>> finali
On Sunday, 29 January 2017 01:25:20 UTC+11, T L wrote:
>
>
>
> On Saturday, January 28, 2017 at 9:33:51 PM UTC+8, C Banning wrote:
>>
>> From the doc: "The finalizer for obj is scheduled to run at some
>> arbitrary time after obj becomes unreachable. There is no guarantee that
>> finalizers wil
On Saturday, January 28, 2017 at 9:33:51 PM UTC+8, C Banning wrote:
>
> From the doc: "The finalizer for obj is scheduled to run at some
> arbitrary time after obj becomes unreachable. There is no guarantee that
> finalizers will run before a program exits, so typically they are useful
> only
On Saturday, January 28, 2017 at 9:33:51 PM UTC+8, C Banning wrote:
>
> From the doc: "The finalizer for obj is scheduled to run at some
> arbitrary time after obj becomes unreachable. There is no guarantee that
> finalizers will run before a program exits, so typically they are useful
> only
>From the doc: "The finalizer for obj is scheduled to run at some arbitrary
time after obj becomes unreachable. There is no guarantee that finalizers
will run before a program exits, so typically they are useful only for
releasing non-memory resources associated with an object during a
long-run
package main
import "time"
import "runtime"
type T1 struct{ i int }
type T2 struct{ i int }
func main() {
t1 := new(T1)
t2 := new(T2)
runtime.SetFinalizer(t1, func(*T1) {println(1)})
runtime.SetFinalizer(t2, func(*T2) {println(2)})
runtime.GC()
package main
import "time"
import "runtime"
type T1 struct{ i int }
type T2 struct{ i int }
func main() {
t1 := new(T1)
t2 := new(T2)
runtime.SetFinalizer(t1, func(*T1) {println(1)})
runtime.SetFinalizer(t2, func(*T2) {println(2)})
runtime.GC()
24 matches
Mail list logo
