[go-nuts] Re: On the topic of try() and errors

[Andrey Tcherepanov]

Michael,

Wonderful reasoning! Your post did reach the goal of "encourage to offer 
insights", because now I have "now what?" stuck in my head.

My first reaction was "holy ..., it is an assert after all!" Well, "assert" 
+ gentle return instead of panic as you pointed out.

thing is ... how would we use that in making error handling 
shorter(optional?) and more readable(must have)?...

func f()(string, error){
   f, err := os.Open("file")
   assert f!=nil, err==nil // or assert f!=nil && err == nil
   defer f.Close()
   //do things with f that assumes it is not nil
}

or 

func f()(string, error){
   f := assert os.Open("file") && f != nil
   defer f.Close()
   //do things with f that assumes it is not nil
}


does not strike me as a more readable.

(And I don't find try() to be appealing for being so much associated with 
"try-catch", and for having function syntax to really hide the "return from 
inside".)

Andrey

On Tuesday, July 9, 2019 at 5:46:03 PM UTC-6, Michael Jones wrote:
>
> In the hope of elevating the discussion of late, I've made a little speech 
> as one might do at a lunchtime discussion with students or colleagues. 
> Maybe this will make sense to some kindred spirits here...
>
> Thoughts about facilitating error handling in Go(), and the try() proposal 
> in particular, have inspired a great deal of thought and sharing, with 
> heated disapproval by some and, it seems, general approval by many. In a 
> sense this is all premature--the proposal is a test and the good/bad 
> judgement will come over time.
>
> One aspect of the topic that seems to cause alarms is the fact it looks 
> like and in some ways acts like error-related try() features in C, C++, C#, 
> Java, JavaScript, and SQL. This invites presumption of harm through 
> similarity. The goal here is to offer *an entirely different way to think 
> about the issue*. In this alternate view, some aspects are more readily 
> understood and extensions and refinements more inviting. So, from here out, 
> it is not about errors.
>
> In 1969, C. A. R. Hoare, Mr. Quicksort and the father of the ideas in Go's 
> channels, was inspired to seek a logical, mathematical basis for computer 
> programming. He, Nicholas Wirth, Ole-Johan Dahl, and Edsger Dijkstra were 
> marching down this path and they all realized that *guarded computation* 
> was important; that statements of provable truth are the basis of rigor.
>
> [image: assert.002.jpeg]
> In my Fig. 1 here, you can see the problem, the result of math.Sqrt() is 
> valid or invalid depending on the status of x; x in the domain of 
> non-negative real numbers means Sqrt is good and x out of that domain means 
> the opposite. 
>
> As a starting point, Hoare and the others embraced AJT's call for 
> *assertions*, such as is shown in Fig 2. as is typical now and then. 
> Let's call it an *assertion statement*. (Hoare actually proposed a 
> keyword version, "assert ;" that would return with 
> prejudice if the bool was false.)
>
> We all know this. But, are other kinds of assertions interesting, beyond 
> statements? Here are two others, the *assertion expression* and the 
> *assertion 
> assignment,* along with Alan Turing's original 1949 appeal for 
> assertions: 
>
> [image: assert.003.jpeg]
> What I've shown here is not something I'm aware of being implemented 
> before, but both Fig. 3 and 4 show consistent specializations of assertion 
> statement to substatements; in the one case, to a function's arguments and 
> in the other, to the values being assigned. If we had these inline 
> assertions, we could call functions with range checking clear, local, and 
> concise, and assign return values with stated conditions known to have been 
> proven. To quote Turing, "...from which the correctness of the whole 
> program easily follows."
>
> There is a subtle shift here, from asserting that x>=0 which is specific, 
> to insisting that Sqrt() has not complained about a domain error, which is 
> specific in meaning but omits specifying what that range might be. 
> (AssertDomain(math.Log(x)) would have the same meaning but a different 
> domain.)
>
> Perhaps Figure 4 looks familiar to you. Compare to Fig. 5...
>
> [image: assert.004.jpeg]
> ...as you can see, we've come to the great debate, but along a different 
> path. If you can pretend that "try" did not have a decade of bitter 
> meanings from other languages and common misuse, then you can see try as 
> nothing more than an assertion assignment. In this view, disjoint from the 
> error type, we can also see that other "same meaning different detail" uses 
> could make sense, just like the Domain assertion of Fig 4. If I have test 
> for error value != nil, then why not test for non-error pointer value == 
> nil as in Fig. 6. Not only does this seem useful and thematically 
> consistent, it happens to already be in Go!
>
> Where you ask? Where has this nil-pointer-try been hiding? Right here:
> [image: assert.005.jpeg]
> So now we reach my 

Re: [go-nuts] How to store the address of C struct on Go side in an array (cgo)

[Ian Lance Taylor]

On Thu, Jul 11, 2019 at 8:45 PM Nitish Saboo  wrote:
>
> I have the following function 'LoadPatternDB' where I am allocating memory 
> for a C struct.My C struct contains the callback function.
> I have the function 'LoadPatternDB' that  is running in multiple go 
> routines.I have written a C wrapper that internally uses syslog-ng methods.
> While running the method 'LoadPatternDB' in syslogparser.go with multiple go  
> routines, I get the following error.
>
> *** Error in `fatal error: bin/main': double free or corruption 
> (fasttop)unexpected signal during runtime execution: 0x7fd2b8588060 ***
>
> My queries are:
>
> 1)When do we get this error ?

That error is from the C memory allocator.  It does not come from Go.
It means that you called a C function such as malloc, calloc, or free,
and the call detected memory corruption.  It may be calling free twice
on the same pointer, or it may be using a dangling pointer, or it may
be some other memory corruption.  We don't know.

> 2)Is it because of not deallocating the struct memory, I am getting this 
> error ?But at the same time I am allocating separate memories for each of the 
> go routines.

No.

> 3)Is it because of the memory crunch on the system that can lead to this 
> error ?

Unlikely.  It is conceivable that malloc or calloc is returning NULL,
and you are not checking for NULL, and that is leading to memory
corruption.  But that is unlikely to happen, and it is unlikely to
cause this kind of error.

> 4)The issues is seen with only multiple go routines.Single iteration of the 
> code is working fine.

That sounds like a good place to start looking.

> 5)Can I not call Go code and C code using multiple threads ?

You can call C code from multiple goroutines, but of course the C code
has to be prepared to handle it.  It's no different from a C program
that calls the C function from multiple threads.

If you show us a small, complete, self-contained example, that does
not call any other code, then we may be able to see the problem.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVxWk5qeCyE4oFqgstSA7yp%2Bg4M8VZAyj3G%2Bo9iN3stiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Andrey Tcherepanov]

Thank you very much for pointing to that paper! Somehow I think it will be 
referenced in the future with a prefix "seminal" :)

What these guys are proposing in that paper would be closer to (Go-style)
func f() (v value | e error) { ... }

(where "|" could be read as "or" or "union")

with that in mind , the call to f might be something like

v := f() 

if e := v.(error) {
  ...
}

A.

On Monday, July 1, 2019 at 12:46:29 AM UTC-6, Sanjay wrote:
>
> 3 of the most well-known new languages in the past decade (Swift, Rust, 
> and Go, respectively) have all eschewed exceptions for control flow in 
> favor of some sigil in the source code to propagate errors explicitly. 
> Swift uses try-statements (along with a few other control flow constructs), 
> Rust uses the "?" operator (previously the try! macro), and Go uses "if err 
> != nil".
>
> C++, a language which does have exceptions, has significant fractions of 
> its user base which disable exception support entirely (20% according to a 
> survey) or partially (52%). Google, for instance, almost invariably 
> compiles with -fno-exceptions and uses macros to propagate errors 
> explicitly (see 
> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49
>  to 
> get a sense for how that works). Herb Sutter, one of the well-known members 
> of the C++ standards committee from Microsoft, has proposals out to make 
> propagating exceptions require a visible sigil in the source code (also a 
> "try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 (an 
> interesting talk overall, I've linked to the specific relevant time). His 
> actual proposal paper is also an interesting read: 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf. In a 
> table with the following introduction "This section lays out what I believe 
> are ideal error handling characteristics. They are not unique to C++; I 
> believe they apply to most modern languages", he lists "Unhandled error 
> propagation is visible" as something not provided by C++ exceptions today.
>
> It's possible that a decade from now, this will all have been a minor 
> blip, and you will eventually be proven right. But at the very least, this 
> context that should inform your priors.
>
> Sanjay
>
> PS - checked exceptions don't really have a great leg to stand on either 
> (e.g. consider their interaction with Java 8's streams: 
> https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams, 
> or consider that both Scala and Kotlin don't implement support for them at 
> all) 
>
> On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels wrote:
>>
>> I’ve developed systems that wrap checked exceptions in unchecked ones, 
>> but in every case I can think of it was to “abort to the top” - returning 
>> control (or exiting) - it is a specialized case of the re-throw, but I 
>> would argue it is rarely used in anything other than framework type code, 
>> with applications code typically wrapping the specific exception in an 
>> “higher-level application checked exception”, that the upper layers handle 
>> (possibly inspecting the “cause” exception. 
>>
>> As to not answering the question about transferring across Go routines, I 
>> apologize. It was not intentional - I read the statement a few times and 
>> didn’t quite get the concern - and meant to get back to it and forgot - but 
>> I read it again a few times and still don’t understand the problem. 
>>
>> What is particular about Go that makes this difficult? It is pretty 
>> common practice to pass exceptions across threads in Java and C++ - e.g. 
>> fork/join and the worker thread throws an exception - the exception is 
>> passed to the joining thread. Conceptually, it is as if the function was 
>> called serially and the exception thrown at the fork point. In these cases 
>> the exception is wrapped, but it has to be because of the strong type 
>> system. It is also pretty trivial to declare a wrapper function that 
>> declares the checked exceptions for clarity - this is done routinely in rpc 
>> using proxies. 
>>
>> > On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor  
>> wrote: 
>> > 
>> > On Sun, Jun 30, 2019 at 5:23 PM robert engels  
>> wrote: 
>> >> 
>> >> I am going to disagree here. I don’t think ‘checked exceptions’ 
>> exhibit this behavior. Addressing the points from the Joeal  article, 
>> > 
>> > Checked exceptions address some of the difficulties with exceptions. 
>> > However, they introduce new difficulties, and I do not believe they 
>> > work in large-scale programs.  In practice, checked exceptions 
>> > degenerate into unchecked exceptions.  Changing the set of exceptions 
>> > that a function throws forces all callers to adjust their set of 
>> > exceptions.  In practice this is so painful that programs catch 
>> > exceptions and turn into them into unchecked exceptions.  There are a 
>> > number of discussions on the Interwebs about the problems with checked 
>> 

Re: [go-nuts] How to store the address of C struct on Go side in an array (cgo)

[Nitish Saboo]

Hi,

I have the following function 'LoadPatternDB' where I am allocating memory
for a C struct.My C struct contains the callback function.
I have the function 'LoadPatternDB' that  is running in multiple go
routines.I have written a C wrapper that internally uses syslog-ng methods.
While running the method 'LoadPatternDB' in syslogparser.go with multiple
go  routines, I get the following error.

 Error in `fatal error: bin/main': double free or corruption
(fasttop)unexpected signal during runtime execution: 0x7fd2b8588060 

My queries are:

1)When do we get this error ?
2)Is it because of not deallocating the struct memory, I am getting this
error ?But at the same time I am allocating separate memories for each of
the go routines.
3)Is it because of the memory crunch on the system that can lead to this
error ?
4)The issues is seen with only multiple go routines.Single iteration of the
code is working fine.
5)Can I not call Go code and C code using multiple threads ?

Can some one please guide me here ?

syslog-node.c
===

PatternDB *patterndb[WORKERIDS];

int load_pattern_db(const gchar* filename, key_value_cb cb, int workerId)
{
if(patterndb[workerId] != NULL){
pattern_db_free(patterndb[workerId]);
}
patterndb[workerId] = pattern_db_new();
pattern_db_reload_ruleset(patterndb[workerId], configuration, filename);
pattern_db_set_emit_func(patterndb[workerId], pdbtool_pdb_emit_accumulate,
cb);
return 0;
}

gboolean pdbtool_accumulate_fields(NVHandle handle, const gchar *name,
const gchar *value, gssize length, gpointer user_data)

{
struct Accumulatedparams *params = user_data;
  key_value_cb cb = params->callback;
  cb(name, value, length, params->data);
  return FALSE;
}

void pdbtool_pdb_emit_accumulate(LogMessage *msg, gboolean synthetic,
gpointer user_data)
{
nv_table_foreach(msg->payload, logmsg_registry, pdbtool_accumulate_fields,
user_data);
}
syslogparser.go
=

func (obj SyslogParser) LoadPatternDB(opts Syslog, workerId int) {
patterndbpath := C.CString(opts.Patterndb)
defer C.free(unsafe.Pointer(patterndbpath))
InitStruct := (*C.Accumulatedparams)(C.calloc(1,
C.sizeof_struct_Accumulatedparams))
InitStruct.callback = (C.key_value_cb)(C.callback)
InitStruct.data = C.int(workerId)
C.load_pattern_db(patterndbpath,
(*C.Accumulatedparams)(unsafe.Pointer(InitStruct)), C.int(workerId))
}


//export Result
func Result(key *C.char, value *C.char, value_len C.size_t, mapid C.int) {
fmt.Println("Map Id: " + strconv.Itoa(int(mapid)))
value_field := C.GoStringN(value, C.int(value_len))
key_field := C.GoString(key)
remap, ok := constants.FIELD_MAPPINGS[key_field]
if ok {
Check.result[int(mapid)][remap] = value_field
//check.result[remap] = value_field
} else {
//check.result[key_field] = value_field
Check.result[int(mapid)][key_field] = value_field
}
}


cfuncs.go
-
package lib

/*

#include 

// The gateway function
void callback(char *key, char *value, size_t value_len, int mapid)
{
//printf("C.callOnMeGo_cgo(): called");
void Result(const char *key, const char *value, size_t value_len, int
mapid);
Result(key, value, value_len, mapid);
}
*/
import "C"

syslog-node.h


#ifndef TEST_H_INCLUDED
#define TEST_H_INCLUDED

#include 

typedef void (*key_value_cb)(const char* key, const char* value, size_t
value_len, int data);
typedef struct Accumulatedparams{
key_value_cb callback;
int data;
}Accumulatedparams;
int load_pattern_db(const char* filename, Accumulatedparams *cb, int
workerId);

#endif


On Fri, Jul 12, 2019 at 12:32 AM Nitish Saboo 
wrote:

> This is the code snippet I was talking about:
>
> store := make([]*C.struct_Accumulatedparams, 2)
>
>
> func (obj Syslogparser) LoadPatternDB(opts Syslog) {
> >
> > patterndb_path := C.CString(opts.patterndb)
> > store[0] = (*C.Accumulatedparams)(C.calloc(1,
> C.sizeof_struct_Accumulatedparams))
> > store[0].callback = (C.key_value_cb)(C.callOnMeGo_cgo)
> > store[0].data = C.int(1)
> > C.load_pattern_db(patterndb_path,
> (*C.Accumulatedparams)(unsafe.Pointer(store[0])))
> > }
>
>
> On Fri, 12 Jul 2019, 00:22 Nitish Saboo,  wrote:
>
>> Hi Ian,
>>
>> Can you please guide me with the correct way  to store the address of a C
>> struct in a Go array so that I can use it later for deallocating the memory?
>>
>> Thanks,
>> Nitish
>>
>> On Fri, 12 Jul 2019, 00:04 Ian Lance Taylor,  wrote:
>>
>>> On Thu, Jul 11, 2019 at 10:58 AM Nitish Saboo 
>>> wrote:
>>> >
>>> > pattern_db_set_emit_func(patterndb[workerId],
>>> pdbtool_pdb_emit_accumulate, cb);
>>> > suggests that cb is being saved away for future use.
>>> >
>>> > yes cb is being saved away and is being used for future use for
>>> callbacks to Go code.
>>>
>>> Then clearly the Go code must not immediately free the C memory.  That
>>> is no different from how C code would work.
>>>
>>>
>>> > syslog-node.h
>>> >  
>>> >
>>> >  #ifndef TEST_H_INCLUDED
>>> >  #define TEST_H_INCLUDED
>>> >
>>> >  #include 
>>> >  typedef void (*key_value_cb)(const char* 

Re: [go-nuts] How to store the address of C struct on Go side in an array (cgo)

[Nitish Saboo]

This is the code snippet I was talking about:

store := make([]*C.struct_Accumulatedparams, 2)


func (obj Syslogparser) LoadPatternDB(opts Syslog) {
>
> patterndb_path := C.CString(opts.patterndb)
> store[0] = (*C.Accumulatedparams)(C.calloc(1,
C.sizeof_struct_Accumulatedparams))
> store[0].callback = (C.key_value_cb)(C.callOnMeGo_cgo)
> store[0].data = C.int(1)
> C.load_pattern_db(patterndb_path,
(*C.Accumulatedparams)(unsafe.Pointer(store[0])))
> }


On Fri, 12 Jul 2019, 00:22 Nitish Saboo,  wrote:

> Hi Ian,
>
> Can you please guide me with the correct way  to store the address of a C
> struct in a Go array so that I can use it later for deallocating the memory?
>
> Thanks,
> Nitish
>
> On Fri, 12 Jul 2019, 00:04 Ian Lance Taylor,  wrote:
>
>> On Thu, Jul 11, 2019 at 10:58 AM Nitish Saboo 
>> wrote:
>> >
>> > pattern_db_set_emit_func(patterndb[workerId],
>> pdbtool_pdb_emit_accumulate, cb);
>> > suggests that cb is being saved away for future use.
>> >
>> > yes cb is being saved away and is being used for future use for
>> callbacks to Go code.
>>
>> Then clearly the Go code must not immediately free the C memory.  That
>> is no different from how C code would work.
>>
>>
>> > syslog-node.h
>> >  
>> >
>> >  #ifndef TEST_H_INCLUDED
>> >  #define TEST_H_INCLUDED
>> >
>> >  #include 
>> >  typedef void (*key_value_cb)(const char* key, const char* value,
>> size_t value_len, int data);
>> >  typedef struct Accumulatedparams{
>> >  key_value_cb callback;
>> > int data;
>> >  }Accumulatedparams;
>> >  int initialize_engine(const char* filename, const char* module_path);
>> >  int reload_pattern_db(const char* filename, Accumulatedparams *cb, int
>> workerId);
>> > int load_pattern_db(const char* filename, Accumulatedparams *cb, int
>> workerId);
>> >
>> > >If I declare the array in the following manner:
>> >
>> > result := make([]*C.struct_Accumulatedparams)
>> > store[0] = (*C.Accumulatedparams)(C.calloc(1,
>> C.sizeof_struct_Accumulatedparams))
>> >
>> > Here also the code gets compiled successfully, just that the GoLand IDE
>> shows store[0].callback and store[0].data in red color saying Unresolved
>> reference 'callback' and Unresolved reference 'data' respectively.Not sure
>> how the code compiles if the IDE shows it in red color. Binary(./main)
>> works fine
>>
>> I don't know what the GoLand IDE does.  I don't see any
>> store[0].callback or store[0].data in that code snippet.
>>
>>
>> > Though this works,
>> >
>> > store[0] = (*C.Accumulatedparams)(C.calloc(1,
>> C.sizeof_struct_Accumulatedparams))
>> > InitStruct := store[0]
>> > InitStruct.callback = (C.key_value_cb)(C.callOnMeGo_cgo)
>> > InitStruct.data = C.int(1)
>> >
>> > Here the code compiles successfully and there is no complain from
>> GoLand IDE as well.Binary (./main) too works fine
>> >
>> > So what i thought to do :
>> >
>> > type Store struct{
>> > result []*C.struct_Accumulatedparams
>> > data []C.int
>> > callback []C.key_value_cb
>> > }
>> >
>> > var store = Store{result: make([]*C.struct_Accumulatedparams, 2), data:
>> make([]C.int ,2), callback:make([]C.key_value_cb, 2)}
>> >
>> > func (obj Syslogparser) LoadPatternDB(opts Syslog) {
>> >
>> > patterndb_path := C.CString(opts.patterndb)
>> > store.result[0] = (*C.Accumulatedparams)(C.calloc(1,
>> C.sizeof_struct_Accumulatedparams)) <<
>> > store.callback[0] = (C.key_value_cb)(C.callOnMeGo_cgo) <
>> > store.data[0] = C.int(1)
>> > C.load_pattern_db(patterndb_path,
>> (*C.Accumulatedparams)(unsafe.Pointer(store.result[0])))
>> > }
>> >
>> > Here the code gets compiled successfully. But I am getting the
>> following  error when I run the binary './main'
>> >
>> > 1In reload PatternDb:
>> > PatternDb :/home/nsaboo/Documents/goworkspace/src/poc/reload.xml
>> > ModulePath :usr/local/lib/syslog-ng
>> > fatal error: unexpected signal during runtime execution
>> > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]
>> >
>> > runtime stack:
>> > runtime.throw(0x4fa203, 0x2a)
>> > /usr/local/go/src/runtime/panic.go:617 +0x72
>> > runtime.sigpanic()
>> > /usr/local/go/src/runtime/signal_unix.go:374 +0x4a9
>> >
>> > goroutine 1 [syscall]:
>> > runtime.cgocall(0x4b8fb0, 0xc42cc8, 0x4d9280)
>> > /usr/local/go/src/runtime/cgocall.go:128 +0x5b fp=0xc42c98
>> sp=0xc42c60 pc=0x404f6b
>> > main._Cfunc_execute_percustomer_db(0x7fb0fb5a5fa0, 0x1d5,
>> 0x7fb0fb8259b0, 0x8)
>> > _cgo_gotypes.go:121 +0x45 fp=0xc42cc8 sp=0xc42c98 pc=0x4b5ca5
>> > main.Syslogparser.ParseMessagePerCustomer(0xca2000, 0x36, 0x4f6b0c,
>> 0x18, 0x4f3fc4, 0x8, 0xcd, 0x1d5)
>> > /home/nsaboo/Documents/goworkspace/src/poc/main.go:132 +0x109
>> fp=0xc42d38 sp=0xc42cc8 pc=0x4b6f09
>> > main.perCustomerParsing(...)
>> > /home/nsaboo/Documents/goworkspace/src/poc/main.go:249
>> > main.main()
>> > /home/nsaboo/Documents/goworkspace/src/poc/main.go:232 +0x6e1
>> fp=0xc42f98 sp=0xc42d38 pc=0x4b78e1
>> > runtime.main()
>> > 

Re: [go-nuts] How to store the address of C struct on Go side in an array (cgo)

[Ian Lance Taylor]

On Thu, Jul 11, 2019 at 10:58 AM Nitish Saboo  wrote:
>
> pattern_db_set_emit_func(patterndb[workerId], pdbtool_pdb_emit_accumulate, 
> cb);
> suggests that cb is being saved away for future use.
>
> yes cb is being saved away and is being used for future use for callbacks 
> to Go code.

Then clearly the Go code must not immediately free the C memory.  That
is no different from how C code would work.


> syslog-node.h
>  
>
>  #ifndef TEST_H_INCLUDED
>  #define TEST_H_INCLUDED
>
>  #include 
>  typedef void (*key_value_cb)(const char* key, const char* value, size_t 
> value_len, int data);
>  typedef struct Accumulatedparams{
>  key_value_cb callback;
> int data;
>  }Accumulatedparams;
>  int initialize_engine(const char* filename, const char* module_path);
>  int reload_pattern_db(const char* filename, Accumulatedparams *cb, int 
> workerId);
> int load_pattern_db(const char* filename, Accumulatedparams *cb, int 
> workerId);
>
> >If I declare the array in the following manner:
>
> result := make([]*C.struct_Accumulatedparams)
> store[0] = (*C.Accumulatedparams)(C.calloc(1, 
> C.sizeof_struct_Accumulatedparams))
>
> Here also the code gets compiled successfully, just that the GoLand IDE shows 
> store[0].callback and store[0].data in red color saying Unresolved reference 
> 'callback' and Unresolved reference 'data' respectively.Not sure how the code 
> compiles if the IDE shows it in red color. Binary(./main) works fine

I don't know what the GoLand IDE does.  I don't see any
store[0].callback or store[0].data in that code snippet.


> Though this works,
>
> store[0] = (*C.Accumulatedparams)(C.calloc(1, 
> C.sizeof_struct_Accumulatedparams))
> InitStruct := store[0]
> InitStruct.callback = (C.key_value_cb)(C.callOnMeGo_cgo)
> InitStruct.data = C.int(1)
>
> Here the code compiles successfully and there is no complain from GoLand IDE 
> as well.Binary (./main) too works fine
>
> So what i thought to do :
>
> type Store struct{
> result []*C.struct_Accumulatedparams
> data []C.int
> callback []C.key_value_cb
> }
>
> var store = Store{result: make([]*C.struct_Accumulatedparams, 2), data: 
> make([]C.int ,2), callback:make([]C.key_value_cb, 2)}
>
> func (obj Syslogparser) LoadPatternDB(opts Syslog) {
>
> patterndb_path := C.CString(opts.patterndb)
> store.result[0] = (*C.Accumulatedparams)(C.calloc(1, 
> C.sizeof_struct_Accumulatedparams)) <<
> store.callback[0] = (C.key_value_cb)(C.callOnMeGo_cgo) <
> store.data[0] = C.int(1)
> C.load_pattern_db(patterndb_path, 
> (*C.Accumulatedparams)(unsafe.Pointer(store.result[0])))
> }
>
> Here the code gets compiled successfully. But I am getting the following  
> error when I run the binary './main'
>
> 1In reload PatternDb:
> PatternDb :/home/nsaboo/Documents/goworkspace/src/poc/reload.xml
> ModulePath :usr/local/lib/syslog-ng
> fatal error: unexpected signal during runtime execution
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]
>
> runtime stack:
> runtime.throw(0x4fa203, 0x2a)
> /usr/local/go/src/runtime/panic.go:617 +0x72
> runtime.sigpanic()
> /usr/local/go/src/runtime/signal_unix.go:374 +0x4a9
>
> goroutine 1 [syscall]:
> runtime.cgocall(0x4b8fb0, 0xc42cc8, 0x4d9280)
> /usr/local/go/src/runtime/cgocall.go:128 +0x5b fp=0xc42c98 
> sp=0xc42c60 pc=0x404f6b
> main._Cfunc_execute_percustomer_db(0x7fb0fb5a5fa0, 0x1d5, 0x7fb0fb8259b0, 0x8)
> _cgo_gotypes.go:121 +0x45 fp=0xc42cc8 sp=0xc42c98 pc=0x4b5ca5
> main.Syslogparser.ParseMessagePerCustomer(0xca2000, 0x36, 0x4f6b0c, 0x18, 
> 0x4f3fc4, 0x8, 0xcd, 0x1d5)
> /home/nsaboo/Documents/goworkspace/src/poc/main.go:132 +0x109 fp=0xc42d38 
> sp=0xc42cc8 pc=0x4b6f09
> main.perCustomerParsing(...)
> /home/nsaboo/Documents/goworkspace/src/poc/main.go:249
> main.main()
> /home/nsaboo/Documents/goworkspace/src/poc/main.go:232 +0x6e1 fp=0xc42f98 
> sp=0xc42d38 pc=0x4b78e1
> runtime.main()
> /usr/local/go/src/runtime/proc.go:200 +0x20c fp=0xc42fe0 sp=0xc42f98 
> pc=0x42cd9c
> runtime.goexit()
> /usr/local/go/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc42fe8 
> sp=0xc42fe0 pc=0x4548c1
> }
>
>
> Where am i going wrong here ?

Somewhere your C code is getting a NULL pointer dereference.

I don't see much in these questions that seems specific to Go.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWPqL7wM%3D-fWntgn23-H1bZYBYg1RCLxSyzd2%2Btf7u9Rg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to store the address of C struct on Go side in an array (cgo)

[Nitish Saboo]

pattern_db_set_emit_func(patterndb[workerId], pdbtool_pdb_emit_accumulate,
cb);
suggests that cb is being saved away for future use.

yes cb is being saved away and is being used for future use for
callbacks to Go code.

Yes, it's fine to store the address of the C struct on the Go side, if
that helps.

syslog-node.h
 

 #ifndef TEST_H_INCLUDED
 #define TEST_H_INCLUDED

 #include 
 typedef void (*key_value_cb)(const char* key, const char* value, size_t
value_len, int data);
 typedef struct Accumulatedparams{
 key_value_cb callback;
int data;
 }Accumulatedparams;
 int initialize_engine(const char* filename, const char* module_path);
 int reload_pattern_db(const char* filename, Accumulatedparams *cb, int
workerId);
int load_pattern_db(const char* filename, Accumulatedparams *cb, int
workerId);

>If I declare the array in the following manner:

result := make([]*C.struct_Accumulatedparams)
store[0] = (*C.Accumulatedparams)(C.calloc(1,
C.sizeof_struct_Accumulatedparams))

*Here also the code gets compiled successfully, just that the GoLand IDE
shows **store[0].callback and **store[0].data in red color saying **Unresolved
reference 'callback' and Unresolved reference 'data' respectively.Not sure
how the code compiles if the IDE shows it in red color. Binary(./main)
works fine*

Though this works,

store[0] = (*C.Accumulatedparams)(C.calloc(1,
C.sizeof_struct_Accumulatedparams))
InitStruct := store[0]
InitStruct.callback = (C.key_value_cb)(C.callOnMeGo_cgo)
InitStruct.data = C.int(1)

*Here the code compiles successfully and there is no complain from GoLand
IDE as well.Binary (./main) too works fine*

So what i thought to do :

type Store struct{
result []*C.struct_Accumulatedparams
data []C.int
callback []C.key_value_cb
}

var store = Store{result: make([]*C.struct_Accumulatedparams, 2), data:
make([]C.int ,2), callback:make([]C.key_value_cb, 2)}

func (obj Syslogparser) LoadPatternDB(opts Syslog) {

patterndb_path := C.CString(opts.patterndb)
store.result[0] = (*C.Accumulatedparams)(C.calloc(1,
C.sizeof_struct_Accumulatedparams)) <<
store.callback[0] = (C.key_value_cb)(C.callOnMeGo_cgo) <
store.data[0] = C.int(1)
C.load_pattern_db(patterndb_path,
(*C.Accumulatedparams)(unsafe.Pointer(store.result[0])))
}

*Here the code gets compiled successfully. But I am getting the following
error when I run the binary './main'*

1In reload PatternDb:
PatternDb :/home/nsaboo/Documents/goworkspace/src/poc/reload.xml
ModulePath :usr/local/lib/syslog-ng
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]

runtime stack:
runtime.throw(0x4fa203, 0x2a)
/usr/local/go/src/runtime/panic.go:617 +0x72
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:374 +0x4a9

goroutine 1 [syscall]:
runtime.cgocall(0x4b8fb0, 0xc42cc8, 0x4d9280)
/usr/local/go/src/runtime/cgocall.go:128 +0x5b fp=0xc42c98
sp=0xc42c60 pc=0x404f6b
main._Cfunc_execute_percustomer_db(0x7fb0fb5a5fa0, 0x1d5, 0x7fb0fb8259b0,
0x8)
_cgo_gotypes.go:121 +0x45 fp=0xc42cc8 sp=0xc42c98 pc=0x4b5ca5
main.Syslogparser.ParseMessagePerCustomer(0xca2000, 0x36, 0x4f6b0c,
0x18, 0x4f3fc4, 0x8, 0xcd, 0x1d5)
/home/nsaboo/Documents/goworkspace/src/poc/main.go:132 +0x109
fp=0xc42d38 sp=0xc42cc8 pc=0x4b6f09
main.perCustomerParsing(...)
/home/nsaboo/Documents/goworkspace/src/poc/main.go:249
main.main()
/home/nsaboo/Documents/goworkspace/src/poc/main.go:232 +0x6e1
fp=0xc42f98 sp=0xc42d38 pc=0x4b78e1
runtime.main()
/usr/local/go/src/runtime/proc.go:200 +0x20c fp=0xc42fe0
sp=0xc42f98 pc=0x42cd9c
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc42fe8
sp=0xc42fe0 pc=0x4548c1
}


*Where am i going wrong here ?*

Thanks,
Nitish

On Thu, 11 Jul 2019, 23:03 Ian Lance Taylor,  wrote:

> On Thu, Jul 11, 2019 at 9:27 AM Nitish Saboo 
> wrote:
> >
> > Following is my C Code:
> >
> > PatternDB *patterndb[WORKERIDS];
> >
> > int load_pattern_db(const gchar* filename, key_value_cb cb, int workerId)
> > {
> > if(patterndb[workerId] != NULL){
> > pattern_db_free(patterndb[workerId]);
> > }
> > patterndb[workerId] = pattern_db_new();
> > pattern_db_reload_ruleset(patterndb[workerId], configuration, filename);
> > pattern_db_set_emit_func(patterndb[workerId],
> pdbtool_pdb_emit_accumulate, cb);
> > return 0;
> > }
> >
> > This is just the C wrapper that internally call syslog-ng methods.
> >
> > Since I am using an array of patterndbs, I am calling the C code with
> multiple Go routines.
> >
> > Single iteration of the code is working fine.
> >
> > The issue is seen only with multiple go routines. Can we store the
> address of the C struct (when memory is allocated using calloc) on Go side
> in an array so that I can deallocate the memory using 'defer
> C.free(unsafe.Pointer(InitStruct))' when the callback is done?This should
> make multiple go routines to work...Am I right ?
>
> I don't know what this code does, but 

Re: [go-nuts] How to store the address of C struct on Go side in an array (cgo)

[Ian Lance Taylor]

On Thu, Jul 11, 2019 at 9:27 AM Nitish Saboo  wrote:
>
> Following is my C Code:
>
> PatternDB *patterndb[WORKERIDS];
>
> int load_pattern_db(const gchar* filename, key_value_cb cb, int workerId)
> {
> if(patterndb[workerId] != NULL){
> pattern_db_free(patterndb[workerId]);
> }
> patterndb[workerId] = pattern_db_new();
> pattern_db_reload_ruleset(patterndb[workerId], configuration, filename);
> pattern_db_set_emit_func(patterndb[workerId], pdbtool_pdb_emit_accumulate, 
> cb);
> return 0;
> }
>
> This is just the C wrapper that internally call syslog-ng methods.
>
> Since I am using an array of patterndbs, I am calling the C code with 
> multiple Go routines.
>
> Single iteration of the code is working fine.
>
> The issue is seen only with multiple go routines. Can we store the address of 
> the C struct (when memory is allocated using calloc) on Go side in an array 
> so that I can deallocate the memory using 'defer 
> C.free(unsafe.Pointer(InitStruct))' when the callback is done?This should 
> make multiple go routines to work...Am I right ?

I don't know what this code does, but the line

pattern_db_set_emit_func(patterndb[workerId], pdbtool_pdb_emit_accumulate, cb);

suggests that cb is being saved away for future use.  If that is
indeed the case then freeing the memory in Go will cause a dangling
pointer, leading to crashes as you see.

You should also double-check that each separate goroutine is using a
different "workerId", as duplication of workerId values could
certainly cause trouble when running concurrently.

Yes, it's fine to store the address of the C struct on the Go side, if
that helps.

Ian



> On Thu, Jul 11, 2019 at 9:39 PM Ian Lance Taylor  wrote:
>>
>> On Thu, Jul 11, 2019 at 7:16 AM Nitish Saboo  
>> wrote:
>> >
>> > I have the following function 'LoadPatternDB' where I am allocating memory 
>> > for a C struct.My C struct contains the callback function.
>> >
>> > 1)I cannot deference the struct in the same func 'LoadPatternDB' because I 
>> > get the following error when my callback function is called from C code:
>> >
>> > signal SIGSEGV: segmentation violation code=0x1 addr=0x7f1e00415341 
>> > pc=0x7f1e00415341]
>> >
>> > 2)The same code is running in multiple go routines.And because of that if 
>> > I don't deallocate the memory I get the following error:
>> >
>> > *** Error in `fatal error: bin/main': double free or corruption 
>> > (fasttop)unexpected signal during runtime execution: 0x7fd2b8588060 ***
>> >
>> > My question is:
>> >
>> > How can I store the address of the C struct (when memory is allocated 
>> > using calloc) on Go side in an array so that I can deallocate the memory 
>> > using 'defer C.free(unsafe.Pointer(InitStruct))' when the callback is done.
>> >
>> >
>> > 'InitStruct := (*C.Accumulatedparams)(C.calloc(1, 
>> > C.sizeof_struct_Accumulatedparams))'   I want to store this address on 
>> > Go side.
>> >
>> >
>> > Can some please guide me here ?
>> >
>> >
>> > syslogparser.go
>> > =
>> >
>> > func (obj SyslogParser) LoadPatternDB(opts Syslog, workerId int) {
>> > patterndbpath := C.CString(opts.Patterndb)
>> > defer C.free(unsafe.Pointer(patterndbpath))
>> > InitStruct := (*C.Accumulatedparams)(C.calloc(1, 
>> > C.sizeof_struct_Accumulatedparams))
>> > //defer C.free(unsafe.Pointer(InitStruct)) . <> > cannot do this here
>> > InitStruct.callback = (C.key_value_cb)(C.callback)
>> > InitStruct.data = C.int(workerId)
>> > C.load_pattern_db(patterndbpath, 
>> > (*C.Accumulatedparams)(unsafe.Pointer(InitStruct)), C.int(workerId))
>> > }
>> >
>> >
>> > //export Result
>> > func Result(key *C.char, value *C.char, value_len C.size_t, mapid C.int) {
>> > fmt.Println("Map Id: " + strconv.Itoa(int(mapid)))
>> > value_field := C.GoStringN(value, C.int(value_len))
>> > key_field := C.GoString(key)
>> > remap, ok := constants.FIELD_MAPPINGS[key_field]
>> > if ok {
>> > Check.result[int(mapid)][remap] = value_field
>> > //check.result[remap] = value_field
>> > } else {
>> > //check.result[key_field] = value_field
>> > Check.result[int(mapid)][key_field] = value_field
>> > }
>> > }
>> >
>> >
>> > cfuncs.go
>> > -
>> > package lib
>> >
>> > /*
>> >
>> > #include 
>> >
>> > // The gateway function
>> > void callback(char *key, char *value, size_t value_len, int mapid)
>> > {
>> > //printf("C.callOnMeGo_cgo(): called");
>> > void Result(const char *key, const char *value, size_t value_len, int 
>> > mapid);
>> > Result(key, value, value_len, mapid);
>> > }
>> > */
>> > import "C"
>> >
>> > syslog-node.h
>> > 
>> >
>> > #ifndef TEST_H_INCLUDED
>> > #define TEST_H_INCLUDED
>> >
>> > #include 
>> >
>> > typedef void (*key_value_cb)(const char* key, const char* value, size_t 
>> > value_len, int data);
>> > typedef struct Accumulatedparams{
>> > key_value_cb callback;
>> > int data;
>> > }Accumulatedparams;
>> > int initialize_engine(const char* filename, const char* module_path);
>> > int reload_pattern_db(const 

Re: [go-nuts] Re: [ANN] VictoriaMetrics - fast open source time series database written in Go

[Michael Jones]

details...

celeste:gg mtj$ ls -l ~/corpora/go/corpusZ.tar
-rw-r--r--  1 mtj  staff  92386304 Jul  4 02:27
/Users/mtj/corpora/go/corpusZ.tar

this is the Go corpus compressed in chunks and then gathered as a tar file.
92MB at zstd #19, original size is 752 311 514 bytes. (Zstd compresses some
large Go files 50:1)

Here is looking for strings in that tar's unarchived, decompressed, Go code
using gg (https://github.com/MichaelTJones/gg):

celeste:gg mtj$ gg -summary -log log -digits s pizza
~/corpora/go/corpusZ.tar
/Users/mtj/corpora/go/corpusZ.tar::blob_22.go: add(pair("blake", "eats
pizza"))
/Users/mtj/corpora/go/corpusZ.tar::blob_22.go: t.Fatalf("after pizza,
size = %d; want %d", d.dynTab.size, want)
/Users/mtj/corpora/go/corpusZ.tar::blob_22.go: "pizza",
/Users/mtj/corpora/go/corpusZ.tar::blob_22.go: "pizza",
/Users/mtj/corpora/go/corpusZ.tar::blob_22.go:
"piwatepizzapkonskowolayangroupharmacyshirahamatonbetsurgutsiracu" +
/Users/mtj/corpora/go/corpusZ.tar::blob_31.go: data:   `{"tags":
[{"list": [{"one":"pizza"}]}]}`,
/Users/mtj/corpora/go/corpusZ.tar::blob_31.go: output: "pizza",
/Users/mtj/corpora/go/corpusZ.tar::blob_65.go:
"raskaunbieidsvollpiwatepizzapkosaigawaplanetariuminanoplantation" +
/Users/mtj/corpora/go/corpusZ.tar::blob_99.go: add(pair("blake", "eats
pizza"))
/Users/mtj/corpora/go/corpusZ.tar::blob_99.go: t.Fatalf("after pizza,
size = %d; want %d", d.dynTab.size, want)
/Users/mtj/corpora/go/corpusZ.tar::blob_99.go: "pizza",
/Users/mtj/corpora/go/corpusZ.tar::blob_99.go: "pizza",
/Users/mtj/corpora/go/corpusZ.tar::blob_99.go:
"piwatepizzapkoninjamisonplanetariuminnesotaketakayamatsumaebashi" +
/Users/mtj/corpora/go/corpusZ.tar::blob_000137.go: {"test :\n```bash\nthis
is a test\n```\n\ntest\n\n:cool::blush:::pizza:\\:blush : : blush:
:pizza:", []byte("test :\n```bash\nthis is a
test\n```\n\ntest\n\n:\\:blush : : blush: ")},
/Users/mtj/corpora/go/corpusZ.tar::blob_000137.go: ":pizza:":
 "\U0001f355",
/Users/mtj/corpora/go/corpusZ.tar::blob_000137.go: pizzaMessage :=
emoji.Sprint("I like a :pizza: and :sushi:!!")
performance
  grep  16 matches
  work  752 311 514 bytes, 170 302 873 tokens, 22 927 078 lines, 176 files
  time  3.975375 sec elapsed, 25.803189 sec user + 0.985283 system
  rate  189 242 887 bytes/sec, 42 839 444 tokens/sec, 5 767 273 lines/sec,
44 files/sec
  cpus  7 workers (parallel speedup = 6.74x)
celeste:gg mtj$

This rate, 189 mb/sec, is on a 4 core 8 thread macbook pro and is the
average over the whole corpus, so reflects not just lexical tokenization of
752 MB of Go code, grep-like regular expression matching for "pizza", but
also Klaus' Go-only, native Zstandard decompression, which transforms the
92 MB tar file to the 752 MB of code. Here are timing numbers, per file,
for Zstd expansion: (gg -log log)

celeste:gg mtj$ cat log
2019/07/11 10:05:31.433048 scan begins
2019/07/11 10:05:31.433240 processing files listed on command line
2019/07/11 10:05:31.433324 processing tar archive
/Users/mtj/corpora/go/corpusZ.tar
2019/07/11 10:05:31.471641 206993 →  4023123 bytes (19.436×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_05.go.zst
2019/07/11 10:05:31.475658  97312 →  4889323 bytes (50.244×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_03.go.zst
2019/07/11 10:05:31.478435 588144 →  4058916 bytes ( 6.901×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_00.go.zst
2019/07/11 10:05:31.478751 252664 →  4343752 bytes (17.192×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_01.go.zst
2019/07/11 10:05:31.483804 254045 →  4245209 bytes (16.710×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_06.go.zst
2019/07/11 10:05:31.483819  93940 →  4666515 bytes (49.675×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_04.go.zst
2019/07/11 10:05:31.484640 212543 →  5266751 bytes (24.780×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_02.go.zst
2019/07/11 10:05:31.59 796173 →  5097981 bytes ( 6.403×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_12.go.zst
2019/07/11 10:05:31.605878 222357 →  4149988 bytes (18.664×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_13.go.zst
2019/07/11 10:05:31.606986 115654 →  5244204 bytes (45.344×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_08.go.zst
2019/07/11 10:05:31.621446 202508 →  4353542 bytes (21.498×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_10.go.zst
2019/07/11 10:05:31.624954 326016 →  4010657 bytes (12.302×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_11.go.zst
2019/07/11 10:05:31.632554 207580 →  4065186 bytes (19.584×)
 decompress and scan /Users/mtj/corpora/go/corpusZ.tar::blob_09.go.zst
2019/07/11 10:05:31.645472 174997 →  4008262 bytes (22.905×)
 decompress and scan 

Re: [go-nuts] Re: [ANN] VictoriaMetrics - fast open source time series database written in Go

[Aliaksandr Valialkin]

On Thu, Jul 11, 2019 at 7:29 PM Michael Jones 
wrote:

> I use Klaus' library to decompress ~GiB files that have been compressed by
> zstd command line (c/c++ code) at level 19. Works great.
>

Thanks for sharing this information!


> On Thu, Jul 11, 2019 at 9:10 AM Klaus Post  wrote:
>
>> On Thursday, 11 July 2019 17:37:09 UTC+2, Aliaksandr Valialkin wrote:
>>>
>>>
>>>
>>> This is really great idea! Will try implementing it.
>>>
>>> Does github.com/klauspost/compress support all the levels for data
>>> decompression? VictoriaMetrics varies compression level depending on the
>>> data type. It would be great if github.com/klauspost/compress could
>>> decompress data compressed by the upstream zstd on higher compression
>>> levels.
>>>
>>
>> Decompression will work for all input. It is implementing the full spec.
>>
>
Great! I filed feature request for implementing pure Go builds for
VictoriaMetrics -
https://github.com/VictoriaMetrics/VictoriaMetrics/issues/94 .


>
>> Compression has "Fastest" and "Default" implemented, roughly matching
>> level 1 and 3 in zstd in speed and performance. I plan on adding something
>> around level 7-9 (as Better) and level 19 (as Best). But for it to be
>> useful I have mainly focused on the fastest modes. I also am planning more
>> concurrency in compression and decompression for streams - blocks will
>> probably remain as single goroutines. For now I am taking a small break and
>> having a bit of fun revisiting deflate and experimenting with Snappy.
>>
>> If there is anything I can do to help feel free to ping me.
>>
>>
>> /Klaus
>>
>>
>>>
>>> --
>>> Best Regards,
>>>
>>> Aliaksandr
>>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/b12c7562-b3a6-426b-bb1c-a62fcfc41714%40googlegroups.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 a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/onlD1GIG00g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CALoEmQwocTkYXf7bn39mxpkhuF%2Bynogb8BC6YwzXa9%3Dj89%3DvQw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Best Regards,

Aliaksandr

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPbKnmA7sJRkG4FG6kV%3D%3D%2Bb9sGvM1HwkG%3Dejwwnpt%2BYpVG86SQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: [ANN] VictoriaMetrics - fast open source time series database written in Go

[Michael Jones]

I use Klaus' library to decompress ~GiB files that have been compressed by
zstd command line (c/c++ code) at level 19. Works great.

On Thu, Jul 11, 2019 at 9:10 AM Klaus Post  wrote:

> On Thursday, 11 July 2019 17:37:09 UTC+2, Aliaksandr Valialkin wrote:
>>
>>
>>
>> This is really great idea! Will try implementing it.
>>
>> Does github.com/klauspost/compress support all the levels for data
>> decompression? VictoriaMetrics varies compression level depending on the
>> data type. It would be great if github.com/klauspost/compress could
>> decompress data compressed by the upstream zstd on higher compression
>> levels.
>>
>
> Decompression will work for all input. It is implementing the full spec.
>
> Compression has "Fastest" and "Default" implemented, roughly matching
> level 1 and 3 in zstd in speed and performance. I plan on adding something
> around level 7-9 (as Better) and level 19 (as Best). But for it to be
> useful I have mainly focused on the fastest modes. I also am planning more
> concurrency in compression and decompression for streams - blocks will
> probably remain as single goroutines. For now I am taking a small break and
> having a bit of fun revisiting deflate and experimenting with Snappy.
>
> If there is anything I can do to help feel free to ping me.
>
>
> /Klaus
>
>
>>
>> --
>> Best Regards,
>>
>> Aliaksandr
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b12c7562-b3a6-426b-bb1c-a62fcfc41714%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQwocTkYXf7bn39mxpkhuF%2Bynogb8BC6YwzXa9%3Dj89%3DvQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to store the address of C struct on Go side in an array (cgo)

[Nitish Saboo]

Hi Ian,

Following is my C Code:

PatternDB *patterndb[WORKERIDS];

int load_pattern_db(const gchar* filename, key_value_cb cb, int workerId)
{
if(patterndb[workerId] != NULL){
pattern_db_free(patterndb[workerId]);
}
patterndb[workerId] = pattern_db_new();
pattern_db_reload_ruleset(patterndb[workerId], configuration, filename);
pattern_db_set_emit_func(patterndb[workerId], pdbtool_pdb_emit_accumulate,
cb);
return 0;
}

This is just the C wrapper that internally call syslog-ng methods.

Since I am using an array of patterndbs, I am calling the C code with
multiple Go routines.

Single iteration of the code is working fine.

The issue is seen only with multiple go routines. Can we store the address
of the C struct (when memory is allocated using calloc) on Go side in an
array so that I can deallocate the memory using 'defer
C.free(unsafe.Pointer(InitStruct))' when the callback is done?This should
make multiple go routines to work...Am I right ?
Thanks,
Nitish

On Thu, Jul 11, 2019 at 9:39 PM Ian Lance Taylor  wrote:

> On Thu, Jul 11, 2019 at 7:16 AM Nitish Saboo 
> wrote:
> >
> > I have the following function 'LoadPatternDB' where I am allocating
> memory for a C struct.My C struct contains the callback function.
> >
> > 1)I cannot deference the struct in the same func 'LoadPatternDB' because
> I get the following error when my callback function is called from C code:
> >
> > signal SIGSEGV: segmentation violation code=0x1 addr=0x7f1e00415341
> pc=0x7f1e00415341]
> >
> > 2)The same code is running in multiple go routines.And because of that
> if I don't deallocate the memory I get the following error:
> >
> > *** Error in `fatal error: bin/main': double free or corruption
> (fasttop)unexpected signal during runtime execution: 0x7fd2b8588060 ***
> >
> > My question is:
> >
> > How can I store the address of the C struct (when memory is allocated
> using calloc) on Go side in an array so that I can deallocate the memory
> using 'defer C.free(unsafe.Pointer(InitStruct))' when the callback is done.
> >
> >
> > 'InitStruct := (*C.Accumulatedparams)(C.calloc(1,
> C.sizeof_struct_Accumulatedparams))'   I want to store this address on
> Go side.
> >
> >
> > Can some please guide me here ?
> >
> >
> > syslogparser.go
> > =
> >
> > func (obj SyslogParser) LoadPatternDB(opts Syslog, workerId int) {
> > patterndbpath := C.CString(opts.Patterndb)
> > defer C.free(unsafe.Pointer(patterndbpath))
> > InitStruct := (*C.Accumulatedparams)(C.calloc(1,
> C.sizeof_struct_Accumulatedparams))
> > //defer C.free(unsafe.Pointer(InitStruct)) . < cannot do this here
> > InitStruct.callback = (C.key_value_cb)(C.callback)
> > InitStruct.data = C.int(workerId)
> > C.load_pattern_db(patterndbpath,
> (*C.Accumulatedparams)(unsafe.Pointer(InitStruct)), C.int(workerId))
> > }
> >
> >
> > //export Result
> > func Result(key *C.char, value *C.char, value_len C.size_t, mapid C.int)
> {
> > fmt.Println("Map Id: " + strconv.Itoa(int(mapid)))
> > value_field := C.GoStringN(value, C.int(value_len))
> > key_field := C.GoString(key)
> > remap, ok := constants.FIELD_MAPPINGS[key_field]
> > if ok {
> > Check.result[int(mapid)][remap] = value_field
> > //check.result[remap] = value_field
> > } else {
> > //check.result[key_field] = value_field
> > Check.result[int(mapid)][key_field] = value_field
> > }
> > }
> >
> >
> > cfuncs.go
> > -
> > package lib
> >
> > /*
> >
> > #include 
> >
> > // The gateway function
> > void callback(char *key, char *value, size_t value_len, int mapid)
> > {
> > //printf("C.callOnMeGo_cgo(): called");
> > void Result(const char *key, const char *value, size_t value_len, int
> mapid);
> > Result(key, value, value_len, mapid);
> > }
> > */
> > import "C"
> >
> > syslog-node.h
> > 
> >
> > #ifndef TEST_H_INCLUDED
> > #define TEST_H_INCLUDED
> >
> > #include 
> >
> > typedef void (*key_value_cb)(const char* key, const char* value, size_t
> value_len, int data);
> > typedef struct Accumulatedparams{
> > key_value_cb callback;
> > int data;
> > }Accumulatedparams;
> > int initialize_engine(const char* filename, const char* module_path);
> > int reload_pattern_db(const char* filename, Accumulatedparams *cb, int
> workerId);
> > int load_pattern_db(const char* filename, Accumulatedparams *cb, int
> workerId);
> >
> > #endif
>
>
> I don't see anything obviously wrong in your Go code, but it's
> impossible to answer your question without knowing what the C code
> does.  What you describe is consistent with C code that expects to
> retain the memory passed to load_pattern_db, or alternatively is also
> consistent with C code that does not expect to be called concurrently
> from multiple threads of execution.
>
> 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.
To view this discussion on 

Re: [go-nuts] Re: Not receiving email digests

[Ian Lance Taylor]

On Thu, Jul 11, 2019 at 8:28 AM Michael Rutter  wrote:
>
> I'm in the same boat of not receiving digests for a similar timeframe: both 
> for golang-nuts and golang-dev.
>
> -Mike
>
> On Wednesday, July 10, 2019 at 4:33:46 PM UTC-7, amr wrote:
>>
>> I appear to be no longer receiving the email digests daily. I last received 
>> a daily on 26th June, and then a single daily on 2nd July. I tried leaving 
>> the group and rejoining yesterday, to no avail!
>> Any ideas, please, moderator?


I have found a Google-internal bug report that appears to be related
to this problem (internal reference ID 136525507).  The Groups team
has deployed some temporary fixes as of yesterday (July 10) and are
working on a permanent fix.  I hope this helps.  I don't have any
other information.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWiSTfpjqHK2RSw9-2gq0mudhSNbA0e93pfZuY%3DsGWLBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: [ANN] VictoriaMetrics - fast open source time series database written in Go

[Klaus Post]

On Thursday, 11 July 2019 17:37:09 UTC+2, Aliaksandr Valialkin wrote:
>
>
>
> This is really great idea! Will try implementing it.
>
> Does github.com/klauspost/compress support all the levels for data 
> decompression? VictoriaMetrics varies compression level depending on the 
> data type. It would be great if github.com/klauspost/compress could 
> decompress data compressed by the upstream zstd on higher compression 
> levels.
>

Decompression will work for all input. It is implementing the full spec.

Compression has "Fastest" and "Default" implemented, roughly matching level 
1 and 3 in zstd in speed and performance. I plan on adding something around 
level 7-9 (as Better) and level 19 (as Best). But for it to be useful I 
have mainly focused on the fastest modes. I also am planning more 
concurrency in compression and decompression for streams - blocks will 
probably remain as single goroutines. For now I am taking a small break and 
having a bit of fun revisiting deflate and experimenting with Snappy.

If there is anything I can do to help feel free to ping me.


/Klaus
 

>
> -- 
> Best Regards,
>
> Aliaksandr
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b12c7562-b3a6-426b-bb1c-a62fcfc41714%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How to store the address of C struct on Go side in an array (cgo)

[Ian Lance Taylor]

On Thu, Jul 11, 2019 at 7:16 AM Nitish Saboo  wrote:
>
> I have the following function 'LoadPatternDB' where I am allocating memory 
> for a C struct.My C struct contains the callback function.
>
> 1)I cannot deference the struct in the same func 'LoadPatternDB' because I 
> get the following error when my callback function is called from C code:
>
> signal SIGSEGV: segmentation violation code=0x1 addr=0x7f1e00415341 
> pc=0x7f1e00415341]
>
> 2)The same code is running in multiple go routines.And because of that if I 
> don't deallocate the memory I get the following error:
>
> *** Error in `fatal error: bin/main': double free or corruption 
> (fasttop)unexpected signal during runtime execution: 0x7fd2b8588060 ***
>
> My question is:
>
> How can I store the address of the C struct (when memory is allocated using 
> calloc) on Go side in an array so that I can deallocate the memory using 
> 'defer C.free(unsafe.Pointer(InitStruct))' when the callback is done.
>
>
> 'InitStruct := (*C.Accumulatedparams)(C.calloc(1, 
> C.sizeof_struct_Accumulatedparams))'   I want to store this address on Go 
> side.
>
>
> Can some please guide me here ?
>
>
> syslogparser.go
> =
>
> func (obj SyslogParser) LoadPatternDB(opts Syslog, workerId int) {
> patterndbpath := C.CString(opts.Patterndb)
> defer C.free(unsafe.Pointer(patterndbpath))
> InitStruct := (*C.Accumulatedparams)(C.calloc(1, 
> C.sizeof_struct_Accumulatedparams))
> //defer C.free(unsafe.Pointer(InitStruct)) . < do this here
> InitStruct.callback = (C.key_value_cb)(C.callback)
> InitStruct.data = C.int(workerId)
> C.load_pattern_db(patterndbpath, 
> (*C.Accumulatedparams)(unsafe.Pointer(InitStruct)), C.int(workerId))
> }
>
>
> //export Result
> func Result(key *C.char, value *C.char, value_len C.size_t, mapid C.int) {
> fmt.Println("Map Id: " + strconv.Itoa(int(mapid)))
> value_field := C.GoStringN(value, C.int(value_len))
> key_field := C.GoString(key)
> remap, ok := constants.FIELD_MAPPINGS[key_field]
> if ok {
> Check.result[int(mapid)][remap] = value_field
> //check.result[remap] = value_field
> } else {
> //check.result[key_field] = value_field
> Check.result[int(mapid)][key_field] = value_field
> }
> }
>
>
> cfuncs.go
> -
> package lib
>
> /*
>
> #include 
>
> // The gateway function
> void callback(char *key, char *value, size_t value_len, int mapid)
> {
> //printf("C.callOnMeGo_cgo(): called");
> void Result(const char *key, const char *value, size_t value_len, int mapid);
> Result(key, value, value_len, mapid);
> }
> */
> import "C"
>
> syslog-node.h
> 
>
> #ifndef TEST_H_INCLUDED
> #define TEST_H_INCLUDED
>
> #include 
>
> typedef void (*key_value_cb)(const char* key, const char* value, size_t 
> value_len, int data);
> typedef struct Accumulatedparams{
> key_value_cb callback;
> int data;
> }Accumulatedparams;
> int initialize_engine(const char* filename, const char* module_path);
> int reload_pattern_db(const char* filename, Accumulatedparams *cb, int 
> workerId);
> int load_pattern_db(const char* filename, Accumulatedparams *cb, int 
> workerId);
>
> #endif


I don't see anything obviously wrong in your Go code, but it's
impossible to answer your question without knowing what the C code
does.  What you describe is consistent with C code that expects to
retain the memory passed to load_pattern_db, or alternatively is also
consistent with C code that does not expect to be called concurrently
from multiple threads of execution.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU2ACrQFZJB7k-%3DaOAWyFODB%2B6FNd%3DqUsj1XciV3GhV3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: [ANN] VictoriaMetrics - fast open source time series database written in Go

[Aliaksandr Valialkin]

On Thu, Jul 11, 2019 at 1:39 PM Klaus Post  wrote:

> On Sunday, 23 June 2019 20:09:48 UTC+2, Aliaksandr Valialkin wrote:
>>
>>
>>
>> On Sun, Jun 23, 2019 at 8:34 PM Jason E. Aten  wrote:
>>
>>> very nice.
>>>
>>> https://github.com/klauspost/compress  just added zstd all in Go, might
>>> be a lovely way to remove the CGO dependency.
>>>
>>
>> I'm keeping eye on it! Currently cgo version of zstd has slightly better
>> performance comparing to pure Go version - see
>> https://github.com/klauspost/compress/tree/master/zstd#performance
>>
>
> Actually, that is only the Datadog cgo package and only for specific write
> sizes. It ties your cgo package for levels 1 & 3 (the only ones currently
> implemented) for streaming performance.
>
> Either way, having it as an option for CGO_ENABLED=0 builds using the
> 'cgo' build tag, would probably make compiling/packaging it easier for a
> lot of people.
>

This is really great idea! Will try implementing it.

Does github.com/klauspost/compress support all the levels for data
decompression? VictoriaMetrics varies compression level depending on the
data type. It would be great if github.com/klauspost/compress could
decompress data compressed by the upstream zstd on higher compression
levels.

-- 
Best Regards,

Aliaksandr

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPbKnmCTEh8Z-48n%2BKBUu5nL7TDxoNL9bQb9sR0AzuuvZtPH8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Not receiving email digests

[Michael Rutter]

I'm in the same boat of not receiving digests for a similar timeframe: both 
for golang-nuts and golang-dev.

-Mike

On Wednesday, July 10, 2019 at 4:33:46 PM UTC-7, amr wrote:
>
> I appear to be no longer receiving the email digests daily. I last 
> received a daily on 26th June, and then a single daily on 2nd July. I tried 
> leaving the group and rejoining yesterday, to no avail!
> Any ideas, please, moderator?
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/eebec84d-c56b-4341-b218-eca6cdaa80de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Not receiving email digests

[amr]

I also have checked my spam, nothing there related.
However - last night I changed my account to receive each posted message 
individually rather than as a daily digest - I am now receiving everything. 
Maybe there is an issue with the digest process?

On Thursday, 11 July 2019 00:33:46 UTC+1, amr wrote:
>
> I appear to be no longer receiving the email digests daily. I last 
> received a daily on 26th June, and then a single daily on 2nd July. I tried 
> leaving the group and rejoining yesterday, to no avail!
> Any ideas, please, moderator?
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d7acd2d7-e54e-409c-9053-57e2fbb317e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] How to store the address of C struct on Go side in an array (cgo)

[Nitish Saboo]

Hi,

I have the following function 'LoadPatternDB' where I am allocating memory 
for a C struct.My C struct contains the callback function.

1)I cannot deference the struct in the same func 'LoadPatternDB' because I 
get the following error when my callback function is called from C code:

*signal SIGSEGV: segmentation violation code=0x1 addr=0x7f1e00415341 
pc=0x7f1e00415341]*

2)The same code is running in multiple go routines.And because of that if I 
don't deallocate the memory I get the following error:

 Error in `fatal error: bin/main': double free or corruption 
(fasttop)unexpected signal during runtime execution: 0x7fd2b8588060 

My question is:

How can I store the address of the C struct (when memory is allocated using 
calloc) on Go side in an array so that I can deallocate the memory using 
'defer C.free(unsafe.Pointer(InitStruct))' when the callback is done.


'InitStruct := (*C.Accumulatedparams)(C.calloc(1, 
C.sizeof_struct_Accumulatedparams))'  >*>>> I want to store this address on 
Go side.*


Can some please guide me here ?


syslogparser.go
=

func (obj SyslogParser) LoadPatternDB(opts Syslog, workerId int) {
patterndbpath := C.CString(opts.Patterndb)
defer C.free(unsafe.Pointer(patterndbpath))
InitStruct := (*C.Accumulatedparams)(C.calloc(1, 
C.sizeof_struct_Accumulatedparams))
/*/defer C.free(unsafe.Pointer(InitStruct)) . <

// The gateway function
void callback(char *key, char *value, size_t value_len, int mapid)
{
//printf("C.callOnMeGo_cgo(): called");
void Result(const char *key, const char *value, size_t value_len, int 
mapid);
Result(key, value, value_len, mapid);
}
*/
import "C"

syslog-node.h


#ifndef TEST_H_INCLUDED
#define TEST_H_INCLUDED

#include 

typedef void (*key_value_cb)(const char* key, const char* value, size_t 
value_len, int data);
typedef struct Accumulatedparams{
key_value_cb callback;
int data;
}Accumulatedparams;
int initialize_engine(const char* filename, const char* module_path);
int reload_pattern_db(const char* filename, Accumulatedparams *cb, int 
workerId);
int load_pattern_db(const char* filename, Accumulatedparams *cb, int 
workerId);

#endif

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/559ecb7d-f041-4381-884a-ecc49f204330%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Not receiving email digests

[HaWe]

Same here. It's been a few days now that I did not receive the email 
digests.
Don't know the exact date. Checked spam folder: also not there.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a10a12d2-47c2-4153-b030-3adf14ad5f33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: [ANN] VictoriaMetrics - fast open source time series database written in Go

[Klaus Post]

On Sunday, 23 June 2019 20:09:48 UTC+2, Aliaksandr Valialkin wrote:
>
>
>
> On Sun, Jun 23, 2019 at 8:34 PM Jason E. Aten  > wrote:
>
>> very nice.
>>
>> https://github.com/klauspost/compress  just added zstd all in Go, might 
>> be a lovely way to remove the CGO dependency.
>>
>
> I'm keeping eye on it! Currently cgo version of zstd has slightly better 
> performance comparing to pure Go version - see 
> https://github.com/klauspost/compress/tree/master/zstd#performance 
>

Actually, that is only the Datadog cgo package and only for specific write 
sizes. It ties your cgo package for levels 1 & 3 (the only ones currently 
implemented) for streaming performance.

Either way, having it as an option for CGO_ENABLED=0 builds using the 'cgo' 
build tag, would probably make compiling/packaging it easier for a lot of 
people.


/Klaus

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3b4a3573-f21a-4b5d-bbdb-6e3bcb4ff10c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Not receiving email digests

[Bojan Delić]

Same for me, I haven't received digest for a long time, from quick search 
of inbox dates that amr reported are similar in my case as well. 

I have checked spam and there is nothing there. 

On Thursday, July 11, 2019 at 1:48:46 AM UTC+2, Ian Lance Taylor wrote:
>
> On Wed, Jul 10, 2019 at 4:33 PM amr > 
> wrote: 
> > 
> > I appear to be no longer receiving the email digests daily. I last 
> received a daily on 26th June, and then a single daily on 2nd July. I tried 
> leaving the group and rejoining yesterday, to no avail! 
> > Any ideas, please, moderator? 
>
> Sorry, no ideas.  I see that you are on the list and signed up to 
> receive one message per day.  Everything I can see looks fine.  I have 
> no way to verifying that the messages are actually being sent or 
> anything, but likely they are.  Check your spam filters and logs. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d7c7e50b-65e2-4839-9ba3-b709b75978de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.