Re: [go-nuts] Re: new range over int docs?

[Jason E. Aten]

On Wed, Feb 7, 2024 at 3:34 AM peterGo  wrote:

> You are reading a specification dated Version of Aug 2, 2023. The current
> specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 10:08:15 PM
> EST.
>

Link?   https://go.dev/ref/spec still gives me the Aug 2, 2023 spec, which
is what the 1.22 release notes points to.

-- 
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/CAPNEFAZ5ZLU4aGi9utmWm7b5_rgmvfiABaQjqUHFbA8YSMbqdw%40mail.gmail.com.

[go-nuts] Re: new range over int docs?

[peterGo]

Jason,

The Go specification "Length and capacity" section defines the len built-in 
function.

Peter

On Tuesday, February 6, 2024 at 11:36:21 PM UTC-5 peterGo wrote:

> Jason,
>
> The Go 1.22 specification, in part,
>
> For statements with range clause
>
> A "for" statement with a "range" clause iterates through all entries of an 
> array, slice, string or map, values received on a channel, or integer 
> values from zero to an upper limit [Go 1.22].
>
> For an integer value n, the iteration values 0 through n-1 are produced in 
> increasing order. If n <= 0, the loop does not run any iterations. 
>
> Peter
>
> On Tuesday, February 6, 2024 at 10:34:07 PM UTC-5 peterGo wrote:
>
>> Jason,
>>
>> The Go Programming Language Specification is reference documentation. It 
>> is intended to be read very carefully in its entirety.
>>
>> You are reading a specification dated Version of Aug 2, 2023. The current 
>> specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 10:08:15 PM 
>> EST.
>>
>> The specification has always said that len(10) is not somehow defined: 
>> "invalid 
>> argument: 10 (untyped int constant) for len".
>>
>> Peter
>>
>> On Tuesday, February 6, 2024 at 8:41:38 PM UTC-5 Jason E. Aten wrote:
>>
>>> The release notes https://go.dev/doc/go1.22 refer to the spec here
>>>
>>> https://go.dev/ref/spec#For_range
>>>
>>> but I do not see any details about the new for i := range 10 statement 
>>> there.
>>>
>>> This is strange. Have the docs simply not been updated yet?
>>>
>>> But I do see this oddly out of place statement, where I'm not sure at 
>>> all what x is referring to in the earlier paragraphs.
>>>
>>> "The range expression x is evaluated once before beginning the loop, 
>>> with one exception: if at most one iteration variable is present and 
>>> len(x) is constant , the 
>>> range expression is not evaluated."
>>>
>>> This would seem to say that, if x is the integer 10, as in the above 
>>> example, and if the len(10) is somehow defined (not sure it would be, but a 
>>> new reader might reasonably assume that an integer has constant length), 
>>> that the range expression would not be evaluated... which seems very odd. 
>>> I'm not sure what this sentence is talking about at all really.
>>>
>>

-- 
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/8b5ba931-2782-4538-bac2-78c5be735e33n%40googlegroups.com.

[go-nuts] Re: new range over int docs?

[peterGo]

Jason,

The Go 1.22 specification, in part,

For statements with range clause

A "for" statement with a "range" clause iterates through all entries of an 
array, slice, string or map, values received on a channel, or integer 
values from zero to an upper limit [Go 1.22].

For an integer value n, the iteration values 0 through n-1 are produced in 
increasing order. If n <= 0, the loop does not run any iterations. 

Peter

On Tuesday, February 6, 2024 at 10:34:07 PM UTC-5 peterGo wrote:

> Jason,
>
> The Go Programming Language Specification is reference documentation. It 
> is intended to be read very carefully in its entirety.
>
> You are reading a specification dated Version of Aug 2, 2023. The current 
> specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 10:08:15 PM 
> EST.
>
> The specification has always said that len(10) is not somehow defined: 
> "invalid 
> argument: 10 (untyped int constant) for len".
>
> Peter
>
> On Tuesday, February 6, 2024 at 8:41:38 PM UTC-5 Jason E. Aten wrote:
>
>> The release notes https://go.dev/doc/go1.22 refer to the spec here
>>
>> https://go.dev/ref/spec#For_range
>>
>> but I do not see any details about the new for i := range 10 statement 
>> there.
>>
>> This is strange. Have the docs simply not been updated yet?
>>
>> But I do see this oddly out of place statement, where I'm not sure at all 
>> what x is referring to in the earlier paragraphs.
>>
>> "The range expression x is evaluated once before beginning the loop, 
>> with one exception: if at most one iteration variable is present and 
>> len(x) is constant , the 
>> range expression is not evaluated."
>>
>> This would seem to say that, if x is the integer 10, as in the above 
>> example, and if the len(10) is somehow defined (not sure it would be, but a 
>> new reader might reasonably assume that an integer has constant length), 
>> that the range expression would not be evaluated... which seems very odd. 
>> I'm not sure what this sentence is talking about at all really.
>>
>

-- 
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/9dc3110b-a6a6-4db5-822c-b891be214982n%40googlegroups.com.

[go-nuts] Re: new range over int docs?

[peterGo]

Jason,

The Go Programming Language Specification is reference documentation. It is 
intended to be read very carefully in its entirety.

You are reading a specification dated Version of Aug 2, 2023. The current 
specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 10:08:15 PM 
EST.

The specification has always said that len(10) is not somehow defined: "invalid 
argument: 10 (untyped int constant) for len".

Peter

On Tuesday, February 6, 2024 at 8:41:38 PM UTC-5 Jason E. Aten wrote:

> The release notes https://go.dev/doc/go1.22 refer to the spec here
>
> https://go.dev/ref/spec#For_range
>
> but I do not see any details about the new for i := range 10 statement 
> there.
>
> This is strange. Have the docs simply not been updated yet?
>
> But I do see this oddly out of place statement, where I'm not sure at all 
> what x is referring to in the earlier paragraphs.
>
> "The range expression x is evaluated once before beginning the loop, with 
> one exception: if at most one iteration variable is present and len(x) is 
> constant , the range 
> expression is not evaluated."
>
> This would seem to say that, if x is the integer 10, as in the above 
> example, and if the len(10) is somehow defined (not sure it would be, but a 
> new reader might reasonably assume that an integer has constant length), 
> that the range expression would not be evaluated... which seems very odd. 
> I'm not sure what this sentence is talking about at all really.
>

-- 
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/4a4017cd-a312-4129-b302-9ed68beef4c4n%40googlegroups.com.

[go-nuts] new range over int docs?

[Jason E. Aten]

The release notes https://go.dev/doc/go1.22 refer to the spec here

https://go.dev/ref/spec#For_range

but I do not see any details about the new for i := range 10 statement 
there.

This is strange. Have the docs simply not been updated yet?

But I do see this oddly out of place statement, where I'm not sure at all 
what x is referring to in the earlier paragraphs.

"The range expression x is evaluated once before beginning the loop, with 
one exception: if at most one iteration variable is present and len(x) is 
constant , the range 
expression is not evaluated."

This would seem to say that, if x is the integer 10, as in the above 
example, and if the len(10) is somehow defined (not sure it would be, but a 
new reader might reasonably assume that an integer has constant length), 
that the range expression would not be evaluated... which seems very odd. 
I'm not sure what this sentence is talking about at all really.

-- 
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/01c51ea7-e09e-4e69-95eb-456981086764n%40googlegroups.com.

Re: [go-nuts] Re: Do we need to call multipart.Part.Close

[Ian Lance Taylor]

On Tue, Feb 6, 2024 at 6:29 AM Pedro Luis Guzmán Hernández
 wrote:
>
> Thanks Brian. That is an implementation detail though, so relying on it with 
> no mention in the documentation at all feels unsound. A Close method usually 
> means you have to defer it right after getting the resource, so I would have 
> expected the docs to be more clarifying on its usage.

Yeah, the Close method doesn't seem to be documented at all.  It would
be nice if somebody sent a patch.  Looks to me like you don't ever
have to call Close, and that it should probably not have been
exported.  It is called by Reader.nextPart, and I don't immediately
see any reason for it to be called anywhere else.

Ian


> El martes, 6 de febrero de 2024 a las 15:11:55 UTC+1, Brian Candler escribió:
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/mime/multipart/multipart.go;l=325
>>
>> All it does is read all the remainder of the part to io.Discard.  So if 
>> you're sure you've read each part before moving onto the next one, it looks 
>> like you should be good.
>>
>> On Tuesday 6 February 2024 at 13:34:16 UTC Pedro Luis Guzmán Hernández wrote:
>>>
>>> multipart.Part, returned by multipart.Reader's NextPart method, have a 
>>> Close() method. The only example here 
>>> https://pkg.go.dev/mime/multipart#NewReader doesn't use the Close() method 
>>> at all, so what's it purpose? Can we safely ignore it?
>>>
>>> The reason I'm asking is that, calling defer part.Closer is a bit annoying 
>>> when you loop through a Reader (see the example mentioned above). Calling 
>>> the defer within the loop means all parts are closed at the end of the 
>>> function. The alternative would be to have an anonymous function within the 
>>> loop and call defer within it, but it feels so awkward.
>
> --
> 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/6371b366-8474-46f0-99bc-510471fb879bn%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/CAOyqgcXp4_7wYsbgRWnuHJ1gto6V0YmpUXpKzBHC%2B%3D9W8A6u9w%40mail.gmail.com.

[go-nuts] Go 1.22.0 is released

[announce]

Hello gophers,

We have just released Go 1.22.0.

To find out what has changed in Go 1.22, read the release notes:
https://go.dev/doc/go1.22

You can download binary and source distributions from our download page:
https://go.dev/dl/#go1.22.0

If you have Go installed already, an easy way to try go1.22.0
is by using the go command:
$ go install golang.org/dl/go1.22.0@latest
$ go1.22.0 download

To compile from source using a Git clone, update to the release with
git checkout go1.22.0 and build as usual.

Thanks to everyone who contributed to the release!

Cheers,
David and Michael for 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/PLf3BJQNTb2guUAF3D2JSg%40geopod-ismtpd-5.

[go-nuts] Go 1.21.7 and Go 1.20.14 are released

[announce]

Hello gophers,

We have just released Go versions 1.21.7 and 1.20.14, minor point releases.

View the release notes for more information:
https://go.dev/doc/devel/release#go1.21.7

You can download binary and source distributions from the Go website:
https://go.dev/dl/

To compile from source using a Git clone, update to the release with
git checkout go1.21.7 and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
David and Michael for 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/0eS9o90ARf-9odgZZ3qmIg%40geopod-ismtpd-5.

[go-nuts] Re: Error on installing package

[Jason Phillips]

Perhaps you wanted "go get 154.pages.dev/google@v1.4.0"?

On Tuesday, February 6, 2024 at 11:36:11 AM UTC-5 Jason Phillips wrote:

> There's no Go package at the root of that repo/module, and thus nothing to 
> install. "go install" only works on main packages.
>
> On Tuesday, February 6, 2024 at 8:34:07 AM UTC-5 Smit K wrote:
>
>> With this command: go install 154.pages.dev/goo...@v1.4.0 
>> 
>> It is not installing: [image: Screenshot 2024-02-06 180047.png]
>
>

-- 
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/c1136e42-c0c4-4f48-b5b3-25b74c827673n%40googlegroups.com.

[go-nuts] Re: Error on installing package

[Jason Phillips]

There's no Go package at the root of that repo/module, and thus nothing to 
install. "go install" only works on main packages.

On Tuesday, February 6, 2024 at 8:34:07 AM UTC-5 Smit K wrote:

> With this command: go install 154.pages.dev/goo...@v1.4.0 
> 
> It is not installing: [image: Screenshot 2024-02-06 180047.png]

-- 
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/422bb367-bc0a-4b19-9ced-d04855c6b4e8n%40googlegroups.com.

Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

[fgergo]

(This time reply to list. Sorry Brian.)

On Tue, Feb 6, 2024 at 3:03 PM 'Brian Candler' via golang-nuts
 wrote:
>
> > Thanks! In addition to that, It also helps with code with upper limit
> > memory-requirement, which fmt.Sprintf() can't.
>
> If you're processing data from untrusted sources, then you probably ought to 
> validate it first.
>
> > How to use a limiting
> > io.Writer with fmt.Sprintf()? How would this limit fmt.Sprintf()'s
> > memory usage?
>
> Proof-of-concept: https://go.dev/play/p/kJabvvTzFH0
>
> I don't know under what circumstances this would cause Fprintf to terminate 
> early; it depends on how much buffering it does internally. I would guess 
> that a large single argument like "%s" would be treated as a single entity, 
> and very likely allocate an intermediate buffer of the full size.
>
> If this matters in your use case, then I think you shouldn't be using Sprintf 
> and friends.
I should probably limit memory usage outside of the process anyway.
A bit unexpected, though I'm not complaining.
cheers

-- 
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/CA%2BctqrraLr%3Dh%2BXuPGOzgfu%3DQD0O_abqMm4bSX6LPPPtGMxwejA%40mail.gmail.com.

[go-nuts] Re: Do we need to call multipart.Part.Close

['Brian Candler' via golang-nuts]

Documentation could certainly be improved, since the Part.Close() method 
 has literally no 
documentation.

Whilst it does feel unsound, in practice I don't think the behaviour could 
be changed now without breaking the Go compatibility guarantee (unless it 
was fundamental to a security issue, and even then I'd expect it to allow 
existing use cases).

On Tuesday 6 February 2024 at 14:29:07 UTC Pedro Luis Guzmán Hernández 
wrote:

> Thanks Brian. That is an implementation detail though, so relying on it 
> with no mention in the documentation at all feels unsound. A Close method 
> usually means you have to defer it right after getting the resource, so I 
> would have expected the docs to be more clarifying on its usage.
> El martes, 6 de febrero de 2024 a las 15:11:55 UTC+1, Brian Candler 
> escribió:
>
>>
>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/mime/multipart/multipart.go;l=325
>>
>> All it does is read all the remainder of the part to io.Discard.  So if 
>> you're sure you've read each part before moving onto the next one, it looks 
>> like you should be good.
>>
>> On Tuesday 6 February 2024 at 13:34:16 UTC Pedro Luis Guzmán Hernández 
>> wrote:
>>
>>> multipart.Part, returned by multipart.Reader's NextPart method, have a 
>>> Close() method. The only example here 
>>> https://pkg.go.dev/mime/multipart#NewReader doesn't use the Close() 
>>> method at all, so what's it purpose? Can we safely ignore it?
>>>
>>> The reason I'm asking is that, calling *defer part.Closer *is a bit 
>>> annoying when you loop through a Reader (see the example mentioned above). 
>>> Calling the defer within the loop means all parts are closed at the end of 
>>> the function. The alternative would be to have an anonymous function within 
>>> the loop and call defer within it, but it feels so awkward.
>>
>>

-- 
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/ce483cc2-3129-4fe7-a594-84afe9c76248n%40googlegroups.com.

[go-nuts] Bound check optimization with "computed" index

[Leonard Mittmann]

I am trying to optimize the loop performance by reducing the number of 
bound checks. Inside the loop I compute a slice index and access two slice 
indexes like this:

j := i / 2
s[j+1] = i
s[j] = i // <- I want to get rid of this bound check

I assumed that I can get rid of the second bound check, as the compiler 
could already know that j+1 < len(s) and j >= 0. Am I missing something? 
Any suggestions how to solve this?

The full boiled down code to reproduce my issue is here: 
https://go.godbolt.org/z/hsjPh3WT7

-- 
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/832957ee-05c9-44cb-9c0c-67ecff8068bfn%40googlegroups.com.

Re: [go-nuts] Embedding an interface with a function type

[Victor Manuel Giordano]

Thanks

El mar, 6 feb 2024 a las 12:05, Ian Lance Taylor ()
escribió:

> On Tue, Feb 6, 2024 at 6:43 AM Victor Manuel “Vitu” Giordano
>  wrote:
> >
> > I'm wondering why the language allow me to write something like this:
> >
> > type IncFunc func(a int) int
> >
> > type Incrementor interface {
> > IncFunc // <-- THIS is allowed
> > IncQuantity() int
> > }
> >
> > (RTR example here)
> >
> > I don't get how I can make leverage of that.. or if has any sense at all
> 若‍
> > As I recall an interface is a set of methods, and a method do have a
> name... the thing here is that the name if the name of the type not the
> function's name.
>
> An interface type like that can be used as a constraint for a type
> parameter.  It can't be used as the type of a variable.  As a type
> parameter constraint it means that the type argument must be IncFunc.
> It's fairly useless, but follows from the other rules about type
> parameter constraints.
>
> Ian
>


-- 
V

-- 
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/CAPUu9ssWofyST_KX3htbcR4aN09gi6MTr%2B9kBxmXaFEiFG6T2A%40mail.gmail.com.

Re: [go-nuts] Embedding an interface with a function type

[Ian Lance Taylor]

On Tue, Feb 6, 2024 at 6:43 AM Victor Manuel “Vitu” Giordano
 wrote:
>
> I'm wondering why the language allow me to write something like this:
>
> type IncFunc func(a int) int
>
> type Incrementor interface {
> IncFunc // <-- THIS is allowed
> IncQuantity() int
> }
>
> (RTR example here)
>
> I don't get how I can make leverage of that.. or if has any sense at all 若‍
> As I recall an interface is a set of methods, and a method do have a name... 
> the thing here is that the name if the name of the type not the function's 
> name.

An interface type like that can be used as a constraint for a type
parameter.  It can't be used as the type of a variable.  As a type
parameter constraint it means that the type argument must be IncFunc.
It's fairly useless, but follows from the other rules about type
parameter constraints.

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/CAOyqgcUS1V4ss%3D9tbAOxMBpCxNoFunJPgF_pgYFZw_%3DAB_%3DPOw%40mail.gmail.com.

[go-nuts] Embedding an interface with a function type

[Victor Manuel “Vitu” Giordano]

Hi Goperhs! How you doing? Hope just fine!

I'm wondering why the language allow me to write something like this:

type IncFunc func(a int) int

type Incrementor interface {
IncFunc *// <-- THIS is allowed*
IncQuantity() int
}

(RTR example here )

I don't get how I can make leverage of that.. or if has any sense at all 
若‍
As I recall an interface is a set of methods, and a method do have a 
name... the thing here is that the name if the name of the type not the 
function's name. 

Thanks in advance.
Víctor.



-- 
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/233f8e98-1c59-442b-b2d1-282a2e1f231en%40googlegroups.com.

[go-nuts] Re: Do we need to call multipart.Part.Close

[Pedro Luis Guzmán Hernández]

Thanks Brian. That is an implementation detail though, so relying on it 
with no mention in the documentation at all feels unsound. A Close method 
usually means you have to defer it right after getting the resource, so I 
would have expected the docs to be more clarifying on its usage.
El martes, 6 de febrero de 2024 a las 15:11:55 UTC+1, Brian Candler 
escribió:

>
> https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/mime/multipart/multipart.go;l=325
>
> All it does is read all the remainder of the part to io.Discard.  So if 
> you're sure you've read each part before moving onto the next one, it looks 
> like you should be good.
>
> On Tuesday 6 February 2024 at 13:34:16 UTC Pedro Luis Guzmán Hernández 
> wrote:
>
>> multipart.Part, returned by multipart.Reader's NextPart method, have a 
>> Close() method. The only example here 
>> https://pkg.go.dev/mime/multipart#NewReader doesn't use the Close() 
>> method at all, so what's it purpose? Can we safely ignore it?
>>
>> The reason I'm asking is that, calling *defer part.Closer *is a bit 
>> annoying when you loop through a Reader (see the example mentioned above). 
>> Calling the defer within the loop means all parts are closed at the end of 
>> the function. The alternative would be to have an anonymous function within 
>> the loop and call defer within it, but it feels so awkward.
>
>

-- 
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/6371b366-8474-46f0-99bc-510471fb879bn%40googlegroups.com.

[go-nuts] Re: Do we need to call multipart.Part.Close

['Brian Candler' via golang-nuts]

https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/mime/multipart/multipart.go;l=325

All it does is read all the remainder of the part to io.Discard.  So if 
you're sure you've read each part before moving onto the next one, it looks 
like you should be good.

On Tuesday 6 February 2024 at 13:34:16 UTC Pedro Luis Guzmán Hernández 
wrote:

> multipart.Part, returned by multipart.Reader's NextPart method, have a 
> Close() method. The only example here 
> https://pkg.go.dev/mime/multipart#NewReader doesn't use the Close() 
> method at all, so what's it purpose? Can we safely ignore it?
>
> The reason I'm asking is that, calling *defer part.Closer *is a bit 
> annoying when you loop through a Reader (see the example mentioned above). 
> Calling the defer within the loop means all parts are closed at the end of 
> the function. The alternative would be to have an anonymous function within 
> the loop and call defer within it, but it feels so awkward.

-- 
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/06a6bef9-cac1-4b0d-a04f-343f58e6f566n%40googlegroups.com.

Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

['Brian Candler' via golang-nuts]

> Thanks! In addition to that, It also helps with code with upper limit
> memory-requirement, which fmt.Sprintf() can't.

If you're processing data from untrusted sources, then you probably ought 
to validate it first.

> How to use a limiting
> io.Writer with fmt.Sprintf()? How would this limit fmt.Sprintf()'s
> memory usage?

Proof-of-concept: https://go.dev/play/p/kJabvvTzFH0

I don't know under what circumstances this would cause Fprintf to terminate 
early; it depends on how much buffering it does internally. I would guess 
that a large single argument like "%s" would be treated as a single entity, 
and very likely allocate an intermediate buffer of the full size.

If this matters in your use case, then I think you shouldn't be using 
Sprintf and friends.

-- 
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/960530e8-b872-4c86-8232-8fad8bd9d76cn%40googlegroups.com.

[go-nuts] Do we need to call multipart.Part.Close

[Pedro Luis Guzmán Hernández]

multipart.Part, returned by multipart.Reader's NextPart method, have a 
Close() method. The only example 
here https://pkg.go.dev/mime/multipart#NewReader doesn't use the Close() 
method at all, so what's it purpose? Can we safely ignore it?

The reason I'm asking is that, calling *defer part.Closer *is a bit 
annoying when you loop through a Reader (see the example mentioned above). 
Calling the defer within the loop means all parts are closed at the end of 
the function. The alternative would be to have an anonymous function within 
the loop and call defer within it, but it feels so awkward.

-- 
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/7d20c337-6037-4020-9f80-bc5cc86aa115n%40googlegroups.com.

[go-nuts] Error on installing package

[Smit K]

With this command: go install 154.pages.dev/google@v1.4.0
It is not installing: [image: Screenshot 2024-02-06 180047.png]

-- 
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/612d4e47-7f05-42d5-874d-e1c50ba8b75en%40googlegroups.com.

Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

[fgergo]

On Tue, Feb 6, 2024 at 12:18 PM 'Brian Candler' via golang-nuts
 wrote:
>
> The C functions are mainly there to prevent overrunning already-allocated 
> buffers, which isn't an issue with Go.
Thanks! In addition to that, It also helps with code with upper limit
memory-requirement, which fmt.Sprintf() can't.
Though I can live with careful coding and not using Sprintf() in this
case, I just hoped possibly somebody else already thought about
needing that.

...
> You could make a custom type which implements io.Writer and truncates at a 
> given size, and pass it to fmt.Fprintf
IIUC this sounds similar to what I'm asking for. How to use a limiting
io.Writer with fmt.Sprintf()? How would this limit fmt.Sprintf()'s
memory usage?

-- 
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/CA%2Bctqro%3D9St0Qj_A-UGEUowvjK1OHX%3DQJ2QiBAMQdxZBwvHM%2Bw%40mail.gmail.com.

[go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

['Brian Candler' via golang-nuts]

The C functions are mainly there to prevent overrunning already-allocated 
buffers, which isn't an issue with Go.

You could truncate the response:

a := fmt.Sprintf("%s", "Blah blah blah")[0:10]

You could use suitable precision specifiers:

a := fmt.Sprintf("%.10s", "Blah blah blah")

You could make a custom type which implements io.Writer and truncates at a 
given size, and pass it to fmt.Fprintf

On Tuesday 6 February 2024 at 09:52:29 UTC fge...@gmail.com wrote:

> C *nprintf(3) implementations stop the conversion when n is reached.
> I couldn't find a similar functionality in the standard library, what
> did I miss?
> If there isn't any, any idea how to implement that without
> reimplementing all format helpers?
> 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/966c0d89-1570-4837-bf5c-657c09ca43e4n%40googlegroups.com.

[go-nuts] snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

[fgergo]

C *nprintf(3) implementations stop the conversion when n is reached.
I couldn't find a similar functionality in the standard library, what
did I miss?
If there isn't any, any idea how to implement that without
reimplementing all format helpers?
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/CA%2BctqroOignMzqDar4Vq9k_B3f6N%2B5BnDhvggwkdczh%2BeT_irQ%40mail.gmail.com.