Thanks Ian. I have submitted issue 28069 along with the simplest example I
could figure out. I found that the behaviour is triggered when a long
double is nested in an inner field of a struct; moving the long double to
the outer field of the struct lets the go build complete successfully.
Regar
On Fri, Oct 5, 2018 at 11:57 PM, Scott Cotton wrote:
>
> On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor wrote:
>>
>> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton wrote:
>
>
>>
>> In fact
>> we definitely do want to add other preemption checks that occur at
>> points other than function entry (iss
On Fri, Oct 5, 2018 at 11:40 PM, Scott Cotton wrote:
>
> On Sat, 6 Oct 2018 at 02:10, Ian Lance Taylor wrote:
>>
>> On Fri, Oct 5, 2018 at 3:21 PM, Scott Cotton wrote:
>> >
>> > On Fri, 5 Oct 2018 at 23:46, Scott Cotton wrote:
>> >>
>> >> Thanks much for the info.
>> >>
>> >> Do you have any mo
The net package's ReadFrom method is named ReadFrom because it is
implemented by the recvfrom system call. Perhaps it was a poor choice
of name in Go, but that is where it comes from.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsub
On Sun, Oct 7, 2018 at 7:25 PM, wrote:
>
> The header file smi.h from libsmi (https://github.com/mikeowens/libsmi)
> declares a typedef using "long double"
>
> typedef long double SmiFloat128;
>
> In Go versions prior to 1.11, programs using smi.h compiled without error.
> In Go 1.11,
The header file smi.h from libsmi (https://github.com/mikeowens/libsmi)
declares a typedef using "long double"
typedef long double SmiFloat128;
In Go versions prior to 1.11, programs using smi.h compiled without error.
In Go 1.11, cgo calls out "long double" as "unexpected". Here is
Not Per Brinch Hansen. He did monitors, which are just serialization. Tony
Hoare did CSP.
-rob
On Mon, Oct 8, 2018 at 12:46 PM Michael Jones
wrote:
> The greatness of go parallelism is that it is almost invisible. This is
> the legacy of CSP, Per Brinch Hansen’s Communicating Sequential Proces
The greatness of go parallelism is that it is almost invisible. This is the
legacy of CSP, Per Brinch Hansen’s Communicating Sequential Processes. It’s
not hard to understand.
On Sun, Oct 7, 2018 at 4:29 PM rob wrote:
> On 10/07/2018 11:40 AM, Marvin Renich wrote:
> >
> > I hope these comments h
On 10/07/2018 11:40 AM, Marvin Renich wrote:
I hope these comments help.
...Marvin
I'm a newbie at Go. These comments help me a lot. I appreciate all the
time these comments took.
But it will take a little longer for me to grok Michael Jones' parallel
code.
Thanks.
--
You received thi
> It looks like it is a stream of JSON objects?
>
> If so, I suspect this is expected?
Per the issue you linked, thepudds, absolutely correct.
This comment gives details on how to handle such a stream of JSON objects:
https://github.com/golang/go/issues/27655#issuecomment-420993215
Paul
--
Y
Note that this would still accept numeric literals:
w.At(4)
If you want to avoid this, you can wrap the index type in a struct:
type Index struct {
I int
}
Quoting Ian Denhardt (2018-10-07 13:20:48)
> Yeah, there's no way to do this as such. One thing you could possibly do
> instead is
Yeah, there's no way to do this as such. One thing you could possibly do
instead is define a wrapper around the type and use methods:
type MyWrapper struct {
theSlice []Elem
}
type Index int
func(w MyWrapper) At(i Index) Elem {
return w.theSlice[int(i)]
}
func(w MyWrapper) SetAt(i Index
...oh, and in case you wonder about count and size variation, home
directory trees are noisy...
celeste:since mtj$ since -v -d 1m ~
/Users/mtj/Library/Application Support/Google/Chrome
/Users/mtj/Library/Application Support/Google/Chrome/Default/Application
Cache/Cache/data_1
/Users/mtj/Library/A
Thanks for gathering this info, and the work you all put into Go, but I
just went to answer it and I wonder how many people are going to answer
this one wrong:
What are the preferred languages at your company? (top 4)
(Please list up to 4, 1 = most preferred)
scale is 1 to 4, in most surveys, t
impressively patient response!
choosing a serial vs concurrent approach matters too in terms of
performance.
celeste:tour4 mtj$ tour4 ~
Go walker [/Users/mtj]
walked 293426 files containing 512174988291 bytes in 4.895 seconds
walked 293426 files containing 512174988537 bytes in 4.918 seconds
walk
Goimports will scrub unneeded imports.
On Sun, Oct 7, 2018 at 4:50 AM Eric Raymond wrote:
> I am pleased to announce the release of pytogo 1.2.
>
> https://gitlab.com/esr/pytogo
>
> New features in this release:
>
> * PEP484 type hints are now converted into Go type signatures.
> * Without PEP4
[I've set reply-to to include you (per your reply-to) but to exclude me; I
prefer to read my list mail on the list rather than in my personal inbox.]
* rob solomon [181006 15:17]:
> I've been trying to do something simple like this, but I'm not interested in
> following symlinks. Here I just am
I'm gonna say no.
On Saturday, October 6, 2018 at 5:07:33 PM UTC-4, Steve Roth wrote:
>
> Is there a way to declare an array (or slice) that is indexed by a type
> derived from int, rather than indexed by int? My intent is to have the
> compiler complain if I index the array/slice with a generi
I am pleased to announce the release of pytogo 1.2.
https://gitlab.com/esr/pytogo
New features in this release:
* PEP484 type hints are now converted into Go type signatures.
* Without PEP484 hints, return types of functions are now sometimes deduced.
* Docstrings are moved to the godoc-prefer
On Sunday, October 7, 2018 at 7:13:59 AM UTC-4, Jakob Borg wrote:
>
> All the Read variants read into a buffer. The special thing about ReadFrom
> is that it tells you who the message was from.
>
io.ReaderFrom.ReaderFrom is conflicted with this.
>
> On 6 Oct 2018, at 18:06, T L > wrote:
>
>
All the Read variants read into a buffer. The special thing about ReadFrom is
that it tells you who the message was from.
On 6 Oct 2018, at 18:06, T L mailto:tapir@gmail.com>>
wrote:
.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To uns
On Friday, 5 October 2018 12:56:50 UTC+2, Thomas S wrote:
>
>
> My service crash because "panic - out of memory", and I'm not sure how to
> monitore it.
> I just want to know, when it crashes, where are the main memory
> allocations, to understand the problem.
>
> It is pretty sudden, I can hardl
22 matches
Mail list logo
