My apologies the link is incorrect. It should be
https://github.com/Skarlso/tuple
Hopefully it’s somewhat of a help in pursuing this topic.
On Friday 9 August 2024 at 07:57:33 UTC+2 Gergely Brautigam wrote:
> Hello.
>
> I actually implemented a Tupke logic here https://github.co
My apologies for the link. Google groups on mobile isn’t really working.
https://girhub.com/Skarlso/tuple
On Friday 9 August 2024 at 07:57:33 UTC+2 Gergely Brautigam wrote:
> Hello.
>
> I actually implemented a Tupke logic here https://github.con/Skarlso/tuple
> .
>
> I find
Hello.
I actually implemented a Tupke logic here https://github.con/Skarlso/tuple.
I find this a much better way to deal with tuples instead of the indexing
logic. And it’s using generics as well. Feel free to borrow stuff. 😊
On Friday 9 August 2024 at 02:19:22 UTC+2 Jolyon Direnko-Smith wrote
ay 26 December 2023 at 10:15:12 UTC+1 Jan Mercl wrote:
> On Tue, Dec 26, 2023 at 9:12 AM Gergely Brautigam
> wrote:
>
> > If you have a top level recover in you main, it doesn't matter where the
> panic happens, you'll capture it. Even in third party library.
>
> Iff
If you have a top level recover in you main, it doesn't matter where the
panic happens, you'll capture it. Even in third party library.
package main
import (
"fmt"
"github.com/Skarlso/panic"
)
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered in f", r)
}
}()
fmt
> On 2022. Oct 27., at 20:16, Konstantin Khomoutov wrote:
>
> On Thu, Oct 27, 2022 at 11:01:01AM -0700, Gergely Brautigam wrote:
>
> [...]
>>> Since Go 1.13 you can also make chains of errors; say, in your second
>>> example
>>> you could do
>
2022 at 06:23:31AM -0700, Gergely Brautigam wrote:
>
> > I was wondering what's the consensus these days on handling defer
> errors?
> >
> > Is it something like, overwriting the returned value, or using a list of
> > errors?
> >
> > Eith
Hello, esteemed Gophers.
I was wondering what's the consensus these days on handling defer errors?
Is it something like, overwriting the returned value, or using a list of
errors?
Either:
func test() (err error) {
defer func() {
if tmpErr := doSomething(); tmpErr != nil {
Do you know how git works? You need a remote url for the repository to push to.
> On 2022. Oct 18., at 12:45, PK wrote:
>
> Thank you, I tried to setup by this:
>
> if err_psh = repo.Push(&git.PushOptions{
>
>RemoteName: "origin",
>
>}); err != nil {
>
>log.Fatal(err_psh)
> On 2022. Oct 18., at 11:19, PK wrote:
>
> no, Do we need to set-up something. If yes can you please let me know?
Yep. Well, you are trying to push something to somewhere, right? So you need a
remote set up which is usually origin. So just set up a remote and then you can
push.
Of course if
Hello.
Did you set up any remotes for the folder that you are trying to push?
On Monday, 17 October 2022 at 13:16:12 UTC+2 princ...@gmail.com wrote:
> Hi,
> I am trying to run example provided here(
> https://github.com/go-git/go-git/tree/master/_examples)
>
> 1) firstly I run the clone example
On Wednesday, 21 July 2021 at 10:05:10 UTC+2 Brian Candler wrote:
> Channels are almost always better than low-level primitives like condition
> variables, which have various pitfalls.
Almost always. :) Sure, there are alternatives, but sync.Cond makes sense
once you use it properly. And it
I think this is a perfect scenario for sync.Cond
https://pkg.go.dev/sync#Cond.
On Tuesday, 20 July 2021 at 21:21:27 UTC+2 prawira.d...@gmail.com wrote:
> I personally like to use range channel to "break out" process in
> goroutine, for example :
>
> package main
> import (
> "fmt"
> "sy
Yaay! Awesome!
On Tuesday, 25 July 2017 18:30:06 UTC+2, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We have just released go1.9rc1, a release candidate of Go 1.9.
> It is cut from release-branch.go1.9 at the revision tagged go1.9rc1.
>
> Thank you to everyone who has helped to test Go 1.9 so
14 matches
Mail list logo
