Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Marc-Antoine Ruel]

Sorry I wasn't clear. The static libraries are in a subdirectory because
the user should not care and these libraries are effectively third party
code.

This declares the generic code available everywhere:
https://github.com/periph/d2xx/blob/main/d2xx.go

One set of files declare the import that is OS and CPU arch appropriate,
e.g.
https://github.com/periph/d2xx/blob/main/d2xx_linux_amd64.go

Then another set of two files defines the OS specific code. In practice,
POSIX and windows;
https://github.com/periph/d2xx/blob/main/d2xx_posix.go
https://github.com/periph/d2xx/blob/main/d2xx_windows.go

A CGO_ENABLED=0 build gets instead redirected to
https://github.com/periph/d2xx/blob/main/d2xx_posix_no_cgo.go
but not on windows because this package uses dynamic linking on windows.
Adapt as appropriate in your use case.

I hope this helps.

M-A


Le lun. 16 oct. 2023, 21 h 13, Justin Israel  a
écrit :

>
>
> On Tuesday, October 17, 2023 at 10:40:33 AM UTC+13 Marc-Antoine Ruel wrote:
>
> I second Richard's suggestion. I used the same trick for
> https://github.com/periph/d2xx. This git repository contains a minimalist
> shim for the .a libraries and nothing else. It's designed to compile on any
> platform. It falls back to a scaffolding if the corresponding .a library is
> not present for the OS-arch combination or if CGO is disabled. It makes
> testing easier.
>
> Then a proper package under https://github.com/periph/host/tree/main/ftdi
> exposes a higher level abstraction for the user.
>
>
> With only headers and static libs in the thirdparty directory, is this
> package "go-gettable"?
> Will go make the subdirectory available in that case? It usually ignores
> if there is no Go source files.
>
>
> M-A
>
> Le lun. 16 oct. 2023, à 14 h 48, Mike Schinkel  a
> écrit :
>
> Hi Jan,
>
> I'm going to go out on a limb here and suggest looking at using Go's
> `embed` feature?
>
> https://blog.jetbrains.com/go/2021/06/09/how-to-use-go-embed-in-go-1-16/
>
> I have not tried it with C libraries so there may be numerous reasons why
> it may not work for your needs. For example, I do not know what is required
> to *"install"* the libraries so that might be your sticking point that
> embed would not address. But if building on the user's machine is the real
> problem and you can distribute pre-build binaries then this might work for
> you.
>
> Basically Go reads a `//go:embed` comment, converts your files into Go
> source code, compiles that code, and then provides a package that allows
> you to write those files to disk from an your Go app before you need to
> load the libraries.
>
> Maybe this will work for you?  If yes, would love to hear back how it
> worked out.
>
> -Mike
> On Monday, October 16, 2023 at 8:40:54 AM UTC-4 Bruno Albuquerque wrote:
>
> I guess you switched things here. Shared libraries (.so) need to be
> available at engine. Static libraries (.a) are bagged into the binary.
>
> -Bruno
>
>
> On Sun, Oct 15, 2023, 3:55 PM Jan  wrote:
>
> Thanks Tamas, this is useful information.
>
> One of my libraries is using a `.a` library -- as opposed to `.so`, which
> is another level of complexity, since the library has to be available in
> runtime, not only in compile time -- and I'm going to follow your
> "incantation" suggestion.
>
>
> On Sunday, October 15, 2023 at 7:55:55 AM UTC+2 Tamás Gulácsi wrote:
>
> Neither I see a convenient way.
> BUT if you add a .go file into the directories where your precompiled
> libraries live,
> then "go get" will download them too (and only those dirs that have .go
> files in it).
>
> So your next mission is to prepare the right #cgo CFLAGS LDFLAGS
> incantations to use those libraries.
>
> Jan a következőt írta (2023. október 14., szombat, 8:37:48 UTC+2):
>
> Thanks Tamás, I may not be understanding correctly, but after taking a
> look at github.com/godror/godror, and the odpi subdirectory,
> I see it is including all the `.c` files on the fly
> <https://github.com/godror/godror/blob/main/odpi/embed/dpi.c>.
>
> A couple of reasons immediately come to mind, that make this not a
> generically valid option:
>
> * ODPI library is all C code (see src
> <https://github.com/godror/godror/tree/main/odpi/src>) so it works
> including in Go: my dependencies are C++/Rust code, for which I write a
> small C wrapper (or for Rust just `extern "C"`). Also architecture
> dependent compilation is different in C++/C/Rust code ...
> * The C++ libraries I'm including have sub-dependencies of themselves (one
> of which is llvm). It uses Bazel to organize it, and to manually move all
> the required C++ files to a directory would be years of work :) Plus wo

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Marc-Antoine Ruel]

I second Richard's suggestion. I used the same trick for
https://github.com/periph/d2xx. This git repository contains a minimalist
shim for the .a libraries and nothing else. It's designed to compile on any
platform. It falls back to a scaffolding if the corresponding .a library is
not present for the OS-arch combination or if CGO is disabled. It makes
testing easier.

Then a proper package under https://github.com/periph/host/tree/main/ftdi
exposes a higher level abstraction for the user.

M-A

Le lun. 16 oct. 2023, à 14 h 48, Mike Schinkel  a
écrit :

> Hi Jan,
>
> I'm going to go out on a limb here and suggest looking at using Go's
> `embed` feature?
>
> https://blog.jetbrains.com/go/2021/06/09/how-to-use-go-embed-in-go-1-16/
>
> I have not tried it with C libraries so there may be numerous reasons why
> it may not work for your needs. For example, I do not know what is required
> to *"install"* the libraries so that might be your sticking point that
> embed would not address. But if building on the user's machine is the real
> problem and you can distribute pre-build binaries then this might work for
> you.
>
> Basically Go reads a `//go:embed` comment, converts your files into Go
> source code, compiles that code, and then provides a package that allows
> you to write those files to disk from an your Go app before you need to
> load the libraries.
>
> Maybe this will work for you?  If yes, would love to hear back how it
> worked out.
>
> -Mike
> On Monday, October 16, 2023 at 8:40:54 AM UTC-4 Bruno Albuquerque wrote:
>
>> I guess you switched things here. Shared libraries (.so) need to be
>> available at engine. Static libraries (.a) are bagged into the binary.
>>
>> -Bruno
>>
>>
>> On Sun, Oct 15, 2023, 3:55 PM Jan  wrote:
>>
>>> Thanks Tamas, this is useful information.
>>>
>>> One of my libraries is using a `.a` library -- as opposed to `.so`,
>>> which is another level of complexity, since the library has to be available
>>> in runtime, not only in compile time -- and I'm going to follow your
>>> "incantation" suggestion.
>>>
>>>
>>> On Sunday, October 15, 2023 at 7:55:55 AM UTC+2 Tamás Gulácsi wrote:
>>>
 Neither I see a convenient way.
 BUT if you add a .go file into the directories where your precompiled
 libraries live,
 then "go get" will download them too (and only those dirs that have .go
 files in it).

 So your next mission is to prepare the right #cgo CFLAGS LDFLAGS
 incantations to use those libraries.

 Jan a következőt írta (2023. október 14., szombat, 8:37:48 UTC+2):

> Thanks Tamás, I may not be understanding correctly, but after taking a
> look at github.com/godror/godror, and the odpi subdirectory,
> I see it is including all the `.c` files on the fly
> .
>
> A couple of reasons immediately come to mind, that make this not a
> generically valid option:
>
> * ODPI library is all C code (see src
> ) so it works
> including in Go: my dependencies are C++/Rust code, for which I write a
> small C wrapper (or for Rust just `extern "C"`). Also architecture
> dependent compilation is different in C++/C/Rust code ...
> * The C++ libraries I'm including have sub-dependencies of themselves
> (one of which is llvm). It uses Bazel to organize it, and to manually move
> all the required C++ files to a directory would be years of work :) Plus
> would require me to slave to maintain things in sync.
> * The C++ libraries take hours to compile ... I don't want to impose
> this to users of my libraries.
>
> I think the only way to work this out is distributing the pre-compiled
> C++/Rust libraries, so the Go simply refer to them (and we get the fast
> compilation times from Go). But then, how to best distribute them in an
> automatic fashion, so that users don't need to one by one figure out how 
> to
> install them (and clean up them later if they are no longer using...) ?
>
> Or maybe there is another convenient way I'm not seeing ?
>
>
> On Thursday, October 12, 2023 at 6:39:34 PM UTC+2 Tamás Gulácsi wrote:
>
>> Can't you build (make go build for you) those libraries?
>> For example, see github.com/godror/godror just includes the sources
>> of that third party library in an "odpi" subdir, and with
>> ```
>> /*
>> #cgo CFLAGS: -I./odpi/include -I./odpi/src -I./odpi/embed
>>
>> #include "dpi.c"
>>
>> */
>> import "C"
>> ```
>> it is compiled automatically.
>>
>>
>> Caveat: for "go get" to download a directory, it must include a
>> sth.go file ("require.go" in the odpi/* subdirs).
>> But it may work that your precompiled libs in a subdir, with a mock
>> .go file gets downloaded.
>> But how will it found by your lib/app ?
>>
>> 

Re: [go-nuts] Is there a gofmt flag to avoid reformatting comments?

[Marc Adkins]

GoLand IDE (Jetbrains) support found a solution. Per their instructions 
change the following pattern:

(update it in *Preferences | Editor | TODO*)
\/(\/|\*)[ ]*\btodo\b(.|\n)*(\*\/|)

It should highlight multiline TODOs without additional two spaces on the 
next line:
// TODO something something something
// something else
var x int

This is working for me.
On Wednesday, April 19, 2023 at 7:06:46 PM UTC-7 Dan Kortschak wrote:

> On Wed, 2023-04-19 at 14:30 -0700, Ian Lance Taylor wrote:
> > 
> > If you give us more details perhaps there is some common ground
> > available.  In particular, a sequence of lines where each line is
> > indented will be treated as a code block, and not reformatted.
>
> Related, I'd like to reiterate the concerns with quote rewriting (filed
> here https://go.dev/issue/54312) which is an accessibility issue.
>
>

-- 
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/f69fd010-0b7a-46e2-955e-8268e70cdfc5n%40googlegroups.com.

[go-nuts] Is there a gofmt flag to avoid reformatting comments?

[Marc Adkins]

I like gofmt a lot. I'm not as happy with godoc. Apparently the in the 1.19 
release gofmt started reformatting comments to be consistent with godoc. I 
missed this in the release notes (which I may not have read, *mea culpa*).

For a long time this wasn't an issue for me but recently I've had gofmt 
"fix" something that IMHO wasn't broken (and in the process break it for my 
purposes). OK, it's a weird edge case related to specially formatted 
comments that are important to my IDE. So not all that important.

Still, I'd like to be able to turn off comment reformatting. I've looked 
but there doesn't seem to be a gofmt flag to avoid comments being 
reformatted for godoc. Am I missing something?

-- 
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/bfbc0dc6-bbad-4f4c-9515-628b0c5f583fn%40googlegroups.com.

[go-nuts] Re: Trying to load DLL generated with CGO reflectively, stuck on WaitForSingleObject

['Marc Sherman' via golang-nuts]

Hi Cesar, I'm new to Go but have been a Win32 programmer for a very long 
time. It sounds like you've written a DLL in Go and you are attempting to 
call LoadLibrary() in your DLL's entry point. The entry point is generally 
known as DllMain() and it's a very restricted environment in terms of which 
APIs may be called while running in DllMain(). From 
https://learn.microsoft.com/en-us/windows/win32/dlls/dllmain:

"Warning - There are significant limits on what you can safely do in a DLL 
entry point. See General Best Practices 
<https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices>
 
for specific Windows APIs that are unsafe to call in DllMain. If you need 
anything but the simplest initialization then do that in an initialization 
function for the DLL. You can require applications to call the 
initialization function after DllMain has run and before they call any 
other functions in the DLL."

And the "General Best Practices" doc linked there states:

"You should never perform the following tasks from within DllMain 
<https://learn.microsoft.com/en-us/windows/win32/dlls/dllmain>:Call 
LoadLibrary 
<https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya>
 
or LoadLibraryEx 
<https://learn.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa>
 
(either directly or indirectly). This can cause a deadlock or a crash."

Hope this helps,
Marc
On Saturday, February 4, 2023 at 7:13:24 PM UTC-5 Cesar López wrote:

> When I use the library on a simple C program with LoadLibraryA(), it works 
> properly but with the DLL loaded in a virtual memory page happens something 
> different, it gets stuck in WaitForSingleObject after running the exported 
> method.
>
> I did all the base relocations and proper IAT refactor, even when the 
> image module gets loaded in the prefered address the following happens:
>
> I initialize the go runtime by running fist the entrypoint of the DLL 
> (after IAT and base relocations), it runs properly and the returns to the 
> main C program, after that I parse the EAT looking for the exported 
> function i.e OnProcessAttach, after locating the export by it's ordinal / 
> name I tried to execute it (process receives no arguments, and returns 
> nothing), and it starts running, then starts calling to 
> RtlInitializeCriticalSection and follows the system calls, after that it 
> just gets in a deadlock on WaitSingleObject (inside the go DLL), with 
> LastStatus C00D (STATUS_INVALID_PARAMETER) -but the exported function 
> doesn't receives any argument-
>
> Go DLL
>
> package main
> import "C"
> import (
> "unsafe"
> "syscall"
> )
>
> //export OnProcessAttach
> func OnProcessAttach() {
> const (
> NULL  = 0
> MB_OK = 0
> )
> caption := "Hola"
> title := "desdegoo"
> ret, _, _ := 
> syscall.NewLazyDLL("user32.dll").NewProc("MessageBoxW").Call(
> uintptr(NULL),
> uintptr(unsafe.Pointer(syscall.StringToUTF16Ptr(caption))),
> uintptr(unsafe.Pointer(syscall.StringToUTF16Ptr(title))),
> uintptr(MB_OK))
>
> if ret != 1 {
> return
> }
> return 
> }
>
> func main() {}
>
>
> C code:
>
>
> // resolve base relocations
> IMAGE_DATA_DIRECTORY relocations = 
> ntHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC];
> DWORD_PTR relocationTable = relocations.VirtualAddress + 
> (DWORD_PTR)dllBase;
> DWORD relocationsProcessed = 0;
>
> while (relocationsProcessed < relocations.Size)
> {
> PBASE_RELOCATION_BLOCK relocationBlock = 
> (PBASE_RELOCATION_BLOCK)(relocationTable + relocationsProcessed);
> relocationsProcessed += sizeof(BASE_RELOCATION_BLOCK);
> DWORD relocationsCount = (relocationBlock->BlockSize - 
> sizeof(BASE_RELOCATION_BLOCK)) / sizeof(BASE_RELOCATION_ENTRY);
> PBASE_RELOCATION_ENTRY relocationEntries = 
> (PBASE_RELOCATION_ENTRY)(relocationTable + relocationsProcessed);
> for (DWORD i = 0; i < relocationsCount; i++)
> {
> relocationsProcessed += sizeof(BASE_RELOCATION_ENTRY);
> if (relocationEntries[i].Type == 0)
> {
> continue;
> }
>
> DWORD_PTR relocationRVA = relocationBlock->PageAddress + 
> relocationEntries[i].Offset;
> DWORD_PTR addressToPatch = 0;
> ReadProcessMemory(GetCurrentProcess(), 
> (LPCVOID)((DWORD_PTR)dllBase + relocationRVA), , 
> sizeof(DWORD_PTR), NULL);
> addre

Re: [go-nuts] How to cast a multi-value?

['Marc Michael' via golang-nuts]

'Keith Randall' via golang-nuts  schrieb am
Di., 18. Mai 2021, 18:25:

> You can use a function call to do the cast:
>
> func byteErr2stringErr(b []byte, e error) (string, error) {
> return string(b), e
> }
> content, err := byteErr2stringErr(os.ReadFile(path))
>
> It's still using additional variables, but they are hidden inside the
> helper function.
> On Sunday, May 16, 2021 at 8:07:24 PM UTC-7 Kurtis Rader wrote:
>
>> On Sun, May 16, 2021 at 7:49 PM 'Marc Michael' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> as Go provides multi values I would expect that's possible to cast such
>>> a multi value. Do I see it correctly, that Go does not provide it?
>>>
>>> Example:
>>>
>>> os.ReadFile returns []byte, error.
>>> I want to cast the []byte to a string.
>>>
>>> content, err := os.ReadFile(path)
>>>
>>> Is it possible to cast the []byte directly to a string without using a
>>> second variable?
>>>
>>
>> No, it is not possible to transform the type of one return value in a 
>> multi-valued
>> expression such as a function call. Such syntactic sugar would have limited
>> usefulness and, in my opinion, is likely to decrease readability and thus
>> be a source of bugs. If you find yourself needing to perform such
>> conversions so often that such a feature is useful that suggests the APIs
>> you're using need to be changed.
>>
>
Hello,

thanks for the clarification. I have thought that I had something overseen.

I have thought about introducing a second variable of type string, but this
would lead to doubling of the memory usage, especaly as I don't now really
how much data there is. With the additional function I think this would not
a real problem, as the []byte would go away if the additional function
finishes.

Thanks all for your help. :-)

Kindly regards

>

-- 
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/CAEOc3dUsahY7W3o_6j%3DM6ycRMnpv6XXnHOr0tyXxperzZ%3DB9kg%40mail.gmail.com.

[go-nuts] How to cast a multi-value?

['Marc Michael' via golang-nuts]

Hello,

as Go provides multi values I would expect that's possible to cast such a
multi value. Do I see it correctly, that Go does not provide it?

Example:

os.ReadFile returns []byte, error.
I want to cast the []byte to a string.

content, err := os.ReadFile(path)

Is it possible to cast the []byte directly to a string without using a
second variable?

Kindly regards

-- 
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/CAEOc3dWn%3Dn%3DFNaQVhnu56yu9yaoVeJRin_m%2B7DNh8hvqV7Ck%2Bw%40mail.gmail.com.

[go-nuts] DeepCloning a datastructure

[Marc Schöchlin]

Hello List,

i am searching for a convenient way to deep-clone a nested datastructure.

My data structure looks like this:

(map[string]map[string]*processing.AccountingSet) (len=1) {
 (string) (len=16) "foo1.bar.com:443": (map[string]*processing.AccountingSet) 
(len=1) {
  (string) (len=3) "all": (*processing.AccountingSet)(0xc90060)({
   count: (int64) 90,
   sum: (int64) 8001480,
   codes: (map[int]int) (len=1) {
    (int) 301: (int) 90
   },
   classes: (map[int]int) (len=6) {
    (int) 0: (int) 90,
    (int) 50: (int) 0,
    (int) 500: (int) 0,
    (int) 1000: (int) 0,
    (int) 6000: (int) 0,
    (int) 3: (int) 0
   }
  })
 }
}

How can i make a exact, deep, and completely independent copy of that structure?

What i tried:
(c.stats contains the mentioned data structure which should by copied to 
c.stats)

import "github.com/ulule/deepcopier"

c.lastStats = map[string]map[string]*AccountingSet{}
err = deepcopier.Copy(c.stats).To(c.lastStats)
if err != nil {
        glog.Errorf("unable to clone : '%s'", err.Error())
}

This doesn't work. The target structure is empty after the copy operation.

Regards
Marc


-- 
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/c860e575-28a0-1642-b097-28f592a83e43%40256bit.org.

[go-nuts] Re: A possible issue with untyped literal numbers

[Marc Vertes]

Ok, thank you for your response.

Marc

Le jeudi 31 octobre 2019 19:07:34 UTC+1, alanfo a écrit :
>
> This in fact is correct behavior.
>
> As 100 is an untyped integer constant, 1e2 can not be implicitly converted 
> to the same type and so the % operation fails.
>
> You can fix it with:
>
> func main() { println(int(100) % 1e2) }
>
> Now 1e2 is converted to 'int' and all is well :)
>
> Alan
>
> On Thursday, October 31, 2019 at 5:13:48 PM UTC, Marc Vertes wrote:
>>
>> Hello,
>>
>> I see that the following code
>>
>> func main() { println(100 % 1e2) }
>>
>> is rejected by the compiler with "invalid operation: operator % not 
>> defined on untyped float"
>>
>> but the following
>>
>> func main() { i := 100; println(i % 1e2) }
>>
>> is happily accepted. Should I open an issue on this ? What should the 
>> normal behaviour be ?
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b450a394-0fb1-4fe5-b0f0-32d601424aab%40googlegroups.com.

[go-nuts] A possible issue with untyped literal numbers

[Marc Vertes]

Hello,

I see that the following code

func main() { println(100 % 1e2) }

is rejected by the compiler with "invalid operation: operator % not defined 
on untyped float"

but the following

func main() { i := 100; println(i % 1e2) }

is happily accepted. Should I open an issue on this ? What should the 
normal behaviour be ?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0a47bee7-6953-4f14-9dfc-d0c18076b2aa%40googlegroups.com.

Re: [go-nuts] Re: Handling connection retries on a highly-available service

[marc . zahn]

I don't get it. Why are they supposed to be dropped only because the 
logging service is down?

Making a service between P and the logger is an interesting way to go
>
Another service which could be down then as well? Why not a Queue? 

Am Donnerstag, 14. Februar 2019 10:05:40 UTC+1 schrieb Michel Levieux:
>
> Hello everyone, thx for all your interesting answers!
>
> I think the fact that when the logger's down, the requests have to be 
> dropped (not queued, maybe I was not clear enough about that in my first 
> message) restrains our possibilities. Making a service between P and the 
> logger is an interesting way to go. For the moment we have made something 
> quite simple with atomic and some goroutines cooperating to know if the 
> connection is still correct, or to try reconnect when it's not, but I think 
> we will come back on that later.
>
> Le mer. 13 févr. 2019 à 14:54, Dany Xu  > a écrit :
>
>> As discuss above, i think the answer is decoupling the P and logger, 
>> storing the logs when the logger is down.The push and pull pattern would be 
>> better.The p sends all logs and the logger pulls all logs.Just keep a 
>> bigger storage for un-consumed logs.Queue may be is a better way but using 
>> a single storage.
>>
>> 在 2019年2月12日星期二 UTC+8上午12:34:46，Michel Levieux写道：
>>>
>>> Hi guys. I need a little help here.
>>>
>>> I work in a digital marketing company, where we have a program that 
>>> receives a lot of requests every second (counted in thousands) and logs its 
>>> behaviour via a logger that runs on another server. We are currently trying 
>>> to implement a connection-retry system between this program and its logging 
>>> API. What we want is :
>>>
>>> - We have a main program - let's call it P
>>> - P sends logs to the logger in multiple goroutines.
>>> - Sometimes we might need to shut down the logger (for maintenance or 
>>> anything)
>>> - We want P to keep running when the logger's down
>>> - Once the logger's up again, P must Dial it back automatically and 
>>> repair the *bufio.Writer associated with it
>>>
>>> Would you guys know a way not to check each single Read/Write if the 
>>> logger's up?
>>>
>>> Up to here we have thought of using atomic, mutexes and context for 
>>> synchronization, but the issues we face are the following:
>>>
>>> - mutexes create "pending" requests, since there's no way to check if a 
>>> mutex is locked or not
>>> - we're not really sure about the right way to use context for this 
>>> specific case
>>> - we'd like to avoid using atomics as much as possible, notably about 
>>> this quote from the docs : "*Except for special, low-level 
>>> applications, synchronization is better done with channels or the 
>>> facilities of the sync package*"
>>>
>>> In the end, what we're looking for is to reach a minimal checking 
>>> frequency (is connection up? do something, else do nothing), the ideal 
>>> being not to have to check anything.
>>>
>>> Have you guys already faced such problematics in the past? What 
>>> solutions have you come up with?
>>>
>>> Many thx in advance for your help!
>>>
>> -- 
>> 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...@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: Handling connection retries on a highly-available service

[marc . zahn]

>
> What about queuing
>

I cannot edit my post so a new answer here with more explanation: Just have 
a RabbitMQ or whatever in between and every logging sends a message to it 
while the logging service consumes it. As long as the logging service is 
down the messages remain in the queue.

Your retry approach has another doownside: What if the logging service is 
down for minutes or even hours? 

-- 
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: Handling connection retries on a highly-available service

[marc . zahn]

What about Queuing?

-- 
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: Go could really use a while statement

[Marc]

I'm still not convinced this topic is not some kind of elaborate joke.

On Tuesday, May 1, 2018 at 1:11:04 PM UTC+2, Hugh Fisher wrote:
>
>
> Another observation from this novice Go programmer: I'm puzzled why
> there's no while statement.
>
> I know it's possible to use a for, but it doesn't feel right to me. I 
> always
> think of for loops as for iterating over data structures. Originally just
> arrays, but languages like Python and Objective-C have extended for
> loops to other collections as well. "Looping until some condition is met"
> for me is a different control structure and needs a different keyword.
>
> There'd be overlap with the for statement, but if-then-else and switch
> with boolean case overlap too.
>
> And since while has been a reserved keyword in a lot of programming
> languages for many decades, I would bet a reasonable amount of
> money that a while statement could be added to Go right now and not
> break anyone's production code.
>
> cheers,
> Hugh Fisher
>
>

-- 
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: How to limit what the `go get` command is able to import

[paraiso . marc]

> Our internal packaging teams biggest worry is that we don't want someone 
to download something to their development laptop, compile the code into a 
standalone binary, then deploy that out to our container platforms.

That's not really a problem with Go but an organizational problem. 

You don't want people to download stuff from the internet? use a firewall 
disallowing people from accessing the internet. Anybody can go on github, 
click on a link and get a zip with some source code. How are you going to 
deal with that? it has nothing to do to with Go. Either you trust your 
developers with their intelligence, or you don't and you don't allow them 
to deploy anything on your container platforms without significant code 
review from an accredited developer who will be the only one authorized to 
deploy anything on your container platforms.


Le vendredi 2 mars 2018 11:59:13 UTC+6, Brendan O'Dwyer a écrit :
>
> Yes(technically) our deploys are controlled via gitlab. 
>
> Our internal packaging teams biggest worry is that we don't want someone 
> to download something to their development laptop, compile the code into a 
> standalone binary, then deploy that out to our container platforms.
>
> In our production environment this isn't even an issue because we can 
> can't even reach out to the internet in builds/deploys because its limited 
> to only internal locations. Their concern is that in development people 
> could `go get` packages that are not approved, then deploy those. While 
> that is super cool and awesome in open source worlds, unfortunately I work 
> for a bank that really likes to restrict and limit things so that they are 
> as secure as can be.
>
> On Wednesday, February 21, 2018 at 4:18:54 PM UTC-6, matthe...@gmail.com 
> wrote:
>>
>> Are the builds and deployment controlled? The command “go list” can be 
>> used to simplify parsing the imports in each package, so a script could 
>> check that every import is either an allowed standard library package or 
>> one matching your internal URL.
>>
>> Matt
>>
>> On Wednesday, February 21, 2018 at 11:37:35 AM UTC-6, Brendan O'Dwyer 
>> wrote:
>>>
>>> My company wants to start using go more, and traditionally when we use 
>>> java and python, when we package them for the developer laptops we override 
>>> settings and configs for the installs to point to our internal Artifactory 
>>> so that we don't have developers using packages that haven't been ok'd for 
>>> use. I was wondering if there was anyway to do this or configure go to 
>>> limit what its allowed to import from the open internet with the `go get` 
>>> command?
>>>
>>

-- 
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: Gobot Beaglebone Black GPIO question...

[Marc-Antoine Ruel]

Gobot is great if you want to delegate the "event loop".

If you want to keep control, you may want to take a look periph.io, which
supports interrupt based edge detection
, so no need to do a
busy loop. Which library to use depends about how you want to structure the
control loops, and that's why the two libraries are so different.

Side note; if you care about high performance GPIO
, we're looking to have PRU support
 which I feel is more useful
on T.I. CPUs than memory mapped GPIO ,
unlike for Broadcom and Allwinner CPUs.

Thanks,

M-A

2018-02-12 8:36 GMT-05:00 Silviu Capota Mera :

> If you have more time to spare on this project, try to circumvent the
> events / subscriber functionality. Try to see if you can read directly from
> the adaptor:
>
> https://github.com/hybridgroup/gobot/blob/master/platforms/beaglebone/
> beaglebone_adaptor.go#L151
>
> so inside your work function, you would do:
> *dVal, err := beagleboneAdaptor.DigitalRead("P8_8")*
> *if err != nil {*
> *  fmt.Println("Error reading the pin: ", err)*
> *  return*
> *}*
> *fmt.Println("Pin read correctly, the value is: ", dVal)*
>
> Then you would run the program while holding the button on, and off,
> respectively. This way you can tell whether the most basic part of the
> gobot subsystem does its job. That would be a first start at debugging.
> Otherwise, just circumvent it, and read the /sys/class/gpio/[your number]
> through the file system api
>
>
>
> On Mon, Feb 12, 2018 at 1:41 AM, Curtis Paul 
> wrote:
>
>> I'm at a loss...
>>
>> https://godoc.org/gobot.io/x/gobot#Eventer
>>
>> I think the first thing is that I'm not sure I understand how to diagnose
>> this codehow to validate it's doing what I think it may or may not be
>> doing.
>>
>> --
>> 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/to
>> pic/golang-nuts/y6ZYXVsfvS0/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>

-- 
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] dep: Updating timestamps?

[Marc Abramowitz]

If I run `dep ensure` and it doesn't actually pick up any new code, a `go 
install -v` will still take a while, presumably because `dep ensure` is 
updating the timestamps of stuff, even if it didn't change.

```
$ ls -ld vendor/github.com/behance/go-common/kvwrapper_etcd/ 
vendor/github.com/behance/go-common/kvwrapper_etcd/*
drwxr-xr-x  3 abramowi staff  102 Nov 01 13:08 
vendor/github.com/behance/go-common/kvwrapper_etcd/
-rw-r--r--  1 abramowi staff 2403 Nov 01 13:08 
vendor/github.com/behance/go-common/kvwrapper_etcd/kvwrapper_etcd.go

$ dep ensure

$ ls -ld vendor/github.com/behance/go-common/kvwrapper_etcd/ 
vendor/github.com/behance/go-common/kvwrapper_etcd/*
drwxr-xr-x  3 abramowi staff  102 Nov 01 13:14 
vendor/github.com/behance/go-common/kvwrapper_etcd/
-rw-r--r--  1 abramowi staff 2403 Nov 01 13:14 
vendor/github.com/behance/go-common/kvwrapper_etcd/kvwrapper_etcd.go
```

Is it reasonable to ask whether `dep ensure` could be made to not update 
the timestamp if nothing changed? I might be able to work on it (no 
promises), if it's deemed reasonable.

Marc

-- 
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: Write a program for Linux in Go lang which can run any command (of coder's choice) on another machine (privately or publicly accessible) and prints its output.

[paraiso . marc]

sounds like homework that should be done by the student, not the community. 

Le mardi 11 avril 2017 00:42:32 UTC+2, Owais Hashmi a écrit :
>
> Write a program for Linux in Go lang which can run any command (of coder's 
> choice) on another machine (privately or publicly accessible) and prints 
> its output.
>

-- 
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: Disadvantage of Go

[paraiso . marc]

>  Some time ago I collected a number of alternatives to using generics - 
see: https://appliedgo.net/generics

None of these alternatives really solve any real problem generics would 
solve. Generics are types, just like first class functions. Lamenting on 
the lack on generics is useless as well, Go will never have generics 
because of forward compatibility. 

But let's not pretend than there is an alternative to generics "people 
can't see" within Go. Go just wasn't built for code re-use in mind or 
writing abstractions at all due to the lack of polymorphism in the 
language. So people have to write specialized code when it comes to writing 
logic involving containers, that's the only truth there is.

> If you have a particular problem and you think, "I do need generics to 
implement that!", then you might become blind for other solutions. 

It's not being blind to another solution, every other solution has 
drawbacks generics don't have. Code generation involve writing 
pre-processors and maintaining manifests, opting out of Go type system with 
interface{} everywhere is obviously problematic. That's not solving what 
generics are here for in languages such as Java C# or Haskell. Basically 
you are asking developers to pay a price the compiler doesn't want to pay. 
Let's not patronize people who see the obvious flaw in that logic.

Again while it is useless to complain, people are complaining for a good 
reason, it can be difficult to understand what led to the absence of 
generics at first place in Go design. People coming from 
C,Python,Javascript and Ruby might not care, people coming from Java, C# or 
Haskell will have harder time working around the lack of generics in Go 
because they are used to that feature to solve their problems. 

To the latter I'd say that if Go feels tedious for a task then use 
something else, really. Go wasn't designed to please people who like 
expressive static type systems. There are many alternatives such as D, 
Ocaml, ... 

Le samedi 14 janvier 2017 10:35:33 UTC+1, Christoph Berger a écrit :
>
> Hi Yu,
>
> Generics have their use cases, e.g. when designing general data containers 
> or in the context of numeric computation (matrix type of int, float, etc). 
> In other areas, however, their use may be overrated. 
>
> If you have a particular problem and you think, "I do need generics to 
> implement that!", then you might become blind for other solutions. 
>
> Some time ago I collected a number of alternatives to using generics - 
> see: https://appliedgo.net/generics
>
> Best,
> Christoph
>
>
> On Saturday, January 14, 2017 at 7:42:43 AM UTC+1, Yu Liu wrote:
>>
>> Agree.
>>
>> Only generics missing is disadvantage of Go.
>>
>> Yu
>>
>> On Friday, January 13, 2017 at 10:56:07 AM UTC-8, simon place wrote:
>>
>>> sorry but for me, excepting generics and maybe a float32 maths lib, 
>>> these are all just your problem.
>>>
>>> particularly wrong is the idea of native conversion of bools to/from 
>>> numbers, albeit widespread and long-standing, perpetuating these mistakes 
>>> just means preventing any development of languages.
>>>
>>

-- 
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: Proposal for a succinct error return syntax

[paraiso . marc]

But you're not going to get any new syntax accepted by the go team anyway, 
certainly not a new operator. You know that already. 

Le vendredi 6 janvier 2017 11:04:38 UTC+1, xjru a écrit :
>
> As I said, this syntax doesn't help, because it puts file into the scope 
> of the if block where we often don't want it. Reformatting it doesn't 
> change that.
>
>

-- 
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: Proposal for a succinct error return syntax

[paraiso . marc]

It would be simpler if Go fmt would let people write if statements on a 
single line :

if file,err := os.Open(fname) ; err!=nil { return err }  

Here, no need for new syntax and still readable while reducing the 
conditional noise. And everybody could be happy.

Le vendredi 6 janvier 2017 01:35:14 UTC+1, xjru a écrit :
>
> Here are some examples for valid error returns according to my proposal:
>
>
> file, err := os.Open(fname) ||| return err
>
> file, err := os.Open(fname) ||| panic(err)
>
> file, err := os.Open(fname) ||| return errors.Wrap(err, "too bad")
>
>
> The third example uses the Wrap function from github.com/pkg/errors. The 
> ||| operator is not important. It could be any operator, but the idea 
> behind the tripple bar is to signal a special kind of or. I can imagine 
> using the keyword "orr" instead.
>
> The semantics is pretty simple. If there is an (possibly multiple) 
> assignment whose last component conforms to the error interface, then it 
> may be followed by ||| and a single statement that must either return or 
> panic.
>
> You might argue that this isn't much longer:
>
> if file, err := os.Open(fname); err != nil {
> return err
> }
>
> However, this has the unfortunate side effect of putting file into the 
> scope of the if block. That's why we often have to use
>
> file, err := os.Open(fname)
> if err != nil {
> return err
> }
>
> I think my proposal has a couple of benefits.
>
>- It is perhaps not too magical (just a little bit because the 
>condition is implied by the ||| operator).
>- I doesn't obscure the clear view on the assignment statement itself 
>(unlike Rust's try! macro).
>- The keywords return or panic make it very clear what happens to 
>control flow (unlike Rust's try! macro).
>
> It does have the drawback that it is a unique special case for errors not 
> based on a more general language facility. It makes the language a little 
> bit more complex. But I think errors are frequent enough to deserve a 
> little bit of syntactic sugar.
>
> Apologies if this has been discussed to death.
>
>

-- 
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: Looking for Golang counterpart to 'params' in Python

[paraiso . marc]

>
> response = requests.request("GET", url, data=payload, headers=headers, 
> *params=params*)



if auth is a header then set the appropriate header :

https://golang.org/pkg/net/http/#Header.Set

if it is basic auth you need to implement then look at the spec : 

https://en.wikipedia.org/wiki/Basic_access_authentication

You didn't explain what you expect "auth" or "params" to be . 


Le mardi 13 décembre 2016 06:46:23 UTC+1, bet...@google.com a écrit :
>
> Hi,
>
> In Python, I can include params like this:
>
> =
>
> *params = {'auth': ''}*
>
> response = requests.request("GET", url, data=payload, headers=headers, 
> *params=params*)
>
> =
>
> Any pointers on how Golang does this?
>
> Thanks,
> Betsy
>

-- 
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 I return a value or pointer?

[paraiso . marc]

The first question you need to ask yourself is are you going to use errors 
as values ( if err == myerrors.ErrValue ) or errors as types ( if e,ok:= 
err.(*myerrors.ErrType ; ok ) 

Le samedi 10 décembre 2016 20:10:26 UTC+1, Jon a écrit :
>
> I would like to know what my default practice should be when returning 
> structs from functions. Should I return a value or a pointer? (Assume I 
> don't need the functionality of returning a pointer and my struct contains 
> at most one simple field so a vast copy isn't needed if I return a value.)
>
> A specific example could be the errors package 
>  with errors.New. 
>
> The New function is implemented by returning an errorString pointer: 
> 
>
> func New(text string) error {
> return {text}
> }
>
> Could it just as easily have been implemented by returning an errorString 
> value ? If so why was the pointer 
> return chosen over value return?
>
> func New(text string) error {
> return errorString{text}
> }
>
> Could it also have been implemented as below 
>  which looks even simpler?
>
> func New(text string) error {
> return errorString(text)
> }
> // errorString is a trivial implementation of error.
> type errorString string
>
> func (e errorString) Error() string {
> return string(e)
> }
>
> What was the thought process that went into the implementation of the 
> errors package? Were the latter two implementation options I suggest 
> considered? If so why were they disregarded? Performance? Coding standards? 
> Heap allocation benefits?
>

-- 
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: Extending objects / methods

[paraiso . marc]

>
> The declared type does not inherit any methods 
>  bound to the existing 
> type, but the method set  of an 
> interface type or of elements of a composite type remains unchanged:


https://golang.org/ref/spec#Type_declarations

You need to use another strategy like struct embedding which *may *or *may 
not* work depending to your use case

A field declared with a type but no explicit field name is an *anonymous 
> field*, also called an *embedded* field or an embedding of the type in 
> the struct. An embedded type must be specified as a type name T or as a 
> pointer to a non-interface type name *T, and T itself may not be a 
> pointer type. The unqualified type name acts as the field name.


type xadvanced struct {
*x
}
func(x *xadvanced)increment(){
   x.y ++
   fmt.Println(x.y)
}

I'd advise you do read the spec at least once, it's short and concise .


Le vendredi 2 décembre 2016 16:25:50 UTC+1, Slawomir Pryczek a écrit :
>
> Hi Guys,
>
> i want to make something like this
>
> type si struct {
>
> s *sync_task.Sync_task
>
> }
>
>
> func (this *si) Process() {
>
>
>... some code here ...
>
>this.Process();
>
> }
>
>
>
> Basically i want to extend object in another package... and this works. 
> Now i'd just want to extend it without creating "real" struct, code
>
> type x struct {
> y int
> }
> type xadvanced *x
>
> func (this *x) increment() {
> this.y++
> fmt.Println(this.y)
> }
>
> test2 := xadvanced()
> test2.increment() ---> ERROR
>
> https://play.golang.org/
>
> What im doing wrong and how to access methods of x object when having 
> pointer to xadvanced...
>

-- 
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: Run some extra setup on each test

[paraiso . marc]

You can use sub-tests 

https://blog.golang.org/subtests

if you need to pass some data to a subtest you can use closures like 

func(data Data) func ( t *testing.T) {
  return func( t *testing.T) {
  print(data)
   }
}

If you need a more traditional setup/teardown fixture based test runner, 
then you need to use something else like Go convey. Granted it means slower 
tests.

Le vendredi 2 décembre 2016 14:48:53 UTC+1, Jérôme LAFORGE a écrit :
>
> Hello all,
> Do you know an elegant workaround that allows to execute extra setup on 
> each test (kind of TestMain but for each test) ?
> If not, did you plan to add this kind of feature into next release of Go ?
>
> Thank in advance.
> BR
> Jérôme
>

-- 
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: Interface help

[paraiso . marc]

Just create a slice of GoNoGoer 

var evals []GoNoGoer 

now you DO NOT need a type assertion like that 

if ok := eval.(GoNoGoer); ok // REMOVE that line


Le mercredi 30 novembre 2016 17:59:07 UTC+1, sc28 a écrit :
>
> I'm trying to better understand how to properly use interfaces and created 
> this scenario:
>
> Let's say I have an 'evaluator' program, that over time will want to add 
> more and more evaluations of a Go-NoGo nature (Nasa?)
>
> Here's want I was trying:
>
> // My Go-NoGo interface - method should return true/false and an error is 
> false
> type GoNoGoer interface {
> Eval() (bool, error)
> }
>
>
> Here's a couple of concrete evaluation types:
> --
>
> type Evaluation1 struct {
> Data string
> }
>
> func (a *Evaluation1) Eval() (bool, error) {
> isOk := a.DoMyEvaluationWithTheData()
> if !isOk {
> return false, fmt.Errorf("evaluation failed because ...")
> }
> return true, nil
> }
>
> type Evaluation2 struct {
> SomeData string
> MoreData int64
> }
>
> func (a *Evaluation2) Eval() (bool, error) {
> isOk := a.DoMyEvaluationWithTheStructData()
> if !isOk {
> return false, fmt.Errorf("evaluation failed because ...")
> }
> return true, nil
> }
>
> --
>
> In main - iterate over all the evaluations and print the results of Eval() 
>
> func main() {
> one := Evaluation1{Data: "abcabcabc"}
> two := Evaluation2{SomeData: "xyzxyz", MoreDate: 128}
>
> var evals []interface{}<-- So I want a slice of evaluations 
> (all implemented as various structs)  - probably not correct to use 
> interface{}???
> evals = append(evals, one)
> evals = append(evals, two)
>
> // range over the slice, and if the object has implemented the Eval() 
> method execute it and print the results  (doesn't work)
> for _, eval := range evals {
> if ok := eval.(GoNoGoer); ok { <-- This also is wrong, I want to go 
> the other direction (from concrete to interface)
> isOk, err := eval.Eval()
> fmt.Println(ok, err)
> }
> }
> }
>
>
> I'd appreciate the slap across the head pointing out where I'm missing the 
> boat!
>
> TIA
>

-- 
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] Type statement in blocks vs global

[paraiso . marc]

I'm not sure what you mean. 

types that reference each others in a type declaration are allowed when 
declared globally , but not in a block ( ? ) 

i.e. :

declaring Foo and Bar outside main would work , declaring them inside main 
doesn't . I wanted to declare them inside an example function in order for 
them to show up in the docs since the latter only prints the body of 
example functions (func ExampleFoo ...) . So I was asking why it worked 
that way. Since a type can only be declared once in a scope, the order in 
which they are declared shouldn't matter ? so they could reference each 
others like in my code snippet. thanks. 

Le lundi 28 novembre 2016 11:54:39 UTC+1, Jan Mercl a écrit :
>
> On Mon, Nov 28, 2016 at 11:46 AM  
> wrote:
>
> > Is there an alternative aside from declaring types globally ? 
>
> Unfortunately, the problem to solve is not defined, only the solution 
> tried and failed is, so I don't know if this can help: 
> https://play.golang.org/p/9btAagXDpM
>
> -- 
>
> -j
>

-- 
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] Thinking OO virtual function in Go

[paraiso . marc]

interfaces only work on methods. 

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

Name, Age , ... are not methods they are fields.You need to make them part 
of Speaker interface by using methods instead of fields.

Le mardi 22 novembre 2016 23:03:54 UTC+1, Tong Sun a écrit :
>
>
>
> On Tue, Nov 22, 2016 at 4:29 PM, Jesse McNelis wrote:
>
>> On Wed, Nov 23, 2016 at 8:16 AM, Tong Sun wrote:
>> > Hi,
>> >
>> > How to architect the OO's virtual function in Go?
>> >
>> > Please take a look at this (not working) Go program
>> > https://play.golang.org/p/qrBX6ScABp
>> >
>> > Please think of the "func Output()" as a very complicated function that 
>> I
>> > only want to define once at the base level, not to duplicate into each 
>> sub
>> > classes.
>> >
>> > How can I make it works so that the last output statement, instead of 
>> being,
>> >
>> > fmt.Printf("[%v] %s: [%0.2f]\n", k, v.Name(), v.Area())
>> >
>> >
>> > will be this instead:
>> >
>> > fmt.Printf("[%v] %s\n", k, v.Output())
>> >
>>
>> You define a function:
>>
>> func Output(s Shape) string {
>>return s.Name() + "'s area size is " + s.Area()
>> }
>>
>> Go uses interfaces for polymorphism.
>> Other OOP languages can use inheritance for polymorphism too, but Go
>> doesn't have inheritance.
>>
>
> Thanks Jesse. That works. 
>
> However I just realized that it is only part of my problem. 
>
> I have a huge list of common variables that I defined in my "base class", 
> changing it from a member function to a pure function causes almost every 
> single variable now undefined. 
>
> I can demonstrate the problem with this code
> https://play.golang.org/p/QjCtD9rGpa
>
> So, once again, thinking in OO, I'll define all of the common variables in 
> base class, and common functionalities in virtual functions. How to make 
> that idea work in Go?
>
> For the above specific code, how to easily make "func Output" works?
>
> 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] Re: Rendering absolute URLs for a hypermedia API

[paraiso . marc]

With gorilla/mux you can use named routes :

r := mux.NewRouter() r.HandleFunc("/articles/{category}/{id:[0-9]+}", 
ArticleHandler). Name("article")
url, err := r.Get("article").URL("category", "technology", "id", "42")



Le lundi 14 novembre 2016 17:34:26 UTC+1, to...@hypr.nz a écrit :
>
> I believe I have done enough research (and attempts) that this should be 
> an easy answer: either it doesn't work that way or I've missed something 
> simple! Fingers crossed and thanks in advance.
>
> My goal is to render absolute URLs for my API—I can't get route libraries 
> (eg gorilla/mux) to do this even though they look to be able to do so.
>
> The first question, to render absolute URLs by reversing a route name, 
> which library should I really be using? I'm assuming one that hooks into 
> the http.Request, such as, gorilla/mux.
>
> Given I use gorilla/mux, how? I see in the source that it requires a Host 
> to be setting in the route registration but upon registration of a Host, it 
> never matches a route again. (I can't find a solution to this either which 
> suggests that I have something wrong in my thinking).
>
> I hope this is descriptive enough to know whether I am way off the mark or 
> need to provide more, detailed information.
>
> Thanks. Todd.
>

-- 
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: Partial Variable Assignment

[paraiso . marc]

No way, it only works in the same block :

https://golang.org/ref/spec#Short_variable_declarations

 the for statement creates a new block . 

Le samedi 12 novembre 2016 03:49:35 UTC+1, so.q...@gmail.com a écrit :
>
>
> I thought it was possible to do partial assignment where, if one variable 
> is already declared and a new one is not.
> https://stackoverflow.com/questions/39028645/golang-variable-assignment
>
> In the below example ok has been declared prior, but v has not. Trying to 
> run the below results in an error "undefined: v", but I thought this was 
> possible?
> https://play.golang.org/p/dlRpcFGsSM
>
> package main
>
> import (
> "fmt"
> )
>
> func Foo() (int,bool) {
> return 1,false
> }
>
> func main() {
> ok := true
> for ok {
> v,ok = Foo()// v,ok := Foo(), doesn't work either
> fmt.Println(v)
> }
> fmt.Println(ok)
> }
>
>
>
>

-- 
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: Survey on Software Architectures

[paraiso . marc]

I'm on page 5 of the survey and still didn't get any question regarding 
software modelling. I stopped answering these questions.

I'm not keen of survey methodology but I don't think most questions are 
relevant to the theme of the survey. I also think you should ask personal 
questions 
at the end of the survey instead of the beginning as I don't think my 
country of origin, age or education influences how you build questions 
about the core theme of that survey. It would yield much more results.

Le mardi 25 octobre 2016 16:31:07 UTC+2, ozkaya...@gmail.com a écrit :
>
> Dear All,
> We're conducting a survey on software architecture modelling whose link is 
> http://bit.ly/2bGpSN4
> The survey aims at better understanding the practical knowledge and 
> experience of practitioners on software architecture modelling languages.
> If you spend 3-7 mins to fill the  survey, we would be so grateful to you. 
> Indeed, we imperatively need participants to contribute our research on 
> software architectures.
> If you know any potential participants, would you mind me requesting you 
> to forward to survey to them?
> Best,Mert
>

-- 
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: interface as valid method receivers ?

[paraiso . marc]

> there is ambiguity as to what is called.

Sorry I meant there *NO *ambiguity as to what is called.

Le mardi 18 octobre 2016 20:12:17 UTC+2, parais...@gmail.com a écrit :
>
> Obviously in Go this is a compile time error :
>
> type Foo interface {}
>
>
> func (f Foo) DoSomething(){}
>
>
> I wonder if there is some technical limitations that make it undesirable 
> or hard to implement, or it's just that Go designers didn't think it is a 
> relevant feature.
>
> I personally think there is it could be handy in some situations, instead 
> of having to write a function without receiver, it could allow to attach 
> behavior to interfaces automatically 
> instead of the explicit :
>
> func DoSomething(f Foo){}
>
>
> what is your opinion on the matter ? Unfortunately I wasn't able to catch 
> anyone of the Go team during the recent conference in Paris to ask that 
> question.
>

-- 
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: interface as valid method receivers ?

[paraiso . marc]

Hey folks, what a great discussion.

To be clear, if something like that would exist, it should have obvious 
limitation, like any Go features regarding structs and interfaces.

It would be illegal to do that for instance :

type Foo interface {
Do()
}
func (f Foo)interface Do(){}

Now I don't think it would make code harder to read. If Foo is used as an 
argument :

func AcceptFoo(f Foo){
   f.Do() // Execute Foo.Do
}
If Do is not inside the Foo "contract" but a method of Foo, there is 
ambiguity as to what is called.

Even if a struct implementing Foo has a Do function of his own, AcceptFoo 
cannot know that
since it is not defined on the interface .

When it comes to methods on structs, nothing would change : 

type Bar struct {}
func(b Bar)Do()

bar := Bar{}

bar.Do() // execute Bar.Do()

// however 

var bar2 Foo = Bar{}

bar2.Do() // execute Foo.Do()


A strict behavior should be defined one way or another, but I think this 
one would be interesting. 

Anyway It was just a thought on the matter, no big deal. It would be a 
great way to encapsulate some behavior without exposing internals or using 
package level functions accepting interfaces thus leading to cleaner API 
for libraries. If you think about technical implications or some current Go 
features this idea might break, let me know.




Le mardi 18 octobre 2016 20:12:17 UTC+2, parais...@gmail.com a écrit :
>
> Obviously in Go this is a compile time error :
>
> type Foo interface {}
>
>
> func (f Foo) DoSomething(){}
>
>
> I wonder if there is some technical limitations that make it undesirable 
> or hard to implement, or it's just that Go designers didn't think it is a 
> relevant feature.
>
> I personally think there is it could be handy in some situations, instead 
> of having to write a function without receiver, it could allow to attach 
> behavior to interfaces automatically 
> instead of the explicit :
>
> func DoSomething(f Foo){}
>
>
> what is your opinion on the matter ? Unfortunately I wasn't able to catch 
> anyone of the Go team during the recent conference in Paris to ask that 
> question.
>

-- 
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] interface as valid method receivers ?

[paraiso . marc]

Obviously in Go this is a compile time error :

type Foo interface {}


func (f Foo) DoSomething(){}


I wonder if there is some technical limitations that make it undesirable or 
hard to implement, or it's just that Go designers didn't think it is a 
relevant feature.

I personally think there is it could be handy in some situations, instead 
of having to write a function without receiver, it could allow to attach 
behavior to interfaces automatically 
instead of the explicit :

func DoSomething(f Foo){}


what is your opinion on the matter ? Unfortunately I wasn't able to catch 
anyone of the Go team during the recent conference in Paris to ask that 
question.

-- 
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] Reasons why `go get` is entirely quiet by default

[paraiso . marc]

Tools should be quiet by default. A package manager isn't supposed to 
return any result like grep or tail, aside from 0 . 

Le jeudi 13 octobre 2016 23:48:27 UTC+2, Nyah Check a écrit :
>
> Hi everyone,
>
> I don't know if someone may have talked of this here. But I just wish to 
> find out why `go get` is entirely quiet by default? Unlike other package 
> managers like npm or yarn. Someone asked this on the IRC channel today and 
> no one seemed to know why? I tweeted 
>  about this 
> today; still no response yet.
>
> Thanks,
> Nyah
>
> "The heaviest penalty for declining to rule is to be ruled by someone 
> inferior to yourself." --*Plato* 
>

-- 
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: [Open sourced] Workflow based REST Api framework - "florest"

[paraiso . marc]

Reading the doc , trying to reproduce the instructions :

 go get  -u github.com/jabong/florest-core/examples
package github.com/jabong/florest-core/examples: cannot find package 
"github.com/jabong/florest-core/examples" in any o


But that package isn't go gettable at first place anyway. 


Le mardi 27 septembre 2016 12:12:48 UTC+2, suba...@gmail.com a écrit :
>
> Hi All,
> Please check this https://github.com/jabong/florest-core.
>
> 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] Re: Adding YAML to the stdlib

[paraiso . marc]

Anybody can write a spec and deem it a standard.

YAML is certainly not a common data serialization format. Adding a YAML 
parser is in my opinion the least of of Go's priorities when one can see 
all the packages pilling up @ /x/ namespace that should have been in the 
stdlib already. More tools supporting XML development might actually make 
more sense, like support for SAX,XML schema,SOAP, XSL,XPath and all these 
API a lot of entreprise developers still need to interact with. Because 
frankly working with XML in Go is a pain in the arse.

Le vendredi 23 septembre 2016 22:02:51 UTC+2, Zachary Gershman a écrit :
>
> Gustavo - it is not jus that YAML is well known, it is also widely used 
> (as I even mentioned). It is a *standard *even though some may not want 
> to consider it as such. If I can read xml in the stdlib why not yaml? And 
> it is widely supported now but are you committed to supporting it for as 
> long as golang is around?
>
> On Friday, September 23, 2016 at 11:28:27 AM UTC-7, Gustavo Niemeyer wrote:
>>
>> Hi Zachary,
>>
>> You have already seen the thread, but for the benefit of others, Zach's 
>> email comes from a thread raised and replied to yesterday on Twitter:
>>
>> https://twitter.com/jvehent/status/778687333956587522
>>
>> As I said there, the yaml spec is big, messy, and I wouldn't encourage 
>> having the package in the distribution of Go. Something being well known 
>> and appreciated is not a reason to have it in the standard library.
>>
>> Also, there's nothing unfair about maintaining go-yaml. This was 
>> developed years ago while porting the first projects of Canonical to Go, 
>> and is by now widely used there, and we remain committed to supporting it. 
>> I also receive regular fixes and contributions from the community, and 
>> nobody seems upset to do so.
>>
>> The most recent change was to replace the LGPL license by Apache, which 
>> was well received. I was able to negotiate that based on requested from the 
>> community, and were were able to do so due to the CLA that is requested for 
>> contributions (ironic that most people CLA's as evil, yet it was used to 
>> open permissions further).
>>
>>
>>
>> On Fri, Sep 23, 2016 at 2:53 PM, Zachary Gershman  
>> wrote:
>>
>>> Hey All,
>>>
>>> I wanted to get feedback here first before I move this over to the 
>>> golang-dev mailing list (or maybe we even just start a change-set).  YAML 
>>> as a spec is not the greatest and some would even describe it as "gross" 
>>> but most if not all config files are written in some form of YAML (see 
>>> kubernetes as a prime example).  YAML was not included in the stdlib and 
>>> luckily for all of us the awesome go-yaml 
>>>  emerged as the de facto standard for 
>>> a majority of developers.
>>>
>>> Now, inclusion into the stdlib must pass a high bar 
>>>  and not everything can / should 
>>> be included but I believe that when you have over 1300 packages 
>>>  depending on an outside 
>>> library, you should at least have the discussion openly about whether it 
>>> should be moved into the stdlib.
>>>
>>> Also, it is slightly unfair to have the expectation that the community 
>>> should support a significant format through independent OSS work.
>>>
>>
>>
>>
>> -- 
>>
>> gustavo @ http://niemeyer.net
>>
>

-- 
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: Why + and += operators for string but not slices?

[paraiso . marc]

The more contextual a PL's semantics is the harder it is to make sense of a 
program written in that PL (the inverse is also true, that's why we don't 
program lining zeros and ones ) ... The problem with what you are asking is 
why yet another special case for slices ? why not one for channels ? why 
not using minus too for slices ? or multiply if my slice represents a 
vector ? some languages handle that with operator overloading in user land, 
Go just doesn't allow that. Adding more semantics to the plus operator 
would be against the goals of the language IMHO.  

Le samedi 17 septembre 2016 04:31:52 UTC+2, oyi...@gmail.com a écrit :
>
> Context enables homonyms in spoken languages and overloaded or polymorphic 
> notation in mathematics. Types do the same in programming languages. The 
> rationale for + over join() or cat() for string is equally applicable to 
> slices. a ++ b wouldn't be an unreasonable replacement for append(a, b...) 
> and append([]T, ...T) can stay as is but who needs it when you have []T ++ 
> []T{...T}
>
>
> On Saturday, September 17, 2016 at 12:31:31 AM UTC+1, parais...@gmail.com 
> wrote:
>>
>> Because Go creators have a strong opinion about what + means. I would 
>> argue the languages that engage into these sort of things especially those 
>> who allow operator overloading are antithetic to Go goals, but that's an 
>> opinion., I didn't create Go, I don't agree with all its design choices but 
>> understand why they were made. Go is only sophisticated in the way it 
>> handles concurrency. 
>>
>> Le vendredi 16 septembre 2016 19:11:17 UTC+2, oyi...@gmail.com a écrit :
>>>
>>> I have not been able to find an explanation. Does anyone care to explain 
>>> or point to relevant documentation?
>>>
>>

-- 
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: Why + and += operators for string but not slices?

[paraiso . marc]

Because Go creators have a strong opinion about what + means. I would argue 
the languages that engage into these sort of things especially those who 
allow operator overloading are antithetic to Go goals, but that's an 
opinion., I didn't create Go, I don't agree with all its design choices but 
understand why they were made. Go is only sophisticated in the way it 
handles concurrency. 

Le vendredi 16 septembre 2016 19:11:17 UTC+2, oyi...@gmail.com a écrit :
>
> I have not been able to find an explanation. Does anyone care to explain 
> or point to relevant documentation?
>

-- 
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: Go package management committee

[paraiso . marc]

Congrats.

Please consider at least 2 use cases :

- library authors

- project authors

These 2 use cases are widely different and if the solution doesn't address 
both cases it will not be useful.

People using gb don't have the same use case and issues as people using 
glide.

Ultimately the problem can only be solved with a third party tool that is 
NOT go get, but it must be an official tool sanctioned by the Go team. Good 
luck.

Le vendredi 26 août 2016 20:45:26 UTC+2, Peter Bourgon a écrit :
>
> As a reminder, in July I started the Go Packaging Proposal doc[0] with 
> the goal “To produce, have accepted, and implement a complete proposal 
> which addresses the concern of package management.” Thanks to everyone 
> who’s signaled interest. That process involves creating a small 
> committee to drive the proposal from start to finish. 
>
> In forming the committee I’ve focused on three important points— 
>
> 1. First and foremost, that the design and discussion process, and 
> ultimate technical solution, should be driven by a data- and 
> user-needs-centric methodology. 
>
> 2. That the schedule outlined in the process doc should be adhered to 
> as closely as possible. That means design-complete by end September, 
> and proposal-complete by end October, so that any possible language or 
> tooling changes can make the 1 November feature freeze for Go 1.8. 
>
> 3. Each member should have or make time to devote to this process, so 
> that both points above are feasible :) 
>
> A committee size of four I believe most effectively balances a variety 
> of voice and opinion, and an ability to effectively decide and act. 
> After a great deal of consultation with, and feedback from, key 
> members of the Go language and package management/vendoring 
> communities, I'm happy to announce that Andrew Gerrand, Edward Muller, 
> Jessie Frazelle, and Sam Boyer have all agreed to serve on the package 
> management committee. 
>
> Andrew needs no introduction, as he's been leading the Go community 
> advocacy efforts from within the Go team since nearly the very 
> beginning. Andrew brings an unmatched perspective on the current state 
> and evolution of the Go language and tooling, and will be instrumental 
> in shepherding any possible language or tooling changes through the 
> proposal process. 
>
> Ed has been maintaining the godep project for the past two years, and 
> brings a pragmatic and user-centric perspective to the committee. 
>
> Jessie has been on the Go package management front lines for years, 
> originally with Docker and now with Kubernetes. I can't think of 
> anyone better to represent the needs of large Go projects and 
> organizations. 
>
> Sam may be best known in the Go community for his article "So you want 
> to write a package manager[1]." With his background and work on the Go 
> Package Solver, Sam brings theoretical depth and rigor to the 
> committee. 
>
> Keeping the committee small was absolutely essential, but it quickly 
> became apparent that several unquestionably qualified individuals, 
> whose efforts and experience would be critical to our success, would 
> be excluded. We decided that an advisory group, while not part of the 
> original Process doc, would enable the committee to remain small and 
> nimble, while leveraging the value, effort, and experience of a larger 
> group. The maintainers of popular package management tools Glide (Matt 
> Farina), govendor (Daniel Theophanes) and gb (Dave Cheney), as well as 
> Steve 'spf13' Francia (Hugo, Cobra) have all graciously agreed to 
> support in this role. Their job will be to help compile user and 
> domain research, and to represent user needs whenever the committee 
> needs input. Matt and Steve in particular have been hard at work on an 
> updated tool survey and user requirement doc; details forthcoming. 
> Both I and the committee are incredibly grateful to each of them for 
> their support. 
>
> I'll act as secretary, note-taker, and communications director for the 
> committee on an as-needed basis, to free them from the overhead. If 
> you have any questions about the process, please direct them to me. 
> And stay tuned for links to research and design Google Docs. 
>
> [0] 
> https://docs.google.com/document/d/18tNd8r5DV0yluCR7tPvkMTsWD_lYcRO7NhpNSDymRr8
>  
> [1] 
> https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.iqtluxnrr
>  
>

-- 
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: Why can't convert []T to []T2 if T2 is a copy definition of T?

[paraiso . marc]

There are no subtypes in go, so no covariance or contravariance, which 
explained a lot of limitations of Go type system. The problem is that some 
level of covariance is hardcoded in the compiler (string to []byte ...) 
 which makes me think that go designers understand the value of it and know 
that there are cases where it is needed. It just the same problem as 
generics vs append. append is a generic function  of type 
append([]T,T...)[]T which behavior is hardcoded in the compiler instead of 
being generalized. Go designers understand the value of generics in that 
specific case without letting the user define their own functions with the 
exact same behavior.

https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)

All languages are opinionated, I think that adjective doesn't match Go 
features. Go is a language that is "restricted" but bear with me. 

The problem with being fine with that fact is that, while Go has these 
restrictions, Go allows a lot of dynamic behavior at runtime through 
reflection (with a speed cost, though caching definitely helps) which is a 
paradox for a statically typed language. The temptation of using reflection 
to work around language restrictions becomes huge every time one is 
confronted to these limitations.

It would be interesting to know if allowing(or not) reflection in userland 
was debated among Go designers at some point.

Regards.

-- 
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: Database design pattern

[paraiso . marc]

I find your question strange because, unless you have a specific 
architectural problem , which you don't, AFAIK, you shouldn't try to force 
patterns in your code. Write code that is testable then refactor if needed. 
Don't try to force a specific pattern just because "patterns". 

Now if you are looking for patterns for the sake of patterns Microsoft has 
extensive documentation of enterprise patterns : 

https://msdn.microsoft.com/en-us/library/ff648419.aspx

as well as Martin Fowler :

http://martinfowler.com/eaaCatalog/index.html

Something that would be useful for everybody next time is you actually 
coming with a piece of code that works then asking for ways to refactor 
that piece of code. 

Le vendredi 19 août 2016 16:08:04 UTC+2, Asit Dhal a écrit :
>
> Hi All,
>
> I need to build an application that accesses a small database(sqlite or 
> may be mysql in production).
>
> My database operations are very small, like
> 1. Insert
> 2. Read
> 3. Search
>
> Insert is one time, and most of the time new records will be added in a 
> batch. 
>
> Can someone suggest me some application design pattern(a tutorial or 
> github repo) for small database access ?
>
>
> Warm Regards,
> Asit Dhal
> http://bit.ly/193ASIT
>

-- 
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: IDE for GOLANG

[paraiso . marc]

Liteide is the best editor for Go :

https://sourceforge.net/projects/liteide/

Le mardi 2 août 2016 14:25:21 UTC+2, kritika...@indiamart.com a écrit :
>
> Hi, 
> is there IDE for creating a web service in GOLANG by using Revel framework 
>  which follows MVC architecture.
>
> i am using Ubuntu ..
>
>
>
> *Watch our latest TV Commercial #IndiaKiKhoj 
> *
>

-- 
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] Is there a function in standard lib to convert []T to a []interface{}?

[paraiso . marc]

I guess the difference is that a builtin COULD be compile-time type safe. 
It could reject anything that is not a slice or an array, the same way 
append is type safe.

Le mercredi 3 août 2016 17:51:44 UTC+2, Thomas Bushnell, BSG a écrit :
>
> On Wed, Aug 3, 2016 at 7:36 AM T L  
> wrote:
>
>> Often, I need converting a []T to []interface{} to use the []interface as 
>> a variable length parameter.
>> But converting a []T for []interface{} in a for loop is neither clean nor 
>> efficient.
>>
>
> If there was a builtin that did it, it would simply need to do the same 
> loop. The memory representation is not the same.
>
> Thomas
>  
>

-- 
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] liteide x30.2 released

[paraiso . marc]

Nice Ctrl+P to navigate between files work well , it's like to be able to 
navigate between Symbols too. With a drop down menu .

Le mardi 12 juillet 2016 09:09:15 UTC+2, visualfc a écrit :
>
> Hi, all
>
> LiteIDE x30.2 released, This version bug fix and build test for Go1.7 rc1
>
>
> ### 2016.7.12 Ver X30.2
> * LiteApp
> * add new vs-dard css, thanks [tupunco](https://github.com/tupunco)
> * fix and re-implement editor list menu
> * QuickOpen
> * QuickOpenFile skip same folder and same files
> * QuickOpneFile add current editor local files
>

-- 
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: New Context method in http.Request, what can we do with it?

[paraiso . marc]

Don't you think it would be better to use context to hold session values 
rather than using global variables like github.com/gorilla/sessions does ? 

Le lundi 11 juillet 2016 00:43:05 UTC+2, Matt Silverlock a écrit :
>
> Use it to pass connection/request-scoped values: that is, values that 
> could only exist once you have a request. authentication tokens, user 
> details, connection IDs: things that can't be known/generated before the 
> connection has been received.
>
> e.g. gorilla/mux (https://github.com/gorilla/mux) uses it to pass 
> route-matching information back to the user (i.e. for /user/:name, the 
> :name value). Don't use context to pass app-level dependencies, as it makes 
> testing, reasoning and debugging hard.
>
>
>
> On Thursday, July 7, 2016 at 4:03:18 PM UTC-7, Tyler Compton wrote:
>>
>> I'm really excited to see context.Context become a first class citizen in 
>> Go 1.7. After using context, it feels like a natural way to write Go 
>> network code and it fits naturally in the standard library. I'm trying to 
>> figure out how I can improve existing code with the new features that come 
>> with it.
>>
>> In Go 1.7, requests now can contain a context, and the context can be 
>> changed. This seems really cool, but I don't know what exactly I can do 
>> that I can't do before, other than what the documentation specifically 
>> outlines: "For outgoing client requests, the context controls cancelation."
>>
>> Is there anything else we will be able to do that I should be looking 
>> into? What are your plans?
>>
>

-- 
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] liteide x30 released

[paraiso . marc]

Great news, I love liteide which is for me the best Go IDE, no question. I 
love the embedded Go Playground too, quite handy when it comes to try new 
stuff in Go.

Le lundi 4 juillet 2016 03:52:29 UTC+2, visualfc a écrit :
>
> Hi, all
> liteide x30 released!
> This version bug fix, support go1.7, add fakevim mode (thanks jsuppe 
> https://github.com/jsuppe) , add quick open files (ctrl+p) and quick open 
> editor (ctrl+alt+p) actions.
>
> LiteIDE Source code : https://github.com/visualfc/liteide
> Gotools Source code : https://github.com/visualfc/gotools
> Binary downloads : http://sourceforge.net/projects/liteide/files
> Latest downloads : http://git.oschina.net/visualfc/liteide/attach_files
>
> ### 2016.7.2 Ver X30
> * LiteIDE
> * add new QuickOpen plugin
> * add new FakeVim plugin, thanks for [jsuppe](
> https://github.com/jsuppe)
> * add custom env LITEIDE_TOOL_PATH/LITEIDE_PLUGIN_PATH/LITEIDE_RES_PATH
> * LiteApp
> * action tooltip shortcut show native text
> * option keyboard map show native text
> * QuickOpen
> * quick open files action CTRL+P
> * quick open editor action CTRL+ALT+P
> * quick go to line action CTRL+L
> * quick open help
> * FakeVim
> * editor add vim style mode editing
> * LiteEditor
> * add goto line start/end action
> * add goto doc start/end action
> * add goto previous/next line action
> * add goto previous/next charater action
> * add goto previous/next word action
> * change '' braces only go source
> * fix codecompleter number first
> * MacOS fix move line up/down shortcut command+shift+up/down
> * GolangEdit
> * CTRL+mouse navigate preview source info
> * LiteFind
> * MacOS fix edit replace shortcut command+shift+F
> * Welcome
> * fix doc css style
> * gotools
> * types fix limit parser
> * types simple field info
>  
>

-- 
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: Go 1.7 Beta 2 is released

[paraiso . marc]

Thanks, is there a way to know what to expect in later versions ( 
1.8,1.9,1.10 and so forth ... ) ? 

Le vendredi 17 juin 2016 01:15:18 UTC+2, Chris Broadfoot a écrit :
>
> Hello gophers,
>
> We have just released go1.7beta2, a beta version of Go 1.7.
> It is cut from the master branch at the revision tagged go1.7beta2.
>
> Please help us by testing your Go programs with the release, and report 
> any problems using the issue tracker:
> https://golang.org/issue/new
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.7beta2
>
> To find out what has changed in Go 1.7, read the draft release notes:
> https://tip.golang.org/doc/go1.7
>
> Documentation for Go 1.7 is available at:
> https://tip.golang.org/
>
> Our goal is to release the final version of Go 1.7 on the 1st of August.
>
> Cheers,
> Chris
>

-- 
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: Testing best practice: passing and failing test

[paraiso . marc]

By the way, Go 1.7 support subtests :

https://tip.golang.org/pkg/testing/#hdr-Subtests_and_Sub_benchmarks

Which is one of the nicest additions to Go 1.7 

Le jeudi 16 juin 2016 16:04:11 UTC+2, Rayland a écrit :
>
> Let's say I have some piece of code like this:
>
> type Foo struct {
> }
>
> func (this *Foo) Do() {
> }
>
>
> If I want to test that method Foo will pass in a certain scenario and fail 
> in another scenario should I have a test for each scenario or should I have 
> all scenarios tested in a method TestFoo_Do()?
>
>
>
>

-- 
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: Currying in Go

[paraiso . marc]

What is the point of doing that in a language that doesn't support auto 
currying ? There is none. You are not currying anything by the way, you 
just wrote 3 closures. 

Le vendredi 17 juin 2016 00:00:43 UTC+2, Zauberkraut a écrit :
>
> Hello,
>
> Go enables the evaluation of functions using currying over function 
> literals. Every example I've found of this is rather shallow; a "deeper" 
> example I wrote implementing (x => (y => (z => x^2 + y^2 + z^2))) follows:
>
> func f(x int) func(int) func(int) int {
> return func(y int) func(int) int {
> return func(z int) int {
> return x*x + y*y + z*z
> }
> }
> }
>
> Go's limited type inference makes the explicit, cascading function types 
> necessary; this seems like an eyesore and maintenance concern. While I 
> don't really mind it, it does cause me to hear code review sirens going off 
> in the distance. Generally speaking, would an extended usage of this 
> paradigm be considered unidiomatic in Go? Obviously, the above example is 
> contrived and not the sort of use case in question. 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.