On Thu, Jan 21, 2021 at 10:21 PM Nicholas Yue wrote:
>
> /*
> #include "hello.c"
> */
> import "C"
Doing a #include of "hello.c" is unusual. That is most likely your
problem. The comment before the import "C" is handled as C code. C
code rarely does a #include of a .c file. Normally one does
Hi,
I am using Go 1.15 on Ubuntu 18.04
I am learning about cgo via the following tutorial
https://golang.org/cmd/cgo/
I have the following two files which I am able to run via
go run cgo_main.go
Knowing that it runs, I'd like to build it into an executable but I get
the fol
Hi all,
Recently, I found myself fishing for this capability. My use case was, in
an earlier PR, I wrote up a code like this
```
func foo(bar *typ) bool {
bar.mutex.RLock()
*defer bar.mutex.RLock() /*/ use bar.attributes in a read only mode and
compute a bool value
}
```
This was an
Looking briefly, seems interesting but slightly different. It seems that
the intent described in the paper is to endorse full blown functions as a
replacement to import statements.
It is useful insofar that it could rationalize the use of build constraints
in Go. But it is too expressive in tha
On Wed, Jan 20, 2021 at 4:22 PM atd...@gmail.com wrote:
> It' has probably been discussed somewhere but I am curious about what
> might have been the issues when considering an implementation of generics
> that would parameterized packages?
>
>
You can take a look at Standard ML / Ocaml "functors
Hi Drew,
Quoth Drew DeVault:
> With the help of some volunteers, we have already made modest,
> conservative improvements to godoc.org. Some features have been
> updated to work with JavaScript disabled, dead links and obsolete tools
> have been pruned, and our fork should be easier to use on your
>
>> I think the general rule of thumb I find agreeable is "the length of
>an
>> identifier should be inversely correlated to the distance between its
>> declaration and its use".
>>
>
Loosely correlated, perhaps.
I'll be honest. I have always found this advice to be rarely useful. It
certainl
