Re: [go-nuts] Bring back slices.BinarySearchFunc with a predicate

2022-04-04 Thread 'Axel Wagner' via golang-nuts 
Sorry, the predicate should be

var b T
pred := func(a T) bool { return cmp(a, b) >= 0 }

On Tue, Apr 5, 2022 at 7:27 AM Axel Wagner 
wrote:

> Hm I must say, I also don't really understand removing the predicate-based
> one. It is easy, when you have a comparison function, to get to a predicate:
> pred := func(a, b T) bool { return cmp(a, b) >= 0 }
> But not the other way around, so a predicate is more general.
>
> I used the predicate version of `sort.Search` to look for prefix-matches
> in a sorted slice of paths. i.e. I was not looking for an equality match of
> the needle, but also something of which the needle is a prefix.
>
> When I saw #50340  fly by, I
> assumed this would be about adding a simpler version of `sort.Search` to
> make the common use-case simpler, which was very much fine with me, so I
> didn't follow that discussion. I would've spoken up sooner, if I expected
> the more general version to disappear.
>
> On Tue, Apr 5, 2022 at 1:08 AM Sudhir Jonathan  wrote:
>
>> The earlier method signature for slices.BinarySearchFunc was very useful:
>>
>> It was of the form
>> ```
>> slices.BinarySearchFunc(array, func(e T) bool)
>> ```
>> which returned the smallest index at which predicate would return true.
>>
>> This was incredibly useful to do inequality operation binary searches  -
>> like find the smallest index in a sorted slice where the element was
>> greater than this (helps figure out the index of the last repeat of an
>> element in the sorted slice).
>>
>> I understand the new method is true-er to its name, but can we bring the
>> old one back as well, maybe as slices.BinarySearchPredicate ?
>>
>> --
>> 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/f5f8c4a8-56da-4f00-a43b-20015828fdb5n%40googlegroups.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHPXtAzbM7bq3FPoo0J2Nz9g1%3DbrpxpBXrAqqG_ViU5RA%40mail.gmail.com.

Re: [go-nuts] Bring back slices.BinarySearchFunc with a predicate

2022-04-04 Thread 'Axel Wagner' via golang-nuts 
Hm I must say, I also don't really understand removing the predicate-based
one. It is easy, when you have a comparison function, to get to a predicate:
pred := func(a, b T) bool { return cmp(a, b) >= 0 }
But not the other way around, so a predicate is more general.

I used the predicate version of `sort.Search` to look for prefix-matches in
a sorted slice of paths. i.e. I was not looking for an equality match of
the needle, but also something of which the needle is a prefix.

When I saw #50340  fly by, I
assumed this would be about adding a simpler version of `sort.Search` to
make the common use-case simpler, which was very much fine with me, so I
didn't follow that discussion. I would've spoken up sooner, if I expected
the more general version to disappear.

On Tue, Apr 5, 2022 at 1:08 AM Sudhir Jonathan  wrote:

> The earlier method signature for slices.BinarySearchFunc was very useful:
>
> It was of the form
> ```
> slices.BinarySearchFunc(array, func(e T) bool)
> ```
> which returned the smallest index at which predicate would return true.
>
> This was incredibly useful to do inequality operation binary searches  -
> like find the smallest index in a sorted slice where the element was
> greater than this (helps figure out the index of the last repeat of an
> element in the sorted slice).
>
> I understand the new method is true-er to its name, but can we bring the
> old one back as well, maybe as slices.BinarySearchPredicate ?
>
> --
> 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/f5f8c4a8-56da-4f00-a43b-20015828fdb5n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHFEsRSq_yU3kFwYLYG3fJ8AdQ6sPgenHGGO%3DdmmebVdg%40mail.gmail.com.

Re: [go-nuts] build unoptimized std lib for debugging

2022-04-04 Thread Ian Lance Taylor 
On Mon, Apr 4, 2022 at 5:16 PM arthurwil...@gmail.com
 wrote:
>
>
>
> On Monday, April 4, 2022 at 7:00:49 PM UTC-5 arthurwil...@gmail.com wrote:
>>
>> On Monday, April 4, 2022 at 6:14:30 PM UTC-5 Ian Lance Taylor wrote:
>>>
>>> On Mon, Apr 4, 2022 at 3:49 PM arthurwil...@gmail.com
>>>  wrote:
>>> >
>>> >
>>> >
>>> > On Sunday, April 3, 2022 at 10:35:04 PM UTC-5 Ian Lance Taylor wrote:
>>> >>
>>> >> On Sun, Apr 3, 2022 at 6:21 PM arthurwil...@gmail.com
>>> >>  wrote:
>>> >> >
>>> >> > I'm trying to build an unoptimized version of the standard library for 
>>> >> > debugging.
>>> >>
>>> >> You can just use
>>> >>
>>> >> go build -gcflags=all="-N -l"
>>> >>
>>> >
>>> > That gives this error:
>>> > /Volumes/git/goroot/src (master)$ go build -gcflags=all="-N -l"
>>> > no Go files in /Volumes/git/goroot/src
>>>
>>> You have to run this wherever you are building your actual Go program.
>>>
>>> What I mean is, if you want to "go build x.go" and you want to build
>>> that with a standard library built for maximal debugging, then rn "go
>>> build -gcflags=all="-N -l" x.go". Any flags specified by
>>> -gcflags=all="FLAGS" will be used to build the standard library as
>>> well. You don't need to build the standard library separately.
>>>
>>> Ian
>>
>>
>> Thanks Ian. I cleaned the cache and mod cache and passed -x to see all the 
>> commands run and noticed go build is not propagating the -N -l flags to the 
>> compiler for a lot of the files.
>>
>> Also noticed some extra compiler flags (-std, -+) that are not listed in the 
>> compile command documentation
>>
>> What do these -std and -+ compiler flags do?
>>
>> Why are some compilation commands missing -N -l?
>>
>>
>
> I found some clues:
>
> CompilingRuntime bool "flag:\"+\" help:\"compiling runtime\""
>
> and:
>
> if Flag.CompilingRuntime && Flag.N != 0 {
> log.Fatal("cannot disable optimizations while compiling runtime")
> }

Yeah.

The -std flag is passed when compiling packages in the standard
library.  Certain undocumented compiler pragmas are only permitted for
standard library code.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWMo%3D9VLjpbA15sSE19BsdZBSv%2BmytaNyTQUPCndyJAaQ%40mail.gmail.com.

Re: [go-nuts] build unoptimized std lib for debugging

2022-04-04 Thread arthurwil...@gmail.com 


On Monday, April 4, 2022 at 7:00:49 PM UTC-5 arthurwil...@gmail.com wrote:

> On Monday, April 4, 2022 at 6:14:30 PM UTC-5 Ian Lance Taylor wrote:
>
>> On Mon, Apr 4, 2022 at 3:49 PM arthurwil...@gmail.com 
>>  wrote: 
>> > 
>> > 
>> > 
>> > On Sunday, April 3, 2022 at 10:35:04 PM UTC-5 Ian Lance Taylor wrote: 
>> >> 
>> >> On Sun, Apr 3, 2022 at 6:21 PM arthurwil...@gmail.com 
>> >>  wrote: 
>> >> > 
>> >> > I'm trying to build an unoptimized version of the standard library 
>> for debugging. 
>> >> 
>> >> You can just use 
>> >> 
>> >> go build -gcflags=all="-N -l" 
>> >> 
>> > 
>> > That gives this error: 
>> > /Volumes/git/goroot/src (master)$ go build -gcflags=all="-N -l" 
>> > no Go files in /Volumes/git/goroot/src 
>>
>> You have to run this wherever you are building your actual Go program. 
>>
>> What I mean is, if you want to "go build x.go" and you want to build 
>> that with a standard library built for maximal debugging, then rn "go 
>> build -gcflags=all="-N -l" x.go". Any flags specified by 
>> -gcflags=all="FLAGS" will be used to build the standard library as 
>> well. You don't need to build the standard library separately. 
>>
>> Ian 
>>
>
> Thanks Ian. I cleaned the cache and mod cache and passed -x to see all the 
> commands run and noticed go build is not propagating the -N -l flags to the 
> compiler for a lot of the files. 
>
> Also noticed some extra compiler flags (-std, -+) that are not listed in 
> the compile command documentation 
>
> What do these -std and -+ compiler flags do? 
>
> Why are some compilation commands missing -N -l?
>
>
>
I found some clues: 

CompilingRuntime bool "flag:\"+\" help:\"compiling runtime\""

and:

if Flag.CompilingRuntime && Flag.N != 0 {
log.Fatal("cannot disable optimizations while compiling runtime")
}
 

>
>  
>

-- 
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/8c82e44d-0ac1-433f-bd02-b0ae61cf7e20n%40googlegroups.com.

Re: [go-nuts] build unoptimized std lib for debugging

2022-04-04 Thread arthurwil...@gmail.com 


On Monday, April 4, 2022 at 6:14:30 PM UTC-5 Ian Lance Taylor wrote:

> On Mon, Apr 4, 2022 at 3:49 PM arthurwil...@gmail.com 
>  wrote: 
> > 
> > 
> > 
> > On Sunday, April 3, 2022 at 10:35:04 PM UTC-5 Ian Lance Taylor wrote: 
> >> 
> >> On Sun, Apr 3, 2022 at 6:21 PM arthurwil...@gmail.com 
> >>  wrote: 
> >> > 
> >> > I'm trying to build an unoptimized version of the standard library 
> for debugging. 
> >> 
> >> You can just use 
> >> 
> >> go build -gcflags=all="-N -l" 
> >> 
> > 
> > That gives this error: 
> > /Volumes/git/goroot/src (master)$ go build -gcflags=all="-N -l" 
> > no Go files in /Volumes/git/goroot/src 
>
> You have to run this wherever you are building your actual Go program. 
>
> What I mean is, if you want to "go build x.go" and you want to build 
> that with a standard library built for maximal debugging, then rn "go 
> build -gcflags=all="-N -l" x.go". Any flags specified by 
> -gcflags=all="FLAGS" will be used to build the standard library as 
> well. You don't need to build the standard library separately. 
>
> Ian 
>

Thanks Ian. I cleaned the cache and mod cache and passed -x to see all the 
commands run and noticed go build is not propagating the -N -l flags to the 
compiler for a lot of the files. 

Also noticed some extra compiler flags (-std, -+) that are not listed in 
the compile command documentation 

What do these -std and -+ compiler flags do? 

Why are some compilation commands missing -N -l?



 

-- 
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/dc258f39-89b7-482a-8d46-f7c50e227900n%40googlegroups.com.

Re: [go-nuts] build unoptimized std lib for debugging

2022-04-04 Thread Ian Lance Taylor 
On Mon, Apr 4, 2022 at 3:49 PM arthurwil...@gmail.com
 wrote:
>
>
>
> On Sunday, April 3, 2022 at 10:35:04 PM UTC-5 Ian Lance Taylor wrote:
>>
>> On Sun, Apr 3, 2022 at 6:21 PM arthurwil...@gmail.com
>>  wrote:
>> >
>> > I'm trying to build an unoptimized version of the standard library for 
>> > debugging.
>>
>> You can just use
>>
>> go build -gcflags=all="-N -l"
>>
>
> That gives this error:
> /Volumes/git/goroot/src (master)$ go build -gcflags=all="-N -l"
> no Go files in /Volumes/git/goroot/src

You have to run this wherever you are building your actual Go program.

What I mean is, if you want to "go build x.go" and you want to build
that with a standard library built for maximal debugging, then rn "go
build -gcflags=all="-N -l" x.go".  Any flags specified by
-gcflags=all="FLAGS" will be used to build the standard library as
well.  You don't need to build the standard library separately.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW1ia11%3DTBGS5WJwCuf%2BJZ9aCh4UDRWxB8B9i32zV-6EQ%40mail.gmail.com.

[go-nuts] Re: Why can't an interface type be a receiver

2022-04-04 Thread Simon Archer 
I think that playground is broken.





*./prog.go:22:9: undefined: translatableImpl./prog.go:27:11: undefined: 
translatableImplGo build failed.*

I fixed it like this:
   https://go.dev/play/p/vZlwZIe9Ras

On Monday, April 4, 2022 at 1:27:46 PM UTC-4 Ron Green wrote:

> in case anyone get's here and is confused...
>
> you can wrap the additional functionality in the struct and use the 
> interfaces from before
>
> https://go.dev/play/p/e8aS0PZC6Zh
>
> On Monday, February 2, 2015 at 2:55:30 PM UTC+2 oju...@gmail.com wrote:
>
>> The code start to get smart when you combine interfaces.
>>
>> https://play.golang.org/p/axyl9FPS1e
>>
>> Whenever you can, forget the actual types. Code for interfaces instead.
>>
>

-- 
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/2d1ab342-5f84-401a-8bf8-60de23f0b93cn%40googlegroups.com.

[go-nuts] Bring back slices.BinarySearchFunc with a predicate

2022-04-04 Thread Sudhir Jonathan 
The earlier method signature for slices.BinarySearchFunc was very useful:

It was of the form 
```
slices.BinarySearchFunc(array, func(e T) bool)
```
which returned the smallest index at which predicate would return true. 

This was incredibly useful to do inequality operation binary searches  - 
like find the smallest index in a sorted slice where the element was 
greater than this (helps figure out the index of the last repeat of an 
element in the sorted slice). 

I understand the new method is true-er to its name, but can we bring the 
old one back as well, maybe as slices.BinarySearchPredicate ?

-- 
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/f5f8c4a8-56da-4f00-a43b-20015828fdb5n%40googlegroups.com.

Re: [go-nuts] build unoptimized std lib for debugging

2022-04-04 Thread arthurwil...@gmail.com 


On Sunday, April 3, 2022 at 10:35:04 PM UTC-5 Ian Lance Taylor wrote:

> On Sun, Apr 3, 2022 at 6:21 PM arthurwil...@gmail.com 
>  wrote: 
> > 
> > I'm trying to build an unoptimized version of the standard library for 
> debugging. 
>
> You can just use 
>
> go build -gcflags=all="-N -l" 
>
>
That gives this error:
/Volumes/git/goroot/src (master)$ go build -gcflags=all="-N -l"
no Go files in /Volumes/git/goroot/src
 

-- 
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/79825cc0-4f1b-4559-9c66-4eb5055e2306n%40googlegroups.com.

Re: [go-nuts] Convert string to time.Duration

2022-04-04 Thread vika...@gmail.com 
Thanks all for the hint and the snippets. I am all set now.

On Tuesday, 5 April 2022 at 00:13:46 UTC+10 tay...@fastmail.com wrote:

> Take a look at time.ParseDuration and its example: 
> https://pkg.go.dev/time#ParseDuration
>
> On Sun, Apr 3, 2022, at 3:48 PM, vika...@gmail.com wrote:
>
> I am looking to convert a *string* (say 4) to type *time.Duration*.
>
> I've looked around but could not find a way to do so.
>
> // https://go.dev/play/p/EUuDAY-Qx8N
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func main() {
> // var addHours string = 4
> fmt.Println(time.Now().Local())
> timeAdd := time.Now().Local().Add(time.Hour * 4) // I want to use 4 
> from a string variable here
> fmt.Println(timeAdd)
> }
>
>
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/72d548fc-f572-4ff5-9516-3e13fa04850dn%40googlegroups.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/159a25e2-7912-46e3-8c41-116ca887cec0n%40googlegroups.com.

Re: [go-nuts] Looked at using Go ... nil/SEGV really bothered me .. Go2 Proposal?

2022-04-04 Thread Sam Hughes 
I was really annoyed that, apparently, I accidentally deleted the message 
you're replying to, immediately after writing it.

I agree with you about being possibly surprised by values of outside of an 
expected range. The benefit of the above is merely that accessing it is 
guaranteed to be checked before dereferencing, converting a panic to a 
possibly invalid value. When using it, if the quality of value matters, you 
can check for quality of the value instead of both existence and quality of 
the value. 

The reference to TypeScript's traced types was to point at how that kind of 
behavior is built into the type system, and can't would require modifying 
one or more steps in the Go compilation process to implement. 

As for the approach, check out the sync/atomic package. It's a very similar 
interface.
On Monday, March 28, 2022 at 1:37:08 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> On Mon, Mar 28, 2022 at 12:39 AM Sam Hughes  wrote:
>
>> @Axel, I really did mean what I said.
>>
>
> So did I.
>
> FTR, if OP would have asked for changes to the type-system to be able to 
> represent non-nilable types, my response would have been different. I 
> didn't read their original message as asking for that.
>
> I didn't say "it's impossible" or "it's a bad idea" to have a programming 
> language which is more strict about nil-references. I said that it's 
> impossible to have the Go compiler force you to check for nil-pointers and 
> a bad idea to have vet do it. I consider every discussion on this list as 
> starting from the language as it is today.
>
> The more convenient approach is to implement a type like below. If you 
>> disagree? So help meI'll I'll disagree with you?
>>
>> ```Go
>> type Box[T any] *T
>>
>> func (ptr Box[T]) Raw() *T {
>>   return (*T)(ptr)
>> }
>>
>> func (ptr Box[T]) IsNil() bool {
>>   return ptr.Raw() == nil
>> }
>>
>> func (ptr Box[T]) Value() (checked T) {
>>   if blind := ptr.Raw(),  ok := !IsNil() bool; ok {
>> checked = *blind
>>   }
>>   return checked
>> }
>>
>
> To me, this seems like it reduces robustness for most programs (assuming 
> you meant to write `Box[T any] struct { p *T }`, otherwise it's at best the 
> same). For one, if you have a pointer, you usually want to do something 
> with that value - getting a new value every time it is dereferenced would 
> make it really easy to write broken programs. It's also easy for functions 
> to have non-sensical behavior when applied to the zero value of some type.
>
> In short, the semantics of "nil-pointers dereference to a new zero-value 
> of the type" seems extremely brittle and a bad idea to me.
>  
>
>>
>> I recently saw a talk called "It's all about Tradeoffs". This is an 
>> excellent example of that. Maybe the above could be improved by static 
>> checking and optimization, but it's never as cheap as just trusting there's 
>> something there, so long as there actually is something there.
>>
> On Friday, March 25, 2022 at 1:41:07 PM UTC-5 Michael Toy wrote:
>>
>>> The discussion is quite informative for me to read, thanks for 
>>> responding. Go uses nil in a way which I don't quite yet grok, and so I had 
>>> no idea if it was even a reasonable thing to wish for. Today I am writing 
>>> in Typescript, and the way null is integrated into the type system now 
>>> (after a while) feels natural and helpful to me.
>>>
>>> Sam is correct, there is bug in my Go snippet in the post. For humor 
>>> value only, I would like to point out that the imaginary Go compiler I was 
>>> wishing for would have found that bug!
>>>
>>> I think Brian gets to the heart of my question, which is "If I really 
>>> understood Go, would I want something like this". I am hearing, "No, you 
>>> would not"
>>>
>>> I think if I were to have a long conversation with Axel about "what is 
>>> it that makes programs robust and maintainable" we'd go round in circles a 
>>> bit, as should happen any time you talk about something complex and 
>>> important. I think I disagree with some statements, but even the 
>>> disagreement is super helpful.
>>>
>>> Thanks for the discussion!
>>>
>>> -Michael Toy
>>>
>>> On Thursday, March 24, 2022 at 12:22:44 AM UTC-10 Brian Candler wrote:
>>>
 The OP hasn't said specifically which language or feature they're 
 comparing with, but I wonder if they're asking for a pointer type which is 
 never allowed to be nil, enforced at compile time.  If so, a normal 
 pointer-which-may-be-nil would have to be represented as a Maybe[*T] or 
 union { *T | nil }. To use such a pointer value at runtime you'd have to 
 deconstruct it via a case statement or similar, with separate branches for 
 where the value is nil or not-nil. I am sure there have been proposals 
 along those lines floated here before.

 I don't think this would negatively affect code readability, because a 
 function which takes *T as an argument can be sure that the value passed 
 in 
 can never be

[go-nuts] Re: Why can't an interface type be a receiver

2022-04-04 Thread Ron Green 
in case anyone get's here and is confused...

you can wrap the additional functionality in the struct and use the 
interfaces from before

https://go.dev/play/p/e8aS0PZC6Zh

On Monday, February 2, 2015 at 2:55:30 PM UTC+2 oju...@gmail.com wrote:

> The code start to get smart when you combine interfaces.
>
> https://play.golang.org/p/axyl9FPS1e
>
> Whenever you can, forget the actual types. Code for interfaces instead.
>

-- 
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/177b5a39-3512-4aed-8b9a-e21d1389671en%40googlegroups.com.

[go-nuts] [security] Go 1.18.1 and Go 1.17.9 pre-announcement

2022-04-04 Thread Julie Qiu 
Hello gophers,

We plan to issue Go 1.18.1 and Go 1.17.9 on Thursday, April 7th.

These minor releases include a PRIVATE security fix to the standard library.

Following our security policy, this is the pre-announcement of those
releases.

Thanks,
Julie on behalf of the Go team

-- 
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/CAEE5VUE_5rvQF%3D_oNZVQDbSMwXq8nCf2ac1132hJR64A%2BNzd2Q%40mail.gmail.com.

Re: [go-nuts] Convert string to time.Duration

2022-04-04 Thread taylor 
Take a look at time.ParseDuration and its example: 
https://pkg.go.dev/time#ParseDuration

On Sun, Apr 3, 2022, at 3:48 PM, vika...@gmail.com wrote:
> I am looking to convert a *string* (say 4) to type *time.Duration*.
> 
> I've looked around but could not find a way to do so.
> 
> // https://go.dev/play/p/EUuDAY-Qx8N
> package main
> 
> import (
> "fmt"
> "time"
> )
> 
> func main() {
> // var addHours string = 4
> fmt.Println(time.Now().Local())
> timeAdd := time.Now().Local().Add(time.Hour * 4) // I want to use 4 from 
> a string variable here
> fmt.Println(timeAdd)
> }
> 
> 
> -- 
> 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/72d548fc-f572-4ff5-9516-3e13fa04850dn%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2a536720-605d-47e6-ab51-36cb12b75b3e%40www.fastmail.com.

[go-nuts] Re: Java to Go converter - 2

2022-04-04 Thread alex-coder 




*Another use case for automatically translating codewritten in Java to 
Golang is Exception Handling.The next example is likely to be about 
multithreading.Example in Java:*
package com.builder.start.here;

public class CatchException {

public static void main(String[] args) {
try {
new ThrowException().runme();
} catch (Exception e) {
System.out.println("yes, I caught it");
} finally {
System.out.println("finally processing");
}

}

}

class ThrowException{
public void runme() throws Exception{
throw new Exception();
}
}

*Converter gave out:*

package main

import (
"fmt"
"os"
)

type CatchException struct{}

func main() {

var args []string = os.Args

var ce CatchException = CatchException{}
ce.CatchException_main(args)
}

/** generated method **/
func (catchException *CatchException) CatchException_main(args []string) {
defer func() {
if err := recover(); err != nil {
str := err.(string)
switch str {
case "Exception":
fmt.Println("yes, I caught it")
default:
fmt.Println("No, something is not right")
}
}
fmt.Println("finally processing")
}()

({}).runme()
}

type ThrowException struct{}

func (throwException *ThrowException) runme() {
panic("Exception")
}
воскресенье, 27 марта 2022 г. в 15:11:48 UTC+3, alex-coder: 

> After several months of switching from Java to Golang, it seemed to me that
> it would be interesting to make the translation of Java code into Golang 
> automatically.
> The text below shows what has been done so far.
>
> The work is not a prototype, but rather indicates the possibility of 
> achieving a result.
> Therefore, I deliberately simplify the development context of the 
> Converter where it was 
> possible. 
>
> At first it seemed important to me that between Java and Go there is a 
> difference 
> between the implementation of the Dynamic Dispatching, more precisely, 
> there is no 
> Dynamic Dispatching in Go. The applied solution in the current 
> implementation 
> looks not only ugly but even violates the several very important rules of 
> the OO design, 
> I'm not kidding here. But this option looks like that it will be working. 
>
> Onward I will provide the 4 code samples in Java, followed by the 
> automatically 
> generated Golang code and comments as needed. 
>
> *1. Of course, I started with the most popular program: "Hello World".*
>
> package main;
>
> public class HelloWorld {
>   public static void main(  String[] args){
> System.out.println("Hello World");
>   }
> }
>
> *Converter gave out:*
>
> package main
>
> import (
> "fmt"
> "os"
> )
>
> type HelloWorld struct{}
>
> func main() {
>
> var args []string = os.Args
>
> var hw HelloWorld = HelloWorld{}
> hw.HelloWorld_main(args)
> }
>
> /** generated method **/
> func (helloWorld *HelloWorld) HelloWorld_main(args []string) {
> fmt.Println("Hello World")
> }
>
> *2. Next, it was interesting to deal with the problem of a simple 
> inheritance.*
>
> package main;
>
> public class TestInheritance {
>   public static void main(  String[] args){
> Inheritance inh=null;
> inh=new Second();
> inh.hello();
> inh=new Third();
> inh.hello();
>   }
> }
> public interface Inheritance {
>   public void hello();
> }
> class Second implements Inheritance {
>   public void hello(){
> System.out.println("Second");
>   }
> }
> class Third implements Inheritance {
>   public void hello(){
> System.out.println("Third");
>   }
> }
>  
> *Converter gave out:*
>
> package main
>
> import (
> "fmt"
> "os"
> )
>
> type TestInheritance struct{}
>
> func main() {
>
> var args []string = os.Args
>
> var ti TestInheritance = TestInheritance{}
> ti.TestInheritance_main(args)
> }
>
> /** generated method **/
> func (testInheritance *TestInheritance) TestInheritance_main(args 
> []string) {
>
> var inh Inheritance
> inh = AddressSecond(Second{})
> inh.hello()
> inh = AddressThird(Third{})
> inh.hello()
> }
>
> type Inheritance interface {
> hello()
> }
> type Second struct{}
>
> func (second *Second) hello() {
> fmt.Println("Second")
> }
>
> type Third struct{}
>
> func (third *Third) hello() {
> fmt.Println("Third")
> }
>
> func AddressSecond(s Second) *Second { return  }
> func AddressThird(t Third) *Third{ return  }
>
>
> *3. In the following example, it is necessary to correctly definea 
> common interface for the inheritance tree.*
>
> package no.packeges;
>
> public class TestExtension {
>   public static void main(  String[] args){
> TestExtension te=new TestExtension();
> te.hello();
> te=new Second();
> te.hello();
> te=new Third();
> te.hello();
> te=new Fourth();
>

[go-nuts] Re: Convert string to time.Duration

2022-04-04 Thread Amnon 
Use time.ParseDuration()

https://go.dev/play/p/SWUHBiSpflh

On Sunday, 3 April 2022 at 23:48:54 UTC+1 vika...@gmail.com wrote:

> I am looking to convert a *string* (say 4) to type *time.Duration*.
>
> I've looked around but could not find a way to do so.
>
> // https://go.dev/play/p/EUuDAY-Qx8N
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func main() {
> // var addHours string = 4
> fmt.Println(time.Now().Local())
> timeAdd := time.Now().Local().Add(time.Hour * 4) // I want to use 4 
> from a string variable here
> fmt.Println(timeAdd)
> }
>

-- 
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/f09becd3-c67d-4b13-b61d-d9ca1c8ae894n%40googlegroups.com.