On Friday, July 17, 2020 at 11:21:32 AM UTC+12 va...@selfip.ru wrote:
> вт, 14 июл. 2020 г. в 18:39, Jake Montgomery :
> >
> > I agree, it seems like an unfortunate oversight. You can do it without
> the slice tricks: https://play.golang.org/p/tNAPOcQqApN
> > It does take an additional
thanks. I've noticed the code,too. And that's what I'm confused: when there
is a create, there is no delete, and I can not find the file under
os.TemDir()
Seems I have to debug the code to find the removing line.
On Friday, July 17, 2020 at 9:06:22 AM UTC+8, Jonathan Reiter wrote:
>
> See the
Since readability is impacted by consequitive lists, you could factor it out...
with ( type list )
func ( arg list ) etc...
--
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
See the multipart function definition. Line 86 deals with the actual temp
file writes.
https://golang.org/src/mime/multipart/formdata.go?s=3015:3047#L34
Do note that under certain conditions, a multipart form might hold on
closing and deleting the multipart files in temp. Debugging async code
thx. Can you help me find the link or doc which describe the detail of "
removed once the request finished" ?
On Thursday, July 16, 2020 at 7:32:06 PM UTC+8, Jesper Louis Andersen wrote:
>
> They will be removed once the request finishes. The way to access them is
> usually by the FormFile
Hello gophers,
We have just released Go versions 1.14.6 and 1.13.14, minor point releases.
View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.14.minor
You can download binary and source distributions from the Go web site:
https://golang.org/dl/
Best proposal yet! I see increased Go adoption in the hipster /craft beer
community.
> On Jul 16, 2020, at 6:49 PM, Denis Cheremisov
> wrote:
>
> func XGenericFunction(x X) …
>
> пятница, 17 июля 2020 г. в 01:25:29 UTC+3, kortschak:
>> On Thu, 2020-07-16 at 13:44 -0700, jpap wrote:
>>
func XGenericFunction(x X) …
пятница, 17 июля 2020 г. в 01:25:29 UTC+3, kortschak:
> On Thu, 2020-07-16 at 13:44 -0700, jpap wrote:
> > Notwithstanding a concise unambiguous alternative, I would rather
> > type parameters "stick out" so they are easily identified when
> > visually scanning
вт, 14 июл. 2020 г. в 18:39, Jake Montgomery :
>
> I agree, it seems like an unfortunate oversight. You can do it without the
> slice tricks: https://play.golang.org/p/tNAPOcQqApN
> It does take an additional Sprintf() though.
>
Thanks, looks good. But i think for go devs adding additional
On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett wrote:
>
> I have just read
> https://github.com/golang/go/issues/33892#issuecomment-659618902 and since it
> was posted on a closed issue I wanted to comment a bit more.
>
> I subscribed to this issue and read the updates for both the Go2
On Thu, 2020-07-16 at 13:44 -0700, jpap wrote:
> Notwithstanding a concise unambiguous alternative, I would rather
> type parameters "stick out" so they are easily identified when
> visually scanning through code.
func ᕙ(⇀ X ↼‶)ᕗ GenericFunction(x X) ...
--
You received this message because
>I can accept draft as is
I've changed my mind about my suggestion. I can also accept and fully
support draft as is! It is fantastic.
On Fri, Jul 17, 2020 at 12:10 AM Matthias Mädel <
medienwerksalzb...@gmail.com> wrote:
> Just some considerations...
>
> Generics syntax is a constraint of the
Just some considerations...
Generics syntax is a constraint of the Parser
Gen ops used with dB/ML/wire stuff...
Encapsulating parantheses follow logic
The type keyword shows the functionality
square brackets introduce a, not only visual,
distraction/confusion
I can accept draft as is
--
You
On Thu, Jul 16, 2020 at 11:50 PM burak serdar wrote:
>
> [_ _] is ambiguous though, because _ is also an identifier character.
> [_x_] can be parsed as indexing with identifier _x_
>
Yes, _int_ is an allowed identifier in Go. However per the suggestion at
the top of the present thread the
On Thu, Jul 16, 2020 at 3:43 PM Robert Viragh wrote:
>
> Hi guys,
>
> Great conversation! I think that seeing a lot of edge cases would make it
> easiest to see what is best.
>
> Since the conversation went into [[ and ]]
>
> Before coming up with [_ and _] I very strongly considered [[ and ]]
Hi guys,
Great conversation! I think that seeing a lot of edge cases would make it
easiest to see what is best.
*Since the conversation went into [[ and ]]*
Before coming up with [_ and _] I very strongly considered [[ and ]]
because I thought things should be orthogonal and different things
On Thursday, 16 July 2020 at 22:44:21 UTC+2 jpap wrote:
> I don't think [[T]] is offensive to the surrounding code, and would love
> to know what more people think.
>
It becomes even worse once you nest generic types:
MyMap[[string, MyList[[int
--
You received this message because
Notwithstanding a concise unambiguous alternative, I would rather type
parameters "stick out" so they are easily identified when visually scanning
through code. I read a lot more code than I write, even as I write Go
full-time.
Here are two playgrounds (that don't format/run) comparing a
I have just read
https://github.com/golang/go/issues/33892#issuecomment-659618902 and since
it was posted on a closed issue I wanted to comment a bit more.
I subscribed to this issue and read the updates for both the Go2 proposals
as well as the Go1 proposals and I enjoy reading them. I
Generics are not the most important part of the language/code. Let's not
make them stick out like a sore thumb.
On Thursday, 16 July 2020 at 22:12:17 UTC+2 jpap wrote:
> On Thursday, 16 July 2020 at 12:51:03 UTC-7 Ian Lance Taylor wrote:
>
>> On Thu, Jul 16, 2020 at 12:41 PM joshua harr wrote:
On Thursday, 16 July 2020 at 12:51:03 UTC-7 Ian Lance Taylor wrote:
> On Thu, Jul 16, 2020 at 12:41 PM joshua harr wrote:
> > Just a note on your rationale for why not to use <: :> :
> > "... requires more typing." Golang has, rather famously, never shied
> away from making developers type
Why not have a github emoji vote.
1. () `type MyMap(K comparable, V something) struct { m map[k]v }; fn(int,
float)(4, .20);`
2. [] `type MyMap[K comparable, V something] struct { m map[k]v }; fn[int,
float](4, .20);`
3. <::> `type MyMap<:K comparable, V something:> struct { m map[k]v };
On Thu, Jul 16, 2020 at 12:41 PM joshua harr wrote:
>
> Just a note on your rationale for why not to use <: :> :
> "... requires more typing." Golang has, rather famously, never shied away
> from making developers type more. The reason it hasn't, as far as I
> understand, is that code is read
On Thu, Jul 16, 2020 at 12:41 PM Jay Kay wrote:
>
> Which code snippet(s) in GO would be 100 percent unambiguous as generics:
>
> a) [g]
> b) {g}
> c)
> d) «g»
It's impossible to accurately answer this kind of question without
more syntax details, and it depends on what you mean by 100 percent
Which code snippet(s) in GO would be 100 percent unambiguous as generics:
a) [g]
b) {g}
c)
d) «g»
--
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
Just a note on your rationale for why not to use <: :> :
"... requires more typing." Golang has, rather famously, never shied away
from making developers type more. The reason it hasn't, as far as I
understand, is that code is read far often than it is written, and so the
extra verbosity is
Here's a short tutorial showing how to write unit tests for AWS S3
downloads:
https://medium.com/@tufin/a-testable-go-aws-s3-scanner-e54de0c26197
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
I think something unfortunate happened to your diagram. On Gmail, I see an
tag with a huge amount of base64 encoded text, and on Google Groups I
don't see anything at all. It may work better to upload the image to a
hosting service like Imgur and link to it.
On Thu, Jul 16, 2020 at 9:47 AM
Thanks for that data point, Nick. It's a good idea to make the build fail
if GO386 is set to 387 if we drop support. It already fails if GO386 is set
to any unsupported value, but we could continue to check GO386 even though
there would only be one supported value, and perhaps give a nicer error
Why not try the design of Feel language,
There is no ambiguity and no more code.
```
type [Item T] struct {
Value T
}
func (it [Item T]) Print() {
println(it.Value)
}
func [TestGenerics T V]() {
var a = [Item T]{}
a.Print()
var b = [Item V]{}
Hello, it depends on OS. You can show it in your logs, with something
like that: log.Infof("Directory for storing large files: %s",
os.TempDir())
В Чт, 16/07/2020 в 03:44 -0700, hao dong пишет:
> As I have learned, http server will store user-upload file on disk
> when its size exceed 32MB.
> I
`generics` looks like a space ,
like c++ namespace/classSpace use `::` `.` `->`
and `::` is not used in golang.
```
type A::(x,y,z) struct{ }
func f::(x,y,z)()(){}
interface B::(x,y,z)()(){}
[]S::(x,y,z){}
```
`FOO::(x,y,z)` just like a `string` for naming .
and the args x,y,z
Its worth noting that Rust does something similar with the "turbofish"
operator in expressions:
"42".parse::()
I personally think this works quite well.
On Wednesday, July 15, 2020 at 5:41:51 AM UTC-7, Michal Strba wrote:
>
> Angle brackets are only problematic in expressions in the bodies of
On Thu, Jul 16, 2020 at 3:12 PM 'Axel Wagner' via golang-nuts
wrote:
> I dislike the idea of using $ and @ because I don't want to add new symbols
> to the language, if it can be avoided. In general I'd argue that Go tends to
> use keywords instead of symbols to convey meaning - e.g. we don't
I dislike the idea of using $ and @ because I don't want to add new symbols
to the language, if it can be avoided. In general I'd argue that Go tends
to use keywords instead of symbols to convey meaning - e.g. we don't write
`a -> b`, but `func(a) b`. There are exceptions (pointers are a big one)
Resending to the list after mistakenly replied off list. My apologies.
On Wed, Jul 15, 2020 at 10:59 PM Ian Lance Taylor wrote:
> Thanks for the detailed writeup.
It might have been too detailed and suffered from low information
density. Let me amend it with a tl;dr:
1. The main
See the documentation of `os.TempDir` at https://golang.org/pkg/os/#TempDir
> On Windows, it uses GetTempPath, returning the first non-empty value from
> %TMP%, %TEMP%, %USERPROFILE%, or the Windows directory.
Lutz
Von: golang-nuts@googlegroups.com im
They will be removed once the request finishes. The way to access them is
usually by the FormFile method on *http.Request or to create a multipart
reader and break it out yourself.
The reason the latter is interesting is because it can avoid storing data
you are not prepared to handle.
On Thu,
As I have learned, http server will store user-upload file on disk when its
size exceed 32MB.
I read the source code, and find out the large file to store in
os.TempDir(), however, after uploading a large file, I can not find the
file in the temp dir.
Cloud someone enlight me, where is the temp
The next thing to do is to boil this down to a standalone test case in the
golang playground.
Are you saying the template is not being expanded correctly at line 155?
https://github.com/ali2210/WizDwarf/blob/master/main.go#L155
Are you sure the value of LifeCode is what you expect? Try
This is good. I have been reaching for a consistency check and this just
may be it.
On Thu, Jul 16, 2020 at 12:04 AM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> On Wed, 2020-07-15 at 14:36 -0700, Randall O'Reilly wrote:
> > And the use of [ ] in map is more
41 matches
Mail list logo
