Re: [go-nuts] What is recommended way to initialize and keep prepared statements in go Lang

[roger peppe]

The way I've been doing this recently is to write two methods for each
statement, one to prepare it and one to use it.
That way the SQL code sits next to the Exec or Query statement that uses
it, making it easier to understand what's going on.

Here's some example code showing the way we've been structuring this. It
would normally be split across several files (I've left comments where I'd
split it).

https://play.golang.org/p/fh9b7loZkLJ

It's a little tedious to do this, but eliminates a few common sources of
errors, and ends up quite readable IMHO.

Hope this helps,

  rog.


On Sat, 13 Apr 2019 at 18:58,  wrote:

> Hi Team ,
> I am new in go lang ,I want to know is there any recommended way in go
> lang to create prepare statement in go lang on application start and pass
> it to multiple http handler so that query can be done inside those http
> handlers.
>
> --
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[peterGo]

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, coming, or occurring immediately before in time or place
// preceding paragraphs
https://www.merriam-webster.com/dictionary/preceding

The Go Programming Language Specification
Constant declarations 
https://golang.org/ref/spec#Constant_declarations

"Within a parenthesized const declaration list the expression list may be 
omitted from any but the first ConstSpec. Such an empty list is equivalent 
to the textual substitution of the first preceding non-empty expression 
list and its type if any. Omitting the list of expressions is therefore 
equivalent to repeating the previous list." 

Using the Merriam-Webster definition, the meaning seems reasonably clear. 
For standardization and clarity, I would prefer that 'first preceding' be 
"immediately preceding."


Google Search

immediately+preceding: About 6,000,000 results
https://www.google.com/search?q="immediately+preceding";

first+preceding: About 52,000 results
https://www.google.com/search?q="first+preceding";


Google Books Ngram Viewer

immediately+preceding: 0.995521%
https://books.google.com/ngrams/graph?content=immediately+preceding&year_start=1800&year_end=2000&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Cimmediately%20preceding%3B%2Cc0

first+preceding: 0.004863%
https://books.google.com/ngrams/graph?content=first+preceding&year_start=1800&year_end=2000&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Cfirst%20preceding%3B%2Cc0

last+preceding: 0.041926%
https://books.google.com/ngrams/graph?content=last+preceding&year_start=1800&year_end=2000&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Clast%20preceding%3B%2Cc0#t1%3B%2Clast%20preceding%3B%2Cc0

most+recent+preceding: 0.001958%
https://books.google.com/ngrams/graph?content=most+recent+preceding&year_start=1800&year_end=2000&corpus=15&smoothing=3&share=&direct_url=t1%3B%2Cmost%20recent%20preceding%3B%2Cc0


Peter


On Monday, April 15, 2019 at 12:28:08 PM UTC-4, Marvin Renich wrote:
>
> At https://golang.org/ref/spec#Constant_declarations where it talks 
> about omitting the expression list, it says 
>
>   Such an empty list is equivalent to the textual substitution of the 
>   first preceding non-empty expression list and its type if any. 
>
> In the declaration 
>
> const ( 
> One = iota 
> Two = 2 
> Three 
> ) 
>
> I would interpret the phrase "first preceding" in the spec as meaning "= 
> iota", when it is really means "= 2".  Both "= iota" and "= 2" are 
> preceding non-empty expressions, and "= iota" is the first.  I think the 
> phrase should be changed to "most recent preceding" or "last preceding" 
> (I prefer "most recent"). 
>
> ...Marvin 
>
>

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] floating point question

[David Riley]

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 constants and have much higher precision at 
>> > which they are not equal. 
>> > Does that mean that the Go compiler is using floats with more precision 
>> > than the runtime? 
>> 
>> Yes, but it's also worth remembering that in general, in computing, it's not 
>> a great idea to compare floats for absolute equality except for specific 
>> constants (e.g. +/- zero, +/- infinity, NaN). 
>> 
>> Is there an in-built intrinsic in Go for comparing floats within an epsilon, 
>> or does that have to be done manually? 
> 
> I came across this when teaching about floats not being exact, was surprised 
> to see the "true" :)

Yup! My personal perspective is that it's best to treat floating point numbers 
as "noisy", because you lose or add little bits to them with most operations in 
ways that are hard to control (this is one of the reasons IEEE floating point 
numbers have tightly-defined characteristics, because then at least the flaws 
are well-defined and you don't get e.g. diverging results in physics 
simulations on different machines because they round differently).

Treat a floating point number as a noisy signal, always compare within ranges 
(often enough, even when comparing against zero, especially considering that 
there is also a *negative* zero in floats) and you won't go wrong.  Well, not 
*very* wrong.  Better yet, avoid use of floating point arithmetic where at all 
possible (but here I'm showing my personal biases).


- Dave

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['Austin Clements' via golang-nuts]

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 tried creating a sample synthetic reproducer but did not
> succeed at the moment.
>
> Regarding the max_map_count, your explanation is very clear and I
> apparently missed the large comment in the runtime explaining all of
> that.
> Do you expect a significant drawback between choosing 2MB or 16MB as
> the granularity of the huge page flag manipulation in the case of huge
> heaps ?
>

Most likely this will just cause less use of huge pages in your
application. This could slow it down by putting more pressure on the TLB.
In a sense, this is a self-compounding issue since huge pages can be highly
beneficial to huge heaps.

Regarding the virtual memory footprint, it changed radically with Go
> 1.12. It basically looks like a leak and I saw it grow to more than
> 1TB where the actual heap total size never exceeds 180GB.
> Although I understand that it is easy to construct a situation where
> there is repeatedly no available contiguous interval of >100MB in the
> address space, it is a significant difference from Go 1.11 where the
> address space would grow to 400-500GB for a similar workload and stay
> flat after that, and I could not find an obvious change in the
> allocator explaining the phenomenon (and unfortunately my resources do
> not allow for an easy live comparison of both program lifetimes).
>
> Am I right saying that scavenging method or frequency does not
> (cannot) affect at all virtual memory footprint and dynamics ?
>

It certainly can affect virtual memory footprint because of how scavenging
affects the allocator's placement policy. Though even with the increased
VSS, I would expect your application to have lower RSS with 1.12. In almost
all cases, lower RSS with higher VSS is a fine trade-off, though lower RSS
with the same VSS would obviously be better. But it can be problematic when
it causes the map count (which is roughly proportional to the VSS) to grow
too large. It's also unfortunate that Linux even has this limit; it's the
only OS Go runs on that limits the map count.

We've seen one other application experience VSS growth with the 1.12
changes, and it does seem to require a pretty unique allocation pattern.
Michael (cc'd) may be zeroing in on the causes of this and may have some
patches for you to try if you don't mind. :)

Regards,
> Rémy.
>
> Le mar. 2 avr. 2019 à 16:15, Austin Clements  a écrit :
> >
> > Hi Rémy. We often fight with vm.max_map_count in the runtime, sadly.
> Most likely this comes from the way the runtime interacts with Linux's
> transparent huge page support. When we scavenge (release to the OS) only
> part of a huge page, we tell the OS not to turn that huge page frame back
> into a huge page since that would just make that memory used again.
> Unfortunately, each time we do this counts as a separate "mapping" just to
> track that one flag. These "mappings" are always at least 2MB, but you have
> a large enough virtual address space to reach the max_map_count even then.
> You can see this in /proc/PID/smaps, which should list mostly contiguous
> neighboring regions that differ only in a single "VmFlags" bit.
> >
> > We did make memory scavenging more aggressive in Go 1.12 (+Michael
> Knyszek), though I would have expected it to converge to roughly the same
> "huge page flag fragmentation" as before over the course of five to ten
> minutes. Is your application's virtual memory footprint the same between
> 1.11 and 1.12 or do that grow?
> >
> > You could try disabling the huge page flag manipulation to confirm
> and/or fix this. In $GOROOT/src/runtime/internal/sys/arch_amd64.go (or
> whichever GOARCH is appropriate), set HugePageSize to 0. Though there's a
> danger that Linux's transparent huge pages could blow up your application's
> resident set size if you do that.
> >
> > On Tue, Apr 2, 2019 at 3:49 AM Rémy Oudompheng 
> wrote:
> >>
> >> Hello,
> >>
> >> In a large heap program I am working on, I noticed a peculiar change in
> the way virtual memory is reserved by the runtime : with comparable heap
> size (about 150GB) and virtual memory size (growing to 400-500GB probably
> due to a kind of fragmentation), the number of distinct memory mappings has
> apparently increased between Go 1.11 and Go 1.12 reaching the system limit
> (Linux setting vm.max_map_count).
> >>
> >> Is it something that has been experienced by someone else ? I don't
> believe this classifies as a bug, but I was a bit surprised (especially as
> I wasn't aware of that system limit).
> >>
> >> Rémy
> >>
> >> --
> >> 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 go

Re: [go-nuts] floating point question

[Michael Jones]

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 the difference, why not
accept the difference and use what is provided?

Acceptance #1: Floating point values are actually binary integers.

While the "floating" aspect means scaling a range of integers over a wide
range via a separate exponent, the mantissa part (the fraction) is still a
binary integer interpreted as the numerator of a rational number, the
denominator being 2^n where n varies of course between 32-bit and 64-bit
floating point, with n=52 for the "double precision" 64-bit case. The n
here determines the number of values that are expressible perfectly as
scaled integers (2^52 of them).

In particular, when expressing a floating point value the compiler and
computer must find the closest power-of-two fraction to your number:
1.0/2.0 => 2^51 / 2^52, for example and this is an ideal representation.
Unfortunately, a value like 1.0/3.0 (or 1.21 == 121/100 in the original
question) is impossible to represent a n/d, d=2^k for any k. That is
because 2^k is not divisible by 3 and neither is 2^k divisible by 121.

We accept this about time. "I'll see you in a 7th of an hour" is a
reasonable notion, but it is not expressible in seconds. It is more than 8
seconds, but less than 9 seconds.(t=8.5714285714... seconds) Now if we
agree to pretend that this floating point value is the time we mean, it
will all work out, unless someone peeks under the hood at the details by
asking "why is 7-1/t not equal to zero but instead 3.469446952E-18?" ;-)

When they do, it's ok. It just means that we're all observing the measure
of the distance between the desired value and the nearest fraction with
2^52 as the denominator. it is all ok. Just remember they're not the
numbers of algebra.


On Tue, Apr 16, 2019 at 6:40 AM David Riley  wrote:

> 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 constants and have much higher precision
> at which they are not equal.
> >> > Does that mean that the Go compiler is using floats with more
> precision than the runtime?
> >>
> >> Yes, but it's also worth remembering that in general, in computing,
> it's not a great idea to compare floats for absolute equality except for
> specific constants (e.g. +/- zero, +/- infinity, NaN).
> >>
> >> Is there an in-built intrinsic in Go for comparing floats within an
> epsilon, or does that have to be done manually?
> >
> > I came across this when teaching about floats not being exact, was
> surprised to see the "true" :)
>
> Yup! My personal perspective is that it's best to treat floating point
> numbers as "noisy", because you lose or add little bits to them with most
> operations in ways that are hard to control (this is one of the reasons
> IEEE floating point numbers have tightly-defined characteristics, because
> then at least the flaws are well-defined and you don't get e.g. diverging
> results in physics simulations on different machines because they round
> differently).
>
> Treat a floating point number as a noisy signal, always compare within
> ranges (often enough, even when comparing against zero, especially
> considering that there is also a *negative* zero in floats) and you won't
> go wrong.  Well, not *very* wrong.  Better yet, avoid use of floating point
> arithmetic where at all possible (but here I'm showing my personal biases).
>
>
> - Dave
>
> --
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Aliaksandr Valialkin]

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 features:
- it provides clear API 
, which is much easier 
to use comparing to the official Prometheus package for exporting 
application metrics - github.com/prometheus/client_golang 
 .
- it has much smaller dependencies comparing to 
github.com/prometheus/client_golang 
 , so it compiles 
quicker to a smaller binary code.
- it is optimized for speed.

The github.com/VictoriaMetrics/metrics has been extracted from 
VictoriaMetrics 

.

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] floating point question

[Robert Johnstone]

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: 
> > 
> > 1.1*1.1 and 1.21 are untyped constants and have much higher precision at 
> which they are not equal. 
> > Does that mean that the Go compiler is using floats with more precision 
> than the runtime? 
>
> Yes, but it's also worth remembering that in general, in computing, it's 
> not a great idea to compare floats for absolute equality except for 
> specific constants (e.g. +/- zero, +/- infinity, NaN). 
>
> Is there an in-built intrinsic in Go for comparing floats within an 
> epsilon, or does that have to be done manually? 
>
>
> - Dave 
>
>

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Marvin Renich]

* 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 point was that the definition of "first preceding" is
ambiguous.  Actually, I would replace "standard" with "precise,
unambiguous".  I do agree that we want to use words and phrases that are
well-defined and, hopefully, well-known.

> Merriam-Webster
> Definition of preceding
> : existing, coming, or occurring immediately before in time or place
> // preceding paragraphs
> https://www.merriam-webster.com/dictionary/preceding
> 
> Using the Merriam-Webster definition, the meaning seems reasonably clear. 

I disagree.  It defines "preceding", but says nothing about the order of
multiple items which are all preceding a single item.

I also disagree with the word "immediately" in that definition.  My
paper copy of "Webster's II New Riverside University Dictionary" C 1988,
gives this definition:

Existing or coming before in time, place, rank, or sequence :
PREVIOUS

"Preceding" may sometimes have an "immediate" connotation, but that is
not an integral part of the word's definition.

> For standardization and clarity, I would prefer that 'first preceding' be 
> "immediately preceding."

I wholeheartedly agree that "immediately" is an improvement over
"first", and I would be happy with this change, but I still think "most
recent preceding" is more precise and not subject to being
misinterpreted.  "Immediately preceding" might cause some confusion
here:

const (
Jan = iota
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
)

There is no "immediately preceding non-empty expression list" for Dec;
the only thing immediately preceding is "Nov".  The "= iota" is not, by
my estimation, immediately preceding; there are 10 lines of code in
between!

> Google Search
> 
> immediately+preceding: About 6,000,000 results
> 
> first+preceding: About 52,000 results

This is evidence that "first preceding" is not nearly as popular as
"immediately preceding".  It does not, however, say anything about
correctness or preciseness.

> Google Books Ngram Viewer
> 
> immediately+preceding: 0.995521%
> 
> first+preceding: 0.004863%
> 
> last+preceding: 0.041926%
> 
> most+recent+preceding: 0.001958%

This shows popularity in an extremely broad range of books, very likely
swamped with fiction (I don't know what books are searched by those
queries).  We are trying to find an expression that unambiguously
defines the behavior of a particular aspect of the Go language.  Most
authors of fiction are not concerned with making their work of art be as
precise as a computer language specification.

...Marvin

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['Michael Knyszek' via golang-nuts]

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 us to confirm the root cause of the VSS growth.

Thanks,
Michael

On Tue, Apr 16, 2019 at 11:03 AM Austin Clements  wrote:

> 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 tried creating a sample synthetic reproducer but did not
>> succeed at the moment.
>>
>> Regarding the max_map_count, your explanation is very clear and I
>> apparently missed the large comment in the runtime explaining all of
>> that.
>> Do you expect a significant drawback between choosing 2MB or 16MB as
>> the granularity of the huge page flag manipulation in the case of huge
>> heaps ?
>>
>
> Most likely this will just cause less use of huge pages in your
> application. This could slow it down by putting more pressure on the TLB.
> In a sense, this is a self-compounding issue since huge pages can be highly
> beneficial to huge heaps.
>
> Regarding the virtual memory footprint, it changed radically with Go
>> 1.12. It basically looks like a leak and I saw it grow to more than
>> 1TB where the actual heap total size never exceeds 180GB.
>> Although I understand that it is easy to construct a situation where
>> there is repeatedly no available contiguous interval of >100MB in the
>> address space, it is a significant difference from Go 1.11 where the
>> address space would grow to 400-500GB for a similar workload and stay
>> flat after that, and I could not find an obvious change in the
>> allocator explaining the phenomenon (and unfortunately my resources do
>> not allow for an easy live comparison of both program lifetimes).
>>
>> Am I right saying that scavenging method or frequency does not
>> (cannot) affect at all virtual memory footprint and dynamics ?
>>
>
> It certainly can affect virtual memory footprint because of how scavenging
> affects the allocator's placement policy. Though even with the increased
> VSS, I would expect your application to have lower RSS with 1.12. In almost
> all cases, lower RSS with higher VSS is a fine trade-off, though lower RSS
> with the same VSS would obviously be better. But it can be problematic when
> it causes the map count (which is roughly proportional to the VSS) to grow
> too large. It's also unfortunate that Linux even has this limit; it's the
> only OS Go runs on that limits the map count.
>
> We've seen one other application experience VSS growth with the 1.12
> changes, and it does seem to require a pretty unique allocation pattern.
> Michael (cc'd) may be zeroing in on the causes of this and may have some
> patches for you to try if you don't mind. :)
>
> Regards,
>> Rémy.
>>
>> Le mar. 2 avr. 2019 à 16:15, Austin Clements  a écrit
>> :
>> >
>> > Hi Rémy. We often fight with vm.max_map_count in the runtime, sadly.
>> Most likely this comes from the way the runtime interacts with Linux's
>> transparent huge page support. When we scavenge (release to the OS) only
>> part of a huge page, we tell the OS not to turn that huge page frame back
>> into a huge page since that would just make that memory used again.
>> Unfortunately, each time we do this counts as a separate "mapping" just to
>> track that one flag. These "mappings" are always at least 2MB, but you have
>> a large enough virtual address space to reach the max_map_count even then.
>> You can see this in /proc/PID/smaps, which should list mostly contiguous
>> neighboring regions that differ only in a single "VmFlags" bit.
>> >
>> > We did make memory scavenging more aggressive in Go 1.12 (+Michael
>> Knyszek), though I would have expected it to converge to roughly the same
>> "huge page flag fragmentation" as before over the course of five to ten
>> minutes. Is your application's virtual memory footprint the same between
>> 1.11 and 1.12 or do that grow?
>> >
>> > You could try disabling the huge page flag manipulation to confirm
>> and/or fix this. In $GOROOT/src/runtime/internal/sys/arch_amd64.go (or
>> whichever GOARCH is appropriate), set HugePageSize to 0. Though there's a
>> danger that Linux's transparent huge pages could blow up your application's
>> resident set size if you do that.
>> >
>> > On Tue, Apr 2, 2019 at 3:49 AM Rémy Oudompheng <
>> remyoudomph...@gmail.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> In a large heap program I am working on, I noticed a peculiar change
>> in the way virtual memory is reserved by the runtime : with comparable heap
>> size (about 150GB) and virtual memory size (growing to 400-500GB probably
>> due to a kind of fragmentation), the number 

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

[Tong Sun]

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 frequently used metric types:
> - Counter
> - Gauge
> - Summary
>
> The metrics package has the following features:
> - it provides clear API 
> , which is much 
> easier to use comparing to the official Prometheus package for exporting 
> application metrics - github.com/prometheus/client_golang 
>  .
> - it has much smaller dependencies comparing to 
> github.com/prometheus/client_golang 
>  , so it compiles 
> quicker to a smaller binary code.
> - it is optimized for speed.
>
> The github.com/VictoriaMetrics/metrics has been extracted from 
> VictoriaMetrics 
> 
> .
>

well done,  thx!

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tong Sun]

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 (
>   Monday weekday = "Monday"
>   Tuesday = "Tuesday"
>   .
>   .
>   .
> )
> ```
>
> Now I have a function that receives a string parameter and I want to 
> evaluate if it s a valid weekday or not. Say:
>
> ```
> func handler(w http.ResponseWriter, r *http.Request) {
>
> // Parse req.body and get a day string
>
> day := "Tuesday" // Valid day
> day := "tuesday" // Invalid day
> day := "123819283" // Invalid day
>
> }
> ```
>
> I want to evaluate if the string variable `day` is one of the valid 
> permitted values for the [Ww]eekday custom type. What is the recommended / 
> right go way of doing this ?
>
> Thanks.
>

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Nitish Saboo]

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 I am using syslog-ng's header files.
The match function in 'syslog-node.c' is being called from 'main.go' file.


When I run 'go build'  it fails with the following error:


# forgithub
syslog-node.c:2:10: fatal error: config.h: No such file or directory
 #include "config.h"
  ^~
compilation terminated.


However, 'config.h' file is present in my syslog-ng-3.6.2 directory where 
main.go is present but it is still not able to find 'config.h'.


nitish@nitish-VirtualBox:~/Documents/goworkspace/src/forgithub$ ls
common.gypi syslog-ng-3.13.2 syslog-node.c
depssyslog-ng-3.13.2.tar.gz  syslog-node.gyp
eventlog-0.2.13 syslog-ng-3.6.2  syslog-node.h
eventlog_0.2.13.tar.gz  syslog-ng_3.6.2.tar.gz
main.go 


nitish@nitish-VirtualBox:~$ cd Documents/goworkspace/src/
forgithub/syslog-ng-3.6.2/


nitish@nitish-VirtualBox:~/Documents/goworkspace/src/forgithub/syslog-ng-3.6.2$ 
ls
aclocal.m4 CONTRIBUTING.md  m4   syslog-ng
AUTHORSCOPYING  Makefile syslog-ng-ctl
autogen.sh debian   Makefile.am  syslog-ng.pc
compiledepcomp  Makefile.in  syslog-ng.pc.in
config.guess   dist.confmissing  syslog-ng.spec
config.h   dist.conf.in Mk   syslog-ng.spec.in
config.h.indoc  modules  test-driver
config.log INSTALL  NEWS.md  tests
config.status  install-sh   pkg-config-0.29  tgz2build
config.sub lib  pkgconfig.tgzVERSION
configure  libtest  scl  ylwrap
configure.ac   libtool  scripts
contribltmain.shstamp-h1


go build -x 

=



WORK=/tmp/go-build995828799
mkdir -p $WORK/b001/
cd /home/nitish/Documents/goworkspace/src/forgithub
CGO_LDFLAGS='"-g" "-O2"' /usr/local/go/pkg/tool/linux_amd64/cgo -objdir 
$WORK/b001/ -importpath forgithub -- -I $WORK/b001/ -g -O2 -I 
./syslog-ng-3.6.2/include ./main.go
cd $WORK
gcc -fno-caret-diagnostics -c -x c - || true
gcc -Qunused-arguments -c -x c - || true
gcc -fdebug-prefix-map=a=b -c -x c - || true
gcc -gno-record-gcc-switches -c -x c - || true
cd $WORK/b001
TERM='dumb' gcc -I /home/nitish/Documents/goworkspace/src/forgithub -fPIC 
-m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build 
-gno-record-gcc-switches -I ./ -g -O2 -I /home/nitish/Documents/
goworkspace/src/forgithub/syslog-ng-3.6.2/include -o ./_x001.o -c 
_cgo_export.c
TERM='dumb' gcc -I /home/nitish/Documents/goworkspace/src/forgithub -fPIC 
-m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build 
-gno-record-gcc-switches -I ./ -g -O2 -I /home/nitish/Documents/
goworkspace/src/forgithub/syslog-ng-3.6.2/include -o ./_x002.o -c 
main.cgo2.c
cd /home/nitish/Documents/goworkspace/src/forgithub
TERM='dumb' gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I 
$WORK/b001/ -g -O2 -I ./syslog-ng-3.6.2/include -o $WORK/b001/_x003.o -c 
syslog-node.c
# forgithub
syslog-node.c:2:10: fatal error: config.h: No such file or directory
 #include "config.h"
  ^~
compilation terminated.


1)Do you think there is some issue with the GO code where I need to add 
some flags to point it to the config.h?

2)Can you please guide me in the right direction to fix compilation issue, 
as in where am i missing the piece of link ?


Thanks,

Nitish




-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] SHA256 with input not aligned to x8 bit

[Skip Tavakkolian]

should this be entered into issue tracker?


On Mon, Apr 15, 2019 at 11:38 PM roger peppe  wrote:

> Yes, you're right. As I said, my solution won't work if you need to
> interoperate with other implementations.
>
> It's interesting that the SHA256 standard is defined to work on an number
> of bits though. I wasn't aware of that.
>
> I had a look around and I didn't find any other language's SHA256
> implementation that allows input which isn't a multiple of 8 bits. Are you
> aware of one? Which implementation are you needing to interoperate with
> that does allow this?
>
> ISTM that if you do require this, it wouldn't be too hard to copy the
> existing implementation and change the digest.checkSum method so that it
> could pad from an arbitrary number of bits.
>
>   cheers,
> rog.
>
>
> On Mon, 15 Apr 2019 at 20:52, Paolo C.  wrote:
>
>> Thanks Rog for the answer.
>> But that won't work.
>> SHA-256 is a standard (FIPS180-4) and if one uses it, is for interoperate
>> in most cases.
>> It may happen that you need only to hash 8bit bounded streams, but it
>> also may not be the case. So, any implementation should be careful of being
>> correct.
>> You example is flawed for the reason the if you WRAP the original
>> algorithm, it will anyway 'Finalize' your input padding it again (look at
>> the Sha256 code), so, the checksum that you will obtain will not match with
>> the one of some who has correctly implemented the standard.
>> On the other hand, if your example worked, it would mean that for each
>> 'odd bitted' stream (i.e. 12 bits) there is a sequence that can be
>> deterministically calculated adding a couple of bytes that has the same
>> sha256. This would the demonstration that sha256 is broken.
>> To obtain a correct implementation you should grab the sha256.go code and
>> bring into your own package correcting the limitation, but this has the
>> problem of the usage of some internal packages, which in turn complicates
>> everything. And also change the interface hash.Hash to let it be usable in
>> hmac, for example.
>> Anyway, don't let me be misunderstood, I can live with it, simply I
>> trusted the package declaration
>>
>> // Package sha256 implements the SHA224 and SHA256 hash algorithms as defined
>>
>> // in FIPS 180-4.
>>
>> that revealed partially true. Technically speaking it's not a BUG, because 
>> since I can NOT input spare bits, I will never obtain wrong results. But for 
>> sure it's not a full and correct implementation.
>>
>> Paolo
>>
>> On Monday, April 15, 2019 at 11:48:23 AM UTC+2, rog wrote:
>>>
>>> The answer depends on what why you want to do this. If you don't need to
>>> interoperate with some other party that needs to arrive at the same
>>> checksum, you could write your own wrapper around sha256 that adds the
>>> necessary information to specify how many bits are significant. Something
>>> like this, perhaps:
>>>
>>> // hashBits returns a hash of the first nbits bits of b,
>>> // starting at the most significant bit of the first
>>> // byte of b.
>>> //
>>> // So hashBits([]byte{0x5a, 0xbc, 0xde}, 12) would
>>> // hash 0x5ab, ignoring the final 0xcde.
>>> //
>>> // It works by hashing an extra 2 bytes that encode
>>> // the final bits and how many there are.
>>> //
>>> // hashBits will panic if nbits is greater than len(b) * 8.
>>> func hashBits(b []byte, nbits int) [sha256.Size]byte {
>>> oddBits := nbits & 7
>>> blen := nbits >> 3
>>> b1 := make([]byte, blen+2)
>>> copy(b1, b[0:blen])
>>> if oddBits > 0 {
>>> b1[blen] = b[blen] & ^(0xff >> uint(oddBits))
>>> b1[blen+1] = byte(oddBits)
>>> }
>>> return sha256.Sum256(b1)
>>> }
>>>
>>> Note that the code above is almost untested, and there are probably more
>>> standard ways to do it - that was just the first thing that came into my
>>> head.
>>>
>>>   cheers,
>>> rog.
>>>
>>> On Sun, 14 Apr 2019 at 22:02, Paolo C.  wrote:
>>>
 SHA256 (SHA in general) has a precise behavior if you wanna hash a
 number of bits not multiple of the block (512bit)
 Sha256.go handle this correcty ONLY in the case that you input is at
 least multiple of 8 bits.
 If you wanna hash, say, 20bit (0xABCDE) you cannot obtain a correct
 result.
 Note that Sha256(0xABCDE) is (See FIPS and NIST publications) not the
 same of Sha256 of 0x0ABCDE o 0xABCDE0.
 Any idea or any implementation available on the web?
 A .Write(data []byte, effectciveLenInBits int) would be required, while
 today Write([]byte) assumes that each bit of the last byte is meaningful
 and to be hashed

 Thanks,

 Paolo

 --
 You received this message because you are subscribed to the Google
 Groups "golang-nuts" group.
 To unsubscribe f

[go-nuts] Local Go module

[Joshua]

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 receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Local Go module

[vaastav anand]

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" such packages using the 'go get' command. This way the package 
automatically ends up in your GOPATH.

On Tuesday, 16 April 2019 17:13:09 UTC-7, Joshua wrote:
>
> 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 receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Nathan Fisher]

Hello,

Currently the *os* package defines the following signals:

var (
Interrupt Signal  = syscall
.SIGINT 
Kill  Signal  = syscall
.SIGKILL

)

Would it make sense to include a Term signal as well or were these signals
considered historical accidents?

My argument for including Term/SIGTERM is that it's used to notify pods of
imminent shutdown in kubernetes.

While it's simple enough to add a var to my app it feels unnecessary for
something that seems an increasingly common signal to handle.

Thoughts?

Kind regards,
-- 
Nathan Fisher
 w: http://junctionbox.ca/

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Nathan Fisher]

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 convention for variable
names (e.g. Interrupt). Whereas the syscall package uses a convention more
akin to C (e.g. SIGINT) presumably a result of auto-generation or legacy.

On Tue, 16 Apr 2019 at 23:36, Nathan Fisher  wrote:

> Hello,
>
> Currently the *os* package defines the following signals:
>
> var (
> Interrupt Signal  = syscall 
> .SIGINT 
> Kill  Signal  = syscall 
> .SIGKILL 
> )
>
> Would it make sense to include a Term signal as well or were these signals
> considered historical accidents?
>
> My argument for including Term/SIGTERM is that it's used to notify pods of
> imminent shutdown in kubernetes.
>
> While it's simple enough to add a var to my app it feels unnecessary for
> something that seems an increasingly common signal to handle.
>
> Thoughts?
>
> Kind regards,
> --
> Nathan Fisher
>  w: http://junctionbox.ca/
>


-- 
Nathan Fisher
 w: http://junctionbox.ca/

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[jlforrest]

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 compilers, that do a 
bunch of work in one pass.
Once the pass is complete then most of the memory used by the pass could be 
freed. But that
will never happen because the memory appears to the GC as still in use. 
There are probably
other examples of such program structure.

What's the current thinking on this problem?

Cordially,
Jon Forrest

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Engels]

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 of apps. 

That being said, have you observed a performance problem in your application 
related to GC? I would doubt it as the Go GC is VERY efficient. 

> 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 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 compilers, that do a bunch 
> of work in one pass.
> Once the pass is complete then most of the memory used by the pass could be 
> freed. But that
> will never happen because the memory appears to the GC as still in use. There 
> are probably
> other examples of such program structure.
> 
> What's the current thinking on this problem?
> 
> Cordially,
> Jon Forrest
> 
> -- 
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Engels]

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 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 compilers, that do a bunch 
> of work in one pass.
> Once the pass is complete then most of the memory used by the pass could be 
> freed. But that
> will never happen because the memory appears to the GC as still in use. There 
> are probably
> other examples of such program structure.
> 
> What's the current thinking on this problem?
> 
> Cordially,
> Jon Forrest
> 
> -- 
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matt Harden]

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 implemented; it will return an error instead of
sending a signal.

So basically on some systems (Windows in particular), I think SIGTERM
doesn't really exist. On the other hand, os.Kill and os.Interrupt both make
sense on Windows - os.Interrupt can be intercepted to capture ctrl-C, and
os.Kill can be sent to force a process to stop.

On Tue, Apr 16, 2019 at 7:49 PM Nathan Fisher 
wrote:

> 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 convention for variable
> names (e.g. Interrupt). Whereas the syscall package uses a convention more
> akin to C (e.g. SIGINT) presumably a result of auto-generation or legacy.
>
> On Tue, 16 Apr 2019 at 23:36, Nathan Fisher 
> wrote:
>
>> Hello,
>>
>> Currently the *os* package defines the following signals:
>>
>> var (
>> Interrupt Signal  = syscall 
>> .SIGINT 
>> Kill  Signal  = syscall 
>> .SIGKILL 
>> )
>>
>> Would it make sense to include a Term signal as well or were these
>> signals considered historical accidents?
>>
>> My argument for including Term/SIGTERM is that it's used to notify pods
>> of imminent shutdown in kubernetes.
>>
>> While it's simple enough to add a var to my app it feels unnecessary for
>> something that seems an increasingly common signal to handle.
>>
>> Thoughts?
>>
>> Kind regards,
>> --
>> Nathan Fisher
>>  w: http://junctionbox.ca/
>>
>
>
> --
> Nathan Fisher
>  w: http://junctionbox.ca/
>
> --
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ian Lance Taylor]

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.
>
> But I was thinking about multi-pass programs like compilers, that do a bunch 
> of work in one pass.
> Once the pass is complete then most of the memory used by the pass could be 
> freed. But that
> will never happen because the memory appears to the GC as still in use. There 
> are probably
> other examples of such program structure.
>
> What's the current thinking on this problem?

I'm not clear on what the problem is.  If the memory is still
referenced, then it can't be freed.  If the memory can be freed, then
there shouldn't be any references to it.  So, at the point where you
would explicitly free memory, just clear the pointers that point to
it.  Then the GC will free the memory.

Ian

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Engels]

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 noop GC designed for ‘cloud functions’ 
where the entire process is effectively terminated between usages avoiding the 
need for GC (or terminated when max heap is reached and a new process started). 

> On Apr 16, 2019, at 11:31 PM, Ian Lance Taylor  wrote:
> 
>> 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.
>> 
>> But I was thinking about multi-pass programs like compilers, that do a bunch 
>> of work in one pass.
>> Once the pass is complete then most of the memory used by the pass could be 
>> freed. But that
>> will never happen because the memory appears to the GC as still in use. 
>> There are probably
>> other examples of such program structure.
>> 
>> What's the current thinking on this problem?
> 
> I'm not clear on what the problem is.  If the memory is still
> referenced, then it can't be freed.  If the memory can be freed, then
> there shouldn't be any references to it.  So, at the point where you
> would explicitly free memory, just clear the pointers that point to
> it.  Then the GC will free the memory.
> 
> Ian
> 
> -- 
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ian Lance Taylor]

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 of GC is very roughly proportional to the
size of live memory.  Actually freeing non-live memory is essentially,
well, free.

Ian

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[jlforrest]

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 the final word on whether it could 
be freed.

You're saying to modify all the pointers that point to this memory. I'm 
guessing
that this could be a lot of work, Plus, let's say this memory is organized 
as
a linked list. Would it be sufficient to just modify the pointer that 
points to the
head of the list, or would I have to go through the list from tail to head, 
modifying
the pointers in each list element?

And to answer Robert Engels question - no, I'm not concerned with the 
GC's performance because the memory I'm thinking about won't be seen
by the GC since it's still referenced. And yes, I'm wondering whether 
there's
a way to create a region-like entity so that all the memory that was 
allocated
in the region could be freed in one swell foop.

Thanks,
Jon




On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote:
>
>
>
> I'm not clear on what the problem is.  If the memory is still 
> referenced, then it can't be freed.  If the memory can be freed, then 
> there shouldn't be any references to it.  So, at the point where you 
> would explicitly free memory, just clear the pointers that point to 
> it.  Then the GC will free the memory. 
>
> Ian 
>

On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote:
>
> 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. 
> > 
> > But I was thinking about multi-pass programs like compilers, that do a 
> bunch of work in one pass. 
> > Once the pass is complete then most of the memory used by the pass could 
> be freed. But that 
> > will never happen because the memory appears to the GC as still in use. 
> There are probably 
> > other examples of such program structure. 
> > 
> > What's the current thinking on this problem? 
>
> I'm not clear on what the problem is.  If the memory is still 
> referenced, then it can't be freed.  If the memory can be freed, then 
> there shouldn't be any references to it.  So, at the point where you 
> would explicitly free memory, just clear the pointers that point to 
> it.  Then the GC will free the memory. 
>
> Ian 
>

On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote:
>
> 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. 
> > 
> > But I was thinking about multi-pass programs like compilers, that do a 
> bunch of work in one pass. 
> > Once the pass is complete then most of the memory used by the pass could 
> be freed. But that 
> > will never happen because the memory appears to the GC as still in use. 
> There are probably 
> > other examples of such program structure. 
> > 
> > What's the current thinking on this problem? 
>
> I'm not clear on what the problem is.  If the memory is still 
> referenced, then it can't be freed.  If the memory can be freed, then 
> there shouldn't be any references to it.  So, at the point where you 
> would explicitly free memory, just clear the pointers that point to 
> it.  Then the GC will free the memory. 
>
> Ian 
>

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Nitish Saboo]

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 (
> 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 I am using syslog-ng's header files.
> The match function in 'syslog-node.c' is being called from 'main.go' file.
>
>
> When I run 'go build'  it fails with the following error:
>
>
> # forgithub
> syslog-node.c:2:10: fatal error: config.h: No such file or directory
>  #include "config.h"
>   ^~
> compilation terminated.
>
>
> However, 'config.h' file is present in my syslog-ng-3.6.2 directory where 
> main.go is present but it is still not able to find 'config.h'.
>
>
> nitish@nitish-VirtualBox:~/Documents/goworkspace/src/forgithub$ ls
> common.gypi syslog-ng-3.13.2 syslog-node.c
> depssyslog-ng-3.13.2.tar.gz  syslog-node.gyp
> eventlog-0.2.13 syslog-ng-3.6.2  syslog-node.h
> eventlog_0.2.13.tar.gz  syslog-ng_3.6.2.tar.gz
> main.go 
>
>
> nitish@nitish-VirtualBox:~$ cd Documents/goworkspace/src/
> forgithub/syslog-ng-3.6.2/
>
>
> nitish@nitish-VirtualBox:~/Documents/goworkspace/src/forgithub/syslog-ng-3.6.2$
>  
> ls
> aclocal.m4 CONTRIBUTING.md  m4   syslog-ng
> AUTHORSCOPYING  Makefile syslog-ng-ctl
> autogen.sh debian   Makefile.am  syslog-ng.pc
> compiledepcomp  Makefile.in  syslog-ng.pc.in
> config.guess   dist.confmissing  syslog-ng.spec
> config.h   dist.conf.in Mk   syslog-ng.spec.in
> config.h.indoc  modules  test-driver
> config.log INSTALL  NEWS.md  tests
> config.status  install-sh   pkg-config-0.29  tgz2build
> config.sub lib  pkgconfig.tgzVERSION
> configure  libtest  scl  ylwrap
> configure.ac   libtool  scripts
> contribltmain.shstamp-h1
>
>
> go build -x 
>
> =
>
>
>
> WORK=/tmp/go-build995828799
> mkdir -p $WORK/b001/
> cd /home/nitish/Documents/goworkspace/src/forgithub
> CGO_LDFLAGS='"-g" "-O2"' /usr/local/go/pkg/tool/linux_amd64/cgo -objdir 
> $WORK/b001/ -importpath forgithub -- -I $WORK/b001/ -g -O2 -I 
> ./syslog-ng-3.6.2/include ./main.go
> cd $WORK
> gcc -fno-caret-diagnostics -c -x c - || true
> gcc -Qunused-arguments -c -x c - || true
> gcc -fdebug-prefix-map=a=b -c -x c - || true
> gcc -gno-record-gcc-switches -c -x c - || true
> cd $WORK/b001
> TERM='dumb' gcc -I /home/nitish/Documents/goworkspace/src/forgithub -fPIC 
> -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build 
> -gno-record-gcc-switches -I ./ -g -O2 -I /home/nitish/Documents/
> goworkspace/src/forgithub/syslog-ng-3.6.2/include -o ./_x001.o -c 
> _cgo_export.c
> TERM='dumb' gcc -I /home/nitish/Documents/goworkspace/src/forgithub -fPIC 
> -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build 
> -gno-record-gcc-switches -I ./ -g -O2 -I /home/nitish/Documents/
> goworkspace/src/forgithub/syslog-ng-3.6.2/include -o ./_x002.o -c 
> main.cgo2.c
> cd /home/nitish/Documents/goworkspace/src/forgithub
> TERM='dumb' gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I 
> $WORK/b001/ -g -O2 -I ./syslog-ng-3.6.2/include -o $WORK/b001/_x003.o -c 
> syslog-node.c
> # forgithub
> syslog-node.c:2:10: fatal error: config.h: No such file or directory
>  #include "config.h"
>   ^~
> compilation terminated.
>
>
> 1)Do you think there is some issue with the GO code where I need to add 
> some flags to point it to the config.h?
>
> 2)Can you please guide me in the right direction to fix compilation issue, 
> as in where am i missing the piece of link ?
>
>
> Thanks,
>
> Nitish
>
>
>
>
>

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Engels]

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 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 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 the final word on whether it could 
> be freed.
> 
> You're saying to modify all the pointers that point to this memory. I'm 
> guessing
> that this could be a lot of work, Plus, let's say this memory is organized as
> a linked list. Would it be sufficient to just modify the pointer that points 
> to the
> head of the list, or would I have to go through the list from tail to head, 
> modifying
> the pointers in each list element?
> 
> And to answer Robert Engels question - no, I'm not concerned with the 
> GC's performance because the memory I'm thinking about won't be seen
> by the GC since it's still referenced. And yes, I'm wondering whether there's
> a way to create a region-like entity so that all the memory that was allocated
> in the region could be freed in one swell foop.
> 
> Thanks,
> Jon
> 
> 
> 
> 
>> On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote:
>> 
>> 
>> I'm not clear on what the problem is.  If the memory is still 
>> referenced, then it can't be freed.  If the memory can be freed, then 
>> there shouldn't be any references to it.  So, at the point where you 
>> would explicitly free memory, just clear the pointers that point to 
>> it.  Then the GC will free the memory. 
>> 
>> Ian 
> 
>> On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote:
>> 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. 
>> > 
>> > But I was thinking about multi-pass programs like compilers, that do a 
>> > bunch of work in one pass. 
>> > Once the pass is complete then most of the memory used by the pass could 
>> > be freed. But that 
>> > will never happen because the memory appears to the GC as still in use. 
>> > There are probably 
>> > other examples of such program structure. 
>> > 
>> > What's the current thinking on this problem? 
>> 
>> I'm not clear on what the problem is.  If the memory is still 
>> referenced, then it can't be freed.  If the memory can be freed, then 
>> there shouldn't be any references to it.  So, at the point where you 
>> would explicitly free memory, just clear the pointers that point to 
>> it.  Then the GC will free the memory. 
>> 
>> Ian 
> 
>> On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote:
>> 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. 
>> > 
>> > But I was thinking about multi-pass programs like compilers, that do a 
>> > bunch of work in one pass. 
>> > Once the pass is complete then most of the memory used by the pass could 
>> > be freed. But that 
>> > will never happen because the memory appears to the GC as still in use. 
>> > There are probably 
>> > other examples of such program structure. 
>> > 
>> > What's the current thinking on this problem? 
>> 
>> I'm not clear on what the problem is.  If the memory is still 
>> referenced, then it can't be freed.  If the memory can be freed, then 
>> there shouldn't be any references to it.  So, at the point where you 
>> would explicitly free memory, just clear the pointers that point to 
>> it.  Then the GC will free the memory. 
>> 
>> Ian 
> 
> -- 
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Engels]

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 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 the final word on whether it could 
> be freed.
> 
> You're saying to modify all the pointers that point to this memory. I'm 
> guessing
> that this could be a lot of work, Plus, let's say this memory is organized as
> a linked list. Would it be sufficient to just modify the pointer that points 
> to the
> head of the list, or would I have to go through the list from tail to head, 
> modifying
> the pointers in each list element?
> 
> And to answer Robert Engels question - no, I'm not concerned with the 
> GC's performance because the memory I'm thinking about won't be seen
> by the GC since it's still referenced. And yes, I'm wondering whether there's
> a way to create a region-like entity so that all the memory that was allocated
> in the region could be freed in one swell foop.
> 
> Thanks,
> Jon
> 
> 
> 
> 
>> On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote:
>> 
>> 
>> I'm not clear on what the problem is.  If the memory is still 
>> referenced, then it can't be freed.  If the memory can be freed, then 
>> there shouldn't be any references to it.  So, at the point where you 
>> would explicitly free memory, just clear the pointers that point to 
>> it.  Then the GC will free the memory. 
>> 
>> Ian 
> 
>> On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote:
>> 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. 
>> > 
>> > But I was thinking about multi-pass programs like compilers, that do a 
>> > bunch of work in one pass. 
>> > Once the pass is complete then most of the memory used by the pass could 
>> > be freed. But that 
>> > will never happen because the memory appears to the GC as still in use. 
>> > There are probably 
>> > other examples of such program structure. 
>> > 
>> > What's the current thinking on this problem? 
>> 
>> I'm not clear on what the problem is.  If the memory is still 
>> referenced, then it can't be freed.  If the memory can be freed, then 
>> there shouldn't be any references to it.  So, at the point where you 
>> would explicitly free memory, just clear the pointers that point to 
>> it.  Then the GC will free the memory. 
>> 
>> Ian 
> 
>> On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote:
>> 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. 
>> > 
>> > But I was thinking about multi-pass programs like compilers, that do a 
>> > bunch of work in one pass. 
>> > Once the pass is complete then most of the memory used by the pass could 
>> > be freed. But that 
>> > will never happen because the memory appears to the GC as still in use. 
>> > There are probably 
>> > other examples of such program structure. 
>> > 
>> > What's the current thinking on this problem? 
>> 
>> I'm not clear on what the problem is.  If the memory is still 
>> referenced, then it can't be freed.  If the memory can be freed, then 
>> there shouldn't be any references to it.  So, at the point where you 
>> would explicitly free memory, just clear the pointers that point to 
>> it.  Then the GC will free the memory. 
>> 
>> Ian 
> 
> -- 
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ian Lance Taylor]

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


> 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 
>> (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 I am using syslog-ng's header files.
>> The match function in 'syslog-node.c' is being called from 'main.go' file.
>>
>>
>> When I run 'go build'  it fails with the following error:
>>
>>
>> # forgithub
>> syslog-node.c:2:10: fatal error: config.h: No such file or directory
>>  #include "config.h"
>>   ^~
>> compilation terminated.
>>
>>
>> However, 'config.h' file is present in my syslog-ng-3.6.2 directory where 
>> main.go is present but it is still not able to find 'config.h'.
>>
>>
>> nitish@nitish-VirtualBox:~/Documents/goworkspace/src/forgithub$ ls
>> common.gypi syslog-ng-3.13.2 syslog-node.c
>> depssyslog-ng-3.13.2.tar.gz  syslog-node.gyp
>> eventlog-0.2.13 syslog-ng-3.6.2  syslog-node.h
>> eventlog_0.2.13.tar.gz  syslog-ng_3.6.2.tar.gz
>> main.go
>>
>>
>> nitish@nitish-VirtualBox:~$ cd 
>> Documents/goworkspace/src/forgithub/syslog-ng-3.6.2/
>>
>>
>> nitish@nitish-VirtualBox:~/Documents/goworkspace/src/forgithub/syslog-ng-3.6.2$
>>  ls
>> aclocal.m4 CONTRIBUTING.md  m4   syslog-ng
>> AUTHORSCOPYING  Makefile syslog-ng-ctl
>> autogen.sh debian   Makefile.am  syslog-ng.pc
>> compiledepcomp  Makefile.in  syslog-ng.pc.in
>> config.guess   dist.confmissing  syslog-ng.spec
>> config.h   dist.conf.in Mk   syslog-ng.spec.in
>> config.h.indoc  modules  test-driver
>> config.log INSTALL  NEWS.md  tests
>> config.status  install-sh   pkg-config-0.29  tgz2build
>> config.sub lib  pkgconfig.tgzVERSION
>> configure  libtest  scl  ylwrap
>> configure.ac   libtool  scripts
>> contribltmain.shstamp-h1
>>
>>
>> go build -x
>>
>> =
>>
>>
>>
>> WORK=/tmp/go-build995828799
>> mkdir -p $WORK/b001/
>> cd /home/nitish/Documents/goworkspace/src/forgithub
>> CGO_LDFLAGS='"-g" "-O2"' /usr/local/go/pkg/tool/linux_amd64/cgo -objdir 
>> $WORK/b001/ -importpath forgithub -- -I $WORK/b001/ -g -O2 -I 
>> ./syslog-ng-3.6.2/include ./main.go
>> cd $WORK
>> gcc -fno-caret-diagnostics -c -x c - || true
>> gcc -Qunused-arguments -c -x c - || true
>> gcc -fdebug-prefix-map=a=b -c -x c - || true
>> gcc -gno-record-gcc-switches -c -x c - || true
>> cd $WORK/b001
>> TERM='dumb' gcc -I /home/nitish/Documents/goworkspace/src/forgithub -fPIC 
>> -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build 
>> -gno-record-gcc-switches -I ./ -g -O2 -I 
>> /home/nitish/Documents/goworkspace/src/forgithub/syslog-ng-3.6.2/include -o 
>> ./_x001.o -c _cgo_export.c
>> TERM='dumb' gcc -I /home/nitish/Documents/goworkspace/src/forgithub -fPIC 
>> -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build 
>> -gno-record-gcc-switches -I ./ -g -O2 -I 
>> /home/nitish/Documents/goworkspace/src/forgithub/syslog-ng-3.6.2/include -o 
>> ./_x002.o -c main.cgo2.c
>> cd /home/nitish/Documents/goworkspace/src/forgithub
>> TERM='dumb' gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
>> -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I 
>> $WORK/b001/ -g -O2 -I ./syslog-ng-3.6.2/include -o $WORK/b001/_x003.o -c 
>> syslog-node.c
>> # forgithub
>> syslog-node.c:2:10: fatal error: config.h: No such file or directory
>>  #include "config.h"
>>   ^~
>> compilation terminated.
>>
>>
>> 1)Do you think there is some issue with the GO code where I need to add some 
>> flags to point it to the config.h?
>>
>> 2)Can you please guide me in the right direction to fix compilation issue, 
>> as in where am i missing the piece of link ?
>>
>>
>> Thanks,
>>
>> Nitish
>>
>>
>>
>>
> --
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit http

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

[Kurtis Rader]

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 you to expect random strangers to
respond immediately to your request for an answer.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ian Lance Taylor]

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 
> other words,
> the fact that memory is referenced isn't the final word on whether it could 
> be freed.

If the memory is still referenced, it can still be used, so it won't
be freed.  If the memory will not longer be used, then don't reference
it.


> You're saying to modify all the pointers that point to this memory. I'm 
> guessing
> that this could be a lot of work, Plus, let's say this memory is organized as
> a linked list. Would it be sufficient to just modify the pointer that points 
> to the
> head of the list, or would I have to go through the list from tail to head, 
> modifying
> the pointers in each list element?

As Robert said, just stop referencing the head.  The only references
that count are the ones from global and local variables.  If it can't
be reached by following pointers from a variable, then it is no longer
referenced.


> And to answer Robert Engels question - no, I'm not concerned with the
> GC's performance because the memory I'm thinking about won't be seen
> by the GC since it's still referenced. And yes, I'm wondering whether there's
> a way to create a region-like entity so that all the memory that was allocated
> in the region could be freed in one swell foop.

My earlier answer still stands: such a region is unlikely to make a
significant difference in a GC system.

Ian

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Using C++ code with cgo

[xiang liu]

you can see my repo,
https://github.com/notedit/media-server-go/tree/master/wrapper

use c++ and go,  I use swig to generate c++ binding for go

av  于2019年4月12日周五 上午1:09写道：

> Works like charm. Thanks a lot.
>
> Here is my code:
>
> aptwrap.h
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> void print();
>
>
> #ifdef __cplusplus
> }
> #endif
>
>
>
> aptwrap.cpp
>
> #include "aptwrap.h"
>
> #include 
> #include 
> #include 
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
>   void print() {
> std::cout << " " << std::endl;
>
>  pkgInitConfig(*_config);
> pkgInitSystem(*_config, _system);
>
> pkgCacheFile cache_file;
> pkgCache* cache = cache_file.GetPkgCache();
>
> for (pkgCache::PkgIterator package = cache->PkgBegin();
> !package.end(); package++) {
> std::cout << package.Name() << std::endl;
> }
>
>   }
>
> #ifdef __cplusplus
> }
> #endif
>
> main.go
>
> package main
>
> // #cgo CXXFLAGS: -I.
> // #cgo CFLAGS: -I.
> // #cgo LDFLAGS: -lapt-pkg
> // #include "aptwrap.h"
> import "C"
>
> func main() {
> C.print()
> }
>
> Thanks
>
>
> On Thursday, April 11, 2019 at 7:51:42 PM UTC+3, Marcin Romaszewicz wrote:
>>
>> Wrap your C++ code in C.
>>
>> Create a header which is simply:
>>
>> cwrapper.h:
>> void printSomething()
>>
>> Then you can have a cwrapper.cpp instead of your wrapper.hpp:
>> #include 
>> extern "C" {
>>
>>
>> void printSomething() {
>>   printf("Hello World");
>> }
>> }
>>
>> Your C++ code will produce a function named printSomething with C linkage
>> semantics, and Go can call that without issue. By hiding  from
>> CGO, you don't have it trying to find C++ headers.
>>
>>
>> On Thu, Apr 11, 2019 at 8:49 AM  wrote:
>>
>>> Hi *,
>>>
>>> I have following C++ code:
>>>
>>> wrapper.hpp:
>>>
>>> #include 
>>>
>>> void printSomething() {
>>>   printf("Hello World");
>>> }
>>>
>>> And corresponding main.go:
>>>
>>> package main
>>>
>>> // #cgo CXXFLAGS: -I.
>>> // #cgo CFLAGS: -I.
>>> // #cgo LDFLAGS:
>>> // #include "wrapper.hpp"
>>> import "C"
>>>
>>> func main() {
>>> C.print()
>>> }
>>>
>>> Unfortunately the result of "go build ." is:
>>>
>>> # _/home/avalchev/Sources/apt
>>> In file included from ./main.go:6:0:
>>> ./wrapper.hpp:1:20: fatal error: iostream: No such file or directory
>>>  #include 
>>> ^
>>> compilation terminated.
>>>
>>>
>>> Basically I'm trying to create debian's libapt-pkg wrapper, but the only
>>> workaround I tried (and it works) is to create static library, but this
>>> reduces portability a lot.
>>>
>>> Is there any way to make this work ?
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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 golan...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.