On Wednesday, July 15, 2020 at 6:41:51 AM UTC-6 Michal Strba wrote:
> What about using a dot when specializing in bodies?
>
> func main() {
> x := zero.() // requires a dot
> }
>
What are all the kinds of "generic expressions" we would need to support?
Go allows incomplete
I think you can use <:T:> or <<>> or .
Among them, is the most convenient to input,
because < and? Are very close on the keyboard, so you can input quickly
gri在 2020年7月15日星期三上午5:56:01 [UTC+8]寫道：
> We have received a variety of feedback on the generics draft design
>
In addition to what Jesper said, the walk pass does a variety of lowerings
and optimizations on the ast. For example, it rewrites the builtin `new` to
a runtime call, rewrites switches to a tree of `if` statements, etc.
On Monday, July 20, 2020 at 2:11:08 AM UTC-7 jesper.lou...@gmail.com wrote:
> https://golang.org/issue/35283
Yup, thanks for pointing this out.
On Tuesday, July 21, 2020 at 12:09:07 AM UTC+3 Ian Lance Taylor wrote:
> On Mon, Jul 20, 2020 at 12:48 PM Yuriy Yarosh wrote:
> >
> > > don't think it's going to be feasible to make it possible to
> > replace the standard
On Mon, Jul 20, 2020 at 12:48 PM Yuriy Yarosh wrote:
>
> > don't think it's going to be feasible to make it possible to
> replace the standard library net package.
>
> Well, I'm not proposing to replace entirely, just to add some annotations for
> the compiler, like use this instead of net
On Mon, Jul 20, 2020 at 1:40 PM Mahdi Hosseini wrote:
>
> Thanks that was a valuable information. It might be the debugging flag that
> caused the issue. I debugged the cgo file and found that in char* mached with
> dwarf.UcharType instead of dwarf.chatType
I think that that in itself
Hi all,
I was wondering if (or to what extend) gc supports generation of SIMD
instructions on arm64. Especially: is it possible to set a compile time
flag such that gc creates NEON instructions only or NEON and especially
SVE instructions?
best wishes,
Stefan
--
You received this
Thanks that was a valuable information. It might be the debugging flag that
caused the issue. I debugged the cgo file and found that in char* mached
with dwarf.UcharType instead of dwarf.chatType
On Monday, July 20, 2020 at 3:45:00 PM UTC-4, Ian Lance Taylor wrote:
>
> On Mon, Jul 20, 2020 at
Hi,
given the discussion here, the blog post I just published might be
interesting:
https://blog.merovius.de/2020/07/20/parametric-context.html
To the best of my knowledge, what I describe there is only really doable
using embedded type-parameters. As I state in the conclusion, I'm not
entirely
> don't think it's going to be feasible to make it possible to
replace the standard library net package.
Well, I'm not proposing to replace entirely, just to add some annotations
for the compiler, like use this instead of net package over here...
> That's a lot of work and a
massive increase
On Mon, Jul 20, 2020 at 12:28 PM Mahdi Hosseini wrote:
>
> Hi,
> I try to recompile Go for a new platform which is a s390x platform using
> Clang instead of GCC. I can not work for C string in CGO. Apparently char in
> unsigned by default on my platform and building even the simple CGO program
I'm think I understand the go-1.14 downloadable module workflow. But I'm
not getting how to use modules in an enterprise system where we cannot
allow automated downloads or where I want to include packages from one
local module in another where neither are available on any public
download
On Mon, Jul 20, 2020 at 12:26 PM Geoff Speicher wrote:
>
> On Mon, Jul 20, 2020 at 2:04 PM Ian Lance Taylor wrote:
>>
>> On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher wrote:
>> >
>> > This is great work but compared to the rest of Go's existing syntax, I
>> > personally find it much harder to
On Mon, Jul 20, 2020 at 12:23 PM Yuriy Yarosh wrote:
>
> Basically I'm replacing net package partially rn with custom DPDK-enabled
> impl right now i.e. everything syscall.Socket related.
> It's not about the protocols, it's about replacing whole BSD sock API and
> epoll/kqueue with a custom
Hi,
I try to recompile Go for a new platform which is a s390x platform using
Clang instead of GCC. I can not work for C string in CGO. Apparently char
in unsigned by default on my platform and building even the simple CGO
program always fails with this error:
On Mon, Jul 20, 2020 at 2:04 PM Ian Lance Taylor wrote:
> On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher wrote:
> >
> > This is great work but compared to the rest of Go's existing syntax, I
> personally find it much harder to grok the generic code examples regardless
> of bracket choice.
> >
>
Basically I'm replacing net package partially rn with custom DPDK-enabled
impl right now i.e. everything syscall.Socket related.
It's not about the protocols, it's about replacing whole BSD sock API and
epoll/kqueue with a custom impl enterily.
I've managed to impl a PoC for this, might create
On Mon, Jul 20, 2020 at 12:06 PM Guido Chari wrote:
>
> I am trying to compile a go program with santizers using gollvm and I can not
> workaround it. Is that possible?
As far as I know nobody has tried to make the various sanitizers work
with GoLLVM. It's probably possible, but I would expect
No problem, i'm just curious.
Thanks.
mai
在2020年7月21日星期二 UTC+8 上午2:42:58 写道：
> On Mon, Jul 20, 2020 at 11:29 AM yangw...@gmail.com
> wrote:
> >
> > The size of the archived go distributions is growing in newer go release.
> >
> > My question:
> > What are the main contents of these additions?
Hi,
I am trying to compile a go program with santizers using gollvm and I can
not workaround it. Is that possible?
Cheers,
Guido.
--
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
All you are doing is replicating manual memory management. If you are going to
do that just use CGo with malloc & free so you will have decent debugging.
If not, don’t do this at all and let the GC do its work (but Go lack of a
generational GC might be an issue here).
> On Jul 20, 2020, at
On Mon, Jul 20, 2020 at 11:29 AM yangw...@gmail.com
wrote:
>
> The size of the archived go distributions is growing in newer go release.
>
> My question:
> What are the main contents of these additions? Can the size of the archived
> go distributions be reduced?
The Go 1 compatibility guarantee
On Mon, Jul 20, 2020 at 7:53 AM Yuriy Yarosh wrote:
>
> Basically I've got some different tcp/ip stack implementations based on DPDK
> and want to be able to replace existing types and methods of the stock net
> package, which would allow to add DPDK support for existing apps without any
>
[ + thanm, cherryyz ]
On Mon, Jul 20, 2020 at 4:24 AM Yuan Ting wrote:
>
> Hi, I try to build hugo with fresh gollvm but the linker complains that:
>
> # github.com/gohugoio/hugo
> /usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match
> split-stack sequence at section 1 offset
The size of the archived go distributions is growing in newer go release.
My question:
What are the main contents of these additions? Can the size of the archived
go distributions be reduced?
在2020年7月21日星期二 UTC+8 上午2:16:19 写道：
> On Mon, Jul 20, 2020 at 10:41 AM yangw...@gmail.com
> wrote:
> >
On Mon, Jul 20, 2020 at 11:13 AM medienwer...@gmail.com
wrote:
>
> re : "However, I don't understand how to make
> that work in practice. "
>
> from my research so far I found tons of Github Actions related to
> "Projects"...
>
> just some examples:
>
On Mon, Jul 20, 2020 at 10:41 AM yangw...@gmail.com
wrote:
>
> Yes, I'm asking about the size of the archived go distributions.
Thanks. Now that we understand that, what is your question?
Ian
> 在2020年7月19日星期日 UTC+8 上午12:11:02 写道：
>>
>> You are asking about the size of the archived go
Dear Ian
re : "However, I don't understand how to make
that work in practice. "
from my research so far I found tons of Github Actions related to
"Projects"...
just some examples:
https://github.com/marketplace/actions/all-in-one-project
On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher wrote:
>
> This is great work but compared to the rest of Go's existing syntax, I
> personally find it much harder to grok the generic code examples regardless
> of bracket choice.
>
> It seems like a lot of complication stems from what effectively
On Mon, Jul 20, 2020 at 9:41 AM Rei Roldan wrote:
>
> I agree, I prefer the D syntax as well.
>
> type!T Point struct {
> x, y int
> data !T
> }
>
> type Transformer interface {
> Transform(!R) !S
> }
>
> func Stringify(s []!T) string {
> }
>
> type Vector []!T
>
> Easy and readable
On Mon, Jul 20, 2020 at 7:22 AM christoph...@gmail.com
wrote:
>
> I would like to insist on considering the D syntax using the ! for generics
> instantiation.
>
> The first time I saw it, I was puzzled and found it unpleasant. But this is
> just because it is unfamiliar and not intuitive.
>
On Mon, Jul 20, 2020 at 1:23 AM Xie Zhenye wrote:
>
> Requiring type-information for parsing will brings difficulty for
> implementing these tools, but not impossible. To solve ambiguity, the only
> requiring type-information is wether a symbol is a type name or an
> identifier. A parser
Check https://godoc.org/modernc.org/memory, maybe it can be used in this
scenario. Note, using the package concurrently from multiple goroutines
requires coordination, like with a mutex.
On Mon, Jul 20, 2020, 19:35 wrote:
> I have an application where I will be allocating millions of data
>
Yes, I'm asking about the size of the archived go distributions.
在2020年7月19日星期日 UTC+8 上午12:11:02 写道：
> You are asking about the size of the archived go distributions, NOT about
> the size of programs built with go, correct?
>
>
> On Friday, July 17, 2020 at 5:33:31 PM UTC-4, yangw...@gmail.com
I have an application where I will be allocating millions of data
structures, all of the same size. My program will need to run continuously
and be pretty responsive to
its network peers.
The data is fairly static, once allocated it will rarely need to be
modified or deleted.
In order to
This is great work but compared to the rest of Go's existing syntax, I
personally find it much harder to grok the generic code examples regardless
of bracket choice.
It seems like a lot of complication stems from what effectively amounts to
requiring the programmer to declare a new generic
I agree, I prefer the D syntax as well.
*type!T Point struct {*
*x, y int*
*data !T*
*}*
*type Transformer interface {*
*Transform(!R) !S*
*}*
*func Stringify(s []!T) string {*
*}*
*type Vector []!T*
Easy and readable :)
On Monday, 20 July 2020 at 16:22:08 UTC+2
This seems to be very similar to a suggestion I made a couple of years ago:
https://gist.github.com/peter-mckenzie/5cc6530da1d966e743f4a39c150a6ac2
The spaces are in different places but that could be regarded as a matter
of style.
I always liked it, but maybe a little too quirky for most :-)
Not having a GitHub account is a non-issue.
- It is an issue now because the enhancement process is on GitHub issues
which does not include voting or weighting of votes.
It is a trivial matter to use gohugo.io with a package that integrates
GitHub issues as the repository for comments.
---
Hi,
ISTM that all those filtering-suggestions are quietly redefining the
problem. The Go team didn't say "we don't have time to read all proposals",
they said "we don't have time to argue every proposal in-depth". So if your
concern was "that is bad, because I want all proposals to get enough
On Mon, Jul 20, 2020 at 1:00 PM Markus Heukelom
wrote:
>
> Would it be an idea to allow people only to label something as proposal if
> they have at least some support / voucher for the idea? Say N>10 general
> upvotes or 1 upvote from a golang committer?
The problem is that not everyone has a
I really like Markus Heukelon's suggestion.
There is no need for the Go team to evaluate each proposal, that is a silly
waste of a valuable and limited resource.
Having a list of all proposals with voting means that the most popular
items float to the top and the worst float to the bottom and
Basically I've got some different tcp/ip stack implementations based on
DPDK and want to be able to replace existing types and methods of the stock
net package, which would allow to add DPDK support for existing apps
without any amends as a complete plug'n'play.
Same goes for JSON serialization
I would like to insist on considering the D syntax using the ! for generics
instantiation.
The first time I saw it, I was puzzled and found it unpleasant. But this is
just because it is unfamiliar and not intuitive.
Once I got used to it, I found it much simple than the C++ templates. In
fact
Coming back at this after more thought & exploration. The fundamental
problem I see is it introduces complexity, but no value.
Say
`type I interface {...}`
`type S(type T I) struct {T}`
Then the generic S (before instantiating with a particular T) may implement
any interface, e.g. in any
On Sunday, July 19, 2020 at 1:44:49 PM UTC-4, Steven Blenkinsop wrote:
>
> On Sun, Jul 19, 2020 at 11:43 AM, Jake Montgomery > wrote:
>
>> This seems to work: https://go2goplay.golang.org/p/8veymwXYCoZ
>>
>>
>> I'm confused. It panics when I run it now.
>>
>
> Since the outcome is probably
Updating those 2 lines would be the least of our problems if this value
ever changes.
On Fri, Jul 17, 2020 at 12:33 PM Jan Mercl <0xj...@gmail.com> wrote:
> On Fri, Jul 17, 2020 at 11:23 AM Heisenberg wrote:
> >
> > Constant definition in token.go:
> >
> > literalType = 0 << 30
> >
> > The only
Hi, I try to build hugo with fresh gollvm but the linker complains that:
# github.com/gohugoio/hugo
/usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match
split-stack sequence at section 1 offset 0
/usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match
Would it be an idea to allow people only to label something as proposal if
they have at least some support / voucher for the idea? Say N>10 general
upvotes or 1 upvote from a golang committer?
By allowing the "proposal" label, you sort of give people the idea that
their idea will be
For archive's sake, let me tell my solution.
I carefully added a preprocessing command into my build steps. Before
compiling, the following command is run:
sed -E -i 's:(Version\s*=\s*)".*":\1"'$(DOCKER_CLI_VERSION)'":' \
$(@D)/cli/version/version.go \
&& sed -E -i
>From a quick glance that might be wrong:
It looks like the walk function visits an abstract syntax tree (AST) and
performs checks for the statics part of the compiler. E.g., it finds unused
variables and functions, type-illegal statements and so on. The term "walk"
is used as in that it "walks
Requiring type-information for parsing will brings difficulty for
implementing these tools, but not impossible. To solve ambiguity, the only
requiring type-information is wether a symbol is a type name or an
identifier. A parser package can help this.Since other languages like Java,
C#,
On Mon, Jul 20, 2020 at 8:33 AM Xie Zhenye wrote:
> Gramma of a programming language is not able to be changed after released.
> So language design is elegant or not is more important than difficulty of
> implementing.
>
> Adding type information in parse time and use angle brackets only affects
Gramma of a programming language is not able to be changed after released.
So language design is elegant or not is more important than difficulty of
implementing.
Adding type information in parse time and use angle brackets only affects
compiler and 3rd part tools or IDEs in a short time.
thx. I'll check it.
On Saturday, July 18, 2020 at 12:03:52 AM UTC+8, Jake Montgomery wrote:
>
> On Thursday, July 16, 2020 at 10:32:32 PM UTC-4, hao dong wrote:
>>
>> 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
55 matches
Mail list logo
