Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

On Tue, Apr 16, 2019 at 9:53 PM wrote: > > In a compiler, say during the lexing and parsing phases, memory might be > allocated > that won't be needed after those phases are complete. The memory is still > referenced, > so the GC won't free it, but conceptually it actually could be freed. In >

Re: [go-nuts] Re: fatal error: 'config.h' file not found

On Tue, Apr 16, 2019 at 9:56 PM Nitish Saboo wrote: > Hi, > > I am new to GO.Can I get little help on this ? > You sent your first message asking for help to a mailing list of random strangers ~10 hours ago. Obviously you are under some time pressure to solve this but it is a bit presumptive of

Re: [go-nuts] Re: fatal error: 'config.h' file not found

On Tue, Apr 16, 2019 at 9:56 PM Nitish Saboo wrote: > > I am new to GO.Can I get little help on this ? It's really hard to know what the answer is. One thing you can try is adding a #cgo CFLAGS line with a -I option pointing to your syslog-ng directory. See https://golang.org/cmd/cgo. Ian >

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

And yes, just nil the pointer to the head node and as long as the nodes are not referenced elsewhere the entire list will be collected. > On Apr 16, 2019, at 11:53 PM, jlforr...@berkeley.edu wrote: > > In a compiler, say during the lexing and parsing phases, memory might be > allocated > that

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

In the example you cite, in a properly written compiler that memory would no longer be referenced (unless it was needed later) - no need to manually clear all pointers - just the root references. I think you need more understanding of how to properly manage memory in a GC environment. > On

[go-nuts] Re: fatal error: 'config.h' file not found

Hi, I am new to GO.Can I get little help on this ? Thanks, Nitish On Wednesday, April 17, 2019 at 12:09:30 AM UTC+5:30, Nitish Saboo wrote: > > Hi, > > > I am using syslog-ng-3.6.2 ( >

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

In a compiler, say during the lexing and parsing phases, memory might be allocated that won't be needed after those phases are complete. The memory is still referenced, so the GC won't free it, but conceptually it actually could be freed. In other words, the fact that memory is referenced isn't

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

On Tue, Apr 16, 2019 at 9:48 PM Robert Engels wrote: > > I think the OP was implying that GC is inefficient and was inquiring about > certain patterns of memory use could be freed more efficiently. I see. I wouldn't worry about it, at least not without clear evidence of some problem. The cost

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

I think the OP was implying that GC is inefficient and was inquiring about certain patterns of memory use could be freed more efficiently. I think certain GC systems allow a region to be used to allocate objects then the region can be freed at once. Similar to the ongoing Java effort of a

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

On Tue, Apr 16, 2019 at 8:46 PM wrote: > > Go's garbage collector is very nice, and solves many problems that come up in > C programs. > > However, one thing I've been wondering about is explicitly freeing memory. I > know it can't be done > now, and that the GC takes care of everything. > >

Re: [go-nuts] Re: Should SIGTERM be included in the os package?

I think the docs on os.Signal explain it: The only signal values guaranteed to be present in the os package on all systems are os.Interrupt (send the process an interrupt) and os.Kill (force the process to exit). On Windows, sending os.Interrupt to a process with os.Process.Signal is not

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

Also, you can use manually managed memory in Go, it’s just not as simple as auto managed memory. > On Apr 16, 2019, at 10:46 PM, jlforr...@berkeley.edu wrote: > > Go's garbage collector is very nice, and solves many problems that come up in > C programs. > > However, one thing I've been

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

Many generational garbage collectors work based on that principle - that recently allocated objects are most likely to be garbage, so often they are freed in a single pass. Go doesn’t do this yet, but Go pointers coupled with value structures/slices can give similar performance for many types

[go-nuts] Current Thinking on Explicit Memory Freeing?

Go's garbage collector is very nice, and solves many problems that come up in C programs. However, one thing I've been wondering about is explicitly freeing memory. I know it can't be done now, and that the GC takes care of everything. But I was thinking about multi-pass programs like

[go-nuts] Re: Should SIGTERM be included in the os package?

As an alternative should the docs be updated to use the syscall package signals directly? https://godoc.org/os/signal#Notify Feels mildly strange intermixing vars from os and syscall where each has it's own distinct convention for the signal names. The two signals found in os follow the standard

[go-nuts] Should SIGTERM be included in the os package?

Hello, Currently the *os* package defines the following signals: var ( Interrupt Signal = syscall .SIGINT Kill Signal = syscall

[go-nuts] Re: Local Go module

You could put such packages at $GOPATH/src/local/name_of_package. This means that if I have a project that was using the specific project, the import would be as follows *import "local/name_of_package" * Although, if the package is available online (such as github), it is better to "install"

[go-nuts] Local Go module

Is there any way to install a package locally so that other projects can use it? In the gradle world, this is done using the "install" task. Joshua -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

[go-nuts] fatal error: 'config.h' file not found

Hi, I am using syslog-ng-3.6.2 ( https://src.fedoraproject.org/lookaside/pkgs/syslog-ng/syslog-ng_3.6.2.tar.gz/6928e9be3499a2e9ae52ea8aa204b165/ ). I want to use syslog-ng header files in my project. This is my repository : https://github.com/nitishsaboo/Testing syslog-node.c is a file where

[go-nuts] Re: The go way to compare values against an enum

Roger and Jan have given you good answers, but if you want to make use of an existing *small *package, check out https://github.com/suntong/enum On Monday, April 15, 2019 at 4:52:52 AM UTC-4, Sankar wrote: > > Hi, > > I have the following Go type. > > ``` > type weekday string > > const ( >

[go-nuts] Re: [ANN] Lightweight package for exposing application metrics in Prometheus format

On Tuesday, April 16, 2019 at 12:13:17 PM UTC-4, Aliaksandr Valialkin wrote: > > Hi all, > > I'm glad to announce a lightweight package for exposing application > metrics in Prometheus format - https://github.com/VictoriaMetrics/metrics > . > > The package provides the following most

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

Hey Rémy, If you have a chance, could you please try out this patch ? It's been known to help the other application Austin mentioned with virtual memory footprint and it should patch cleanly onto the go1.12. Let me know what you see! It'd help

Re: [go-nuts] Re: Language Specification nit under Constant declarations

* peterGo [190416 09:23]: > Marvin Renich, > > "I would interpret the phrase," "I think the phrase," and "I prefer" are > your personal interpretation, thoughts, and preference. Go prefers standard > interpretations: US words, spelling, grammar, and dictionaries. For example, Absolutely. My

Re: [go-nuts] floating point question

There are multiple bit-representations for NaN, so even then, you can't compare for equality. On Monday, 15 April 2019 12:59:28 UTC-4, David Riley wrote: > > On Apr 15, 2019, at 12:47 PM, Miki Tebeka > wrote: > > > > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: > > > >

[go-nuts] [ANN] Lightweight package for exposing application metrics in Prometheus format

Hi all, I'm glad to announce a lightweight package for exposing application metrics in Prometheus format - https://github.com/VictoriaMetrics/metrics . The package provides the following most frequently used metric types: - Counter - Gauge - Summary The metrics package has the following

Re: [go-nuts] floating point question

These "floating-point is weird" discussions tend to be unfair to the virtues of floating point. ;-) The numbers in computers are NOT the numbers of mathematics. They do not have the same properties, promises, and definitions. So instead of shaking our fists at the computer when we're reminded of

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

On Tue, Apr 16, 2019 at 1:23 AM Rémy Oudompheng wrote: > Thanks Austin, > > The application workload is a kind of fragmentation torture test as it > involves a mixture of many long-lived small and large (>100 MB) > objects, with regularly allocated short-lived small and large objects. > I have

Re: [go-nuts] floating point question

On Apr 16, 2019, at 2:29 AM, Miki Tebeka wrote: >> >> On Monday, April 15, 2019 at 7:59:28 PM UTC+3, David Riley wrote: >> On Apr 15, 2019, at 12:47 PM, Miki Tebeka wrote: >> > >> > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: >> > >> > 1.1*1.1 and 1.21 are untyped

[go-nuts] Re: Language Specification nit under Constant declarations

Marvin Renich, "I would interpret the phrase," "I think the phrase," and "I prefer" are your personal interpretation, thoughts, and preference. Go prefers standard interpretations: US words, spelling, grammar, and dictionaries. For example, Merriam-Webster Definition of preceding : existing,

Re: [go-nuts] floating point question

I came across this when teaching about floats not being exact, was surprised to see the "true" :) On Monday, April 15, 2019 at 7:59:28 PM UTC+3, David Riley wrote: > > On Apr 15, 2019, at 12:47 PM, Miki Tebeka > wrote: > > > > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: >

Re: [go-nuts] floating point question

Thanks! On Monday, April 15, 2019 at 7:51:05 PM UTC+3, Jan Mercl wrote: > > > > On Mon, Apr 15, 2019 at 6:47 PM Miki Tebeka > wrote: > > > Does that mean that the Go compiler is using floats with more precision > than the runtime? > > Absolutely: https://golang.org/ref/spec#Constants > >