On Fri, Aug 24, 2018 at 8:31 AM, Steven Hartland wrote:
>
> Hi all I've just been banging my head why test our linux test env isn't
> caching tests and found that its down to -exec.
>
> The docs (https://golang.org/cmd/go/#hdr-Build_and_test_caching) refer to
> cacheable "test" flags but doesn't m
On Fri, Aug 24, 2018 at 12:28 AM, wrote:
>
>> go test -v -race -count=5 .
> === RUN TestSyncAPI
> ==
> WARNING: DATA RACE
> Read at 0x00c4200ca080 by goroutine 8:
> _/Users/yanqing11/test/go/sync1.(*Pool).Put()
> /Users/yanqing11/test/go/sync1/pool.go:108 +0xe8
> _/Use
On Sat, Aug 25, 2018 at 7:58 AM, Peter Kleiweg wrote:
> Op zaterdag 25 augustus 2018 16:40:55 UTC+2 schreef Jakob Borg:
>>
>> On 25 Aug 2018, at 15:21, Peter Kleiweg wrote:
>>
>>
>> disabling the cache won't be an option in Go 1.12. What to do then?
>>
>>
>> You don’t say what your issues with th
ion::traverse (this=0x11f6a88, traverse=0xffbff6d4)
>> at /export/home/amandeep/gccgo-src/gcc/go/gofrontend/gogo.cc:5135
>> #18 0x001ec6f0 in Bindings::traverse (this=0x10b4f60, traverse=0xffbff6d4,
>> is_global=) at
>> /export/home/amandeep/gccgo-src/gcc/go/gofrontend/gogo.h:
On Sat, Aug 25, 2018 at 5:16 PM, Peter Kleiweg wrote:
> Op zaterdag 25 augustus 2018 18:54:32 UTC+2 schreef Ian Lance Taylor:
>>
>> On Sat, Aug 25, 2018 at 7:58 AM, Peter Kleiweg wrote:
>> > Op zaterdag 25 augustus 2018 16:40:55 UTC+2 schreef Jakob Borg:
>> >
On Sun, Aug 26, 2018 at 6:59 AM, 'Serguei Bezverkhi (sbezverk)' via
golang-nuts wrote:
>
> Ioctl implementation in unix package seems a bit limited, how do you pass
> for example a required struct if “func IoctlSetInt(fd int, req uint, value
> int)” allows only to accept int?? If this package had
On Tue, Aug 28, 2018 at 10:26 AM, Rohit Jain wrote:
>
> ```err := testService.test.UpdateWithQuery(
> ctx,
> bson.M{
> -"id": campaignID,
> +"id": campaignID,
> "x_yyy.testing":
On Wed, Aug 29, 2018 at 11:41 AM, rajesh nataraja wrote:
>
> whereas go compiler recognizes it. Why are the tools not matching? This is
> with go 1.9.7
>
>
> gofmt throws the following error
>
> expected type, found '='
Make sure you are using a gofmt built with Go 1.9, not some older
version th
On Wed, Aug 29, 2018 at 12:23 PM, wrote:
>
> Although I spent some time searching, I have not found an issue quite like
> the one I’m experiencing so here goes. We are working to create a set of
> Golang wrapper functions/methods that call into an existing database product
> (YottaDB) that has a
On Wed, Aug 29, 2018 at 6:16 PM, wrote:
> Sorry, should have mentioned I came across this in go1.11 but I have not
> validated that it is not an issue in earlier releases.
I can't find anything similar in the issue tracker. Please do file a
bug report at https://golang.org/issue. Thanks.
Ian
he 1.11 version of gofmt.
Ian
> On Wed, Aug 29, 2018 at 5:24 AM Ian Lance Taylor wrote:
>>
>> On Tue, Aug 28, 2018 at 10:26 AM, Rohit Jain
>> wrote:
>> >
>> > ```err := testService.test.UpdateWithQuery(
>> >
On Thu, Aug 30, 2018 at 4:50 PM, Eric Raymond wrote:
>
> On Thursday, August 30, 2018 at 7:25:10 PM UTC-4, Nigel Tao wrote:
>>
>> On Fri, Aug 31, 2018 at 4:18 AM Burak Serdar wrote:
>> > If b is an interface to a *Blob, what's stored in the slice is {Type:
>> > *Blob, Value: pointer to the object
On Sun, Sep 2, 2018 at 1:08 AM, 'Charlton Trezevant' via golang-nuts
wrote:
>
> Link: [Getting specific about generics, by Emily
> Maier](https://emilymaier.net/words/getting-specific-about-generics/)
>
> The interface-based alternative to contracts seems like such a natural fit-
> It’s simple, st
On Thu, Sep 6, 2018 at 12:49 AM, Christophe Meessen
wrote:
>
> I know about the problems it raised with C++, but Go is different. Go2 draft
> restricts generic parameters to types.
> The only case where there might eventually be an ambiguity is with
> specialized functions in expressions.
>
> I wo
On Thu, Sep 6, 2018 at 5:28 AM, wrote:
>
> Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe Meessen:
>>
>> I understand your example, but it wouldn't be a problem anymore with a
>> special character like a $ sign. D use the !.
>
>
> Scala uses [ and ] instead of < and > to avoid
On Thu, Sep 6, 2018 at 7:00 AM, Jonathan Amsterdam
wrote:
> Consider
>
> type Int int
> var y int = Int(3)
>
> The spec says
>
> A value x is assignable to a variable of type T ("x is assignable to T") if
> one of the following conditions applies:
>
> x's type V and T have identical underlying typ
On Thu, Sep 6, 2018 at 8:20 AM, wrote:
>
> As I wasn't happy with some aspects of it, I've rewritten my feedback on the
> Go 2 Generics draft and deleted the original gist. Here's the link to the
> new gist for anybody who's interested:
> https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace
On Thu, Sep 6, 2018 at 10:29 AM, jimmy frasche wrote:
>
> Contracts are a brilliant solution to the problem on an intellectual
> level. I really am impressed by how deftly they tackle the stated
> problem. But I am concerned about their usability on the practical
> level. The idea is simple but it
On Thu, Sep 6, 2018 at 11:40 AM, Matt Sherman wrote:
>
> Perhaps a compromise position would be that these type
> groups/classes/contracts are not language builtins but in the stdlib?
> contracts.Comparable, etc.
Yes, definitely.
> And, for a first implementation, only the stdlib can define con
On Thu, Sep 6, 2018 at 12:05 PM, alanfo wrote:
>
> So, yes, there'd be a lot to learn but there'd also be a lot to learn to
> write 'full-blooded' contracts effectively some aspects of which are quite
> subtle.
I would like to more clearly understand which aspects seem subtle when
reading the cod
On Thu, Sep 6, 2018 at 12:24 PM, mustafa katipoğlu
<98mustafakatipo...@gmail.com> wrote:
>
> If I use len() function inside of a foor loop , does it calculates the
> output each time? or if the output will be the same(like arrays) will it
> calculates the length of the function again ?
>
> var lett
>
> for _, xt1 := range LookupCodes {
> ...
> c1.lookup = &xt1
Don't do that. See https://golang.org/doc/faq#closures_and_goroutines
. You aren't using a closure, but the issue is the same.
Ian
--
You received this message because you are subscribed to the Google Groups
"
On Wed, Sep 5, 2018 at 8:26 PM, Steve Phillips wrote:
> Interesting idea, but has the Go team expressed interest in creating such a
> tool?
Yes, I think it's become clear that we should have a tool that, given
a contract body, produces a minimal contract body that expresses the
same contract. I
On Tue, Sep 4, 2018 at 7:41 AM, thwd wrote:
>
> From the draft proposal I gather two open questions:
> - How free or restricted should contract bodies be?
I believe it's useful to have contract bodies simply be arbitrary
function bodies, as the current design draft suggests. This is
because I b
On Tue, Sep 4, 2018 at 9:17 AM, roger peppe wrote:
>
> As I understand it, if a contract doesn't allow it, you won't be able to do
> it.
> That is, the contract is scanned for "operations" (however they might be
> defined), and then it will be a compiler error if a function uses an operation
> no
On Tue, Sep 4, 2018 at 9:49 AM, roger peppe wrote:
>
> For example, the Stringer contract in the
> design doc purports to check that there's a method named String, which
> it does not - it could be a function-valued field instead.
>
> So if you've written something like this:
>
> func FastStri
On Thu, Sep 6, 2018 at 1:21 PM, Caleb Spare wrote:
> On Thu, Sep 6, 2018 at 9:54 AM Ian Lance Taylor wrote:
>>
>> Personally I think an important feature of the current design draft is
>> that it adds relatively few new concepts to the language. While
>> concepts are
On Thu, Sep 6, 2018 at 1:38 PM, xingtao zhao wrote:
>
> But we can still using [type T] instead.
That is a very good point. Thanks. As far as I can see we could
plausibly switch to square brackets if we prefer them.
Ian
> On Thursday, September 6, 2018 at 6:45:07 AM UTC-7, Ian Lan
On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche wrote:
>
> Wouldn't there be an issue with fp := AFunc[int] ?
I don't think so. AFunc[int] would be parsed as an index operation,
and after name lookup it would resolve into either an array lookup or
a function instantiation, depending on the meaning
On Thu, Sep 6, 2018 at 2:30 PM, Scott Cotton wrote:
>
> I am interested in potentially putting some time into reviewing and possibly
> writing up the results of reviewing the generics proposal.
>
> As I'm quite stretched for time to do this, it would help me plan if the go
> team could say anythin
On Thu, Sep 6, 2018 at 2:32 PM, wrote:
>
> Here's a few points which I noticed when reading through the draft design
> which I thought people might have trouble getting their heads around:
>
> 1. The use of untyped numeric constants where you might need to specify the
> exact value needed to get
On Thu, Sep 6, 2018 at 2:35 PM, jimmy frasche wrote:
>
>> It's not necessary to support fields but I think it really is
>> necessary to support operators. I claim that, other than type safe
>> data structures, the number one generic function that people want to
>> write is Min (or Max). I don't
On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
wrote:
>
> On Thu, Sep 6, 2018 at 9:45 PM Ian Lance Taylor wrote:
>>
>> On Thu, Sep 6, 2018 at 10:29 AM, jimmy frasche
>> wrote:
>>
>> This is clearly a key issue. I happen to think that contracts are
>> f
On Fri, Sep 7, 2018 at 12:18 AM, Seven Dang
wrote:
> Group, help me! thank so much... very so much
>
I'm sorry, I don't understand your question. I don't understand what it
has to do with Go at all. You seem to be asking about systemd and
systemctl. These are not parts of the Go language
On Fri, Sep 7, 2018 at 1:41 AM, Sergey Kamardin wrote:
>> Note that calculating the length of a slice is a fast operation; it's
>> a single memory load.
>
> So, actually it just loads a slice header's field?
Yes.
Ian
--
You received this message because you are subscribed to the Google Groups
On Fri, Sep 7, 2018 at 3:43 AM, Shiming Liu wrote:
>
> Hi you guys, do you know how to convert big.Float to big.Int, I have
> searched with google and searched in this group, but don't found valuable
> info.
>
> In stackoverflow I got an answer
> https://stackoverflow.com/questions/47545898/golang
On Thu, Sep 6, 2018 at 4:29 PM, Axel Wagner
wrote:
>
> The other day I had a lengthy conversation with Rog Peppe, David Crawshaw
> and Nate Finch on twitter and I'd argue that neither of us would really
> count as a Go-novice and we *still* weren't always clear what types certain
> contracts allow
On Fri, Sep 7, 2018 at 10:51 AM, jimmy frasche wrote:
>
> To describe a sufficiently-tight contract you need to be able to come
> up with an elaborate conjunction of properties that allow everything
> needed while disallowing everything that would cause your code to
> break. To read such a contrac
On Fri, Sep 7, 2018 at 11:39 AM, Axel Wagner
wrote:
> On Fri, Sep 7, 2018 at 3:10 PM Ian Lance Taylor wrote:
>>
>> This does surprise me. I'm certainly too close to the problem, but to
>> me it always seems quite clear which type arguments a contract allows
>> an
On Fri, Sep 7, 2018 at 5:28 PM, Rob Pike wrote:
>
> contract unsigned(v T) {
> // Require T to be an integer type.
> v % 1
> // This is satisfied by any unsigned integer type, but not by a
> signed integer type.
> v = 1<<(unsafe.Sizeof(v) * 8 - 1)
> }
>
> That requires an import, n
On Fri, Sep 7, 2018 at 5:29 PM, Rob Pike wrote:
>
> Would this work?
>
> contract unsigned(u T) {
> 1 << u
> }
>
> It's another infelicitous horror, but I believe it exploits the only place
> in the language where an unsigned integer is required.
Yes, that would also work (pace issue #19113).
On Fri, Sep 7, 2018 at 9:19 PM, Lucio wrote:
>
> PS: Maybe I should add a thought to clarify what I'm imagining. Am I
> mistaken in my belief that user-defined methods and functions are much less
> likely to appear within contracts than operators on intrinsic types? And
> that the "generic" nature
On Sat, Sep 8, 2018 at 5:54 AM, Wojciech S. Czarnecki wrote:
> On Sat, 8 Sep 2018 03:59:45 -0700
> Ian Lance Taylor wrote:
>
>> Why is it useful to say "this polymorphic function may
>> only be instantiated with unsigned integer types?"
>
> E.g. because an
On Sat, Sep 8, 2018 at 6:29 AM, alanfo wrote:
>
> As it's clear now that Ian wants to stick with 'full-blooded' contracts if
> it can be made to work, I've been trying to think of ways to make them
> easier to work with and to solve some of the issues they currently have.
>
> Reading through the d
On Sat, Sep 8, 2018 at 1:16 PM, Larry Clapp wrote:
>
> The draft proposal says
>
> "The body of a contract may not refer to any name defined in the current
> package"
>
> but then later has this example
>
> package move
>
> contract counter(x T) {
> var _ int = x.Count
> }
>
> contract counters(T
On Sat, Sep 8, 2018 at 3:47 PM, Ignazio Di Napoli wrote:
> I'd really like to read a reply to Lucio's argument about operator
> overloading.
>
> Once we define that:
> 1. a 2. a==b is the same as a.Equals(b);
> 3. the other comparaison operators are defined using these two (e.g.: a>b is
> !a.Les
On Sat, Sep 8, 2018 at 2:23 PM, jimmy frasche wrote:
>
> I get that it avoids introducing those properties directly into the
> language but it also locks the language into those properties. You can
> never change https://github.com/golang/go/issues/19113 after
> introducing contracts because there
On Sat, Sep 8, 2018 at 6:10 PM, Rob Pike wrote:
> "A contract is a compile-time description of which types are permitted
> for a polymorphic function or type."
>
> No, it's not. It's a collection of statement-like operations that must be
> legally compilable, under restricted circumstances, by the
On Sat, Sep 8, 2018 at 7:53 PM, Jonathan Amsterdam
wrote:
>> When is it important to not just express what operations are
>> required for a type, but also to try to rule out some types?
>
>
> I think the short answer is: numeric code. That's when one thinks about
> which types make sense for an a
On Sat, Sep 8, 2018 at 4:31 PM, Shawn Webb wrote:
>
> I've read through a previous discussion in 2012 about golang's use of
> deterministic memory allocations here:
> https://groups.google.com/forum/#!msg/golang-nuts/Jd9tlNc6jUE/qp2oyfEEfjQJ
>
> Back then, -buildmode=pie didn't exist back then, so
On Sat, Sep 8, 2018 at 6:58 PM, Rick
wrote:
[ replacing "operator" by "method" since that seems to be what was intended ]
> Is support for [method] overloading implied by support for generics?
No.
> Is it > possible to have one with the other?
Yes, they are entirely independent.
> To be hone
On Sun, Sep 9, 2018 at 6:51 AM, Ignazio Di Napoli wrote:
>
> Thank you, I see your point. This is less powerful than contracts, but Go
> proved me that less is more, as long as it is enough. My point is: do we
> really need a so powerful version of generics or maybe operators and
> interfaces a
On Sun, Sep 9, 2018 at 12:18 PM, 'Axel Wagner' via golang-nuts
wrote:
>
> I disagree with the premise that we need operators for generics - when I
> think of "generics", I usually think of "type-safe, constrained, parametric
> polymorphism". Without operators, generic code would still fulfill that
On Tue, Sep 11, 2018 at 10:04 AM, roger peppe wrote:
>> func (x Foo(int)) Bar() {}
>
> As I understand it, this would be technically allowed, but would not
> mean what you think.
>
> This is defining a method Bar on the Foo type, and "int" is declaring
> a name for the type parameter defined in t
On Tue, Sep 11, 2018 at 1:39 PM, roger peppe wrote:
> On 11 September 2018 at 18:04, roger peppe wrote:
>> If it were not explicitly prohibited by the draft proposal, we could
>> also imagine this, a definition of a method foo on the type A that's
>> parameterised with type T; the method itself h
On Tue, Sep 11, 2018 at 2:56 AM, 'Axel Wagner' via golang-nuts
wrote:
>
> * My post does not allow to constrain on struct fields. This is a
> fundamental reduction in power over contracts (type-parameters can't be
> identifiers, but only type names so can't solve this like
> assignability/converti
On Tue, Sep 11, 2018 at 6:22 PM, Patrick Smith wrote:
>
> This is a hypothetical question. Suppose generics were implemented as in the
> draft proposal, but without contracts. Instead, the rule is that if an
> instantiation of a generic function with a specific type argument doesn't
> compile, the
On Tue, Sep 11, 2018 at 11:48 PM, Leigh McCulloch wrote:
>
> Does anyone here know how Go interacts with memory limits inside containers?
> (e.g. Kubernetes, Docker)
>
> Does the Go runtime have similar problems as the Java runtime, in that it
> doesn't know what the container limit is, and only
On Wed, Sep 12, 2018 at 6:47 AM, Wojciech S. Czarnecki wrote:
>
> https://github.com/ohir/gonerics
>
> Thanks to all for your insights and stated concerns.
>
> Changes:
>
> 1. "Out" (return) type constraints are out. Might return as optional.
> 2. enumerated "T is assignable to" constraint added
>
On Wed, Sep 12, 2018 at 6:58 AM, Leigh McCulloch wrote:
>
> Thanks for the link and answering. I'll look more into understanding the
> issue. I'm mostly trying to reconcile that there are so many articles about
> not using Java inside containers because it does nothing to stay in the
> memory limi
On Wed, Sep 12, 2018 at 7:07 AM, robert engels wrote:
> With the Azul VM (and I believe the G1 collector in Java), the VM is
> definitely aware of memory pressure as it approaches the maximum limit - then
> it will increase the concurrent GC activity trying to avoid a potential huge
> pause if
On Wed, Sep 12, 2018 at 7:32 AM, Wojciech S. Czarnecki wrote:
> On Wed, 12 Sep 2018 06:33:59 -0700
> Ian Lance Taylor wrote:
>
>> I don't think there is any way to solve this problem as stated without
>> taking a step toward metaprogramming: making decisions at compil
On Tue, Sep 11, 2018 at 5:38 PM, Patrick Smith wrote:
>
> First, please consider requiring the 'type' keyword in definitions of
> methods on generic types:
>
> func (x Foo(type T)) method() {}
>
> This adds a small amount of verbiage, but makes the intent crystal clear. It
> also allows for easy e
On Wed, Sep 12, 2018 at 7:49 AM, Wojciech S. Czarnecki wrote:
> On Wed, 12 Sep 2018 06:33:59 -0700
> Ian Lance Taylor wrote:
>
> Addenum:
>
>> You need to have a way to say "compile this code under certain
>> conditions based on the type argument, otherwise com
On Wed, Sep 12, 2018 at 10:54 AM, jimmy frasche wrote:
>
> Given a platform that supports the fused multiply add (FMA)
> instruction and the code:
>
> contract MA(t T) {
> t * t + t
> }
>
> func ma(type T MA)(a, b, c T) T {
> return a*b + c
> }
>
> Does the compiled-for-any-type ve
On Mon, Sep 10, 2018 at 5:32 AM, komuW wrote:
>
> On Thursday, 6 September 2018 23:22:34 UTC+3, Ian Lance Taylor wrote:
>>
>> On Wed, Sep 5, 2018 at 8:26 PM, Steve Phillips wrote:
>> > Interesting idea, but has the Go team expressed interest in creating
>> >
On Thu, Sep 13, 2018 at 6:31 PM, Patrick Smith wrote:
>
> (Apologies if this has already been brought up; I don't remember seeing it.)
>
> While writing a bit of sample generics code, I ran into a nasty little
> ambiguity:
>
> type Foo(type T) interface {}
> type Bar(type T) interface {
>
> Foo(T)
On Thu, Sep 13, 2018 at 7:16 PM, wrote:
>
> Trying to compile the following on Solaris 10 gives the error: call of
> non-function C.testc
>
> package main
>
> /*
> #include
>
> void testc() {
> printf("Hello cgo");
> }
> */
> import "C"
>
> func main() {
> C.testc()
> }
>
> The output of
On Fri, Sep 14, 2018 at 3:32 AM, alanfo wrote:
>
> I was then brought back to reality by this post by Robert Engels in the
> 'Generics - Why contracts?' thread:
>
> "As I’ve said elsewhere, a SIMPLE to use and understand solution that covers
> 90% is better than a complex one to cover 100% IMO, an
On Fri, Sep 14, 2018 at 10:47 AM, wrote:
>
> The problem is that many people think the current draft design is too
> complex and I haven't seen a plausible suggestion from anyone (myself
> included) which would be appreciably simpler but as comprehensive, or nearly
> so.
>
> This is why I'd concl
On Fri, Sep 14, 2018 at 1:40 AM, wrote:
>
> oh yes, I am using gccgo. I configured gccgo from source. Below is the go
> version output:
> go version go1.10.3 gccgo (GCC) 8.2.1 20180814 solaris/sparc
What version of GCC are you using? What is the output of `gcc --version`?
Ian
--
You received
On Fri, Sep 14, 2018 at 2:16 PM, wrote:
> It would be the same. Please see below.
>
> -bash-3.2$ gcc --version
> gcc (GCC) 8.2.1 20180814
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCH
On Mon, Sep 17, 2018 at 10:39 AM, Scott Cotton wrote:
>
> Wanted to ask about the Go runtime use of threads. Specifically, suppose
> I've got an app in mind that would run OS-priveleged and use specially
> scheduled threads, like SCHED_RR in linux for example.
>
> One could do this with chrt or c
On Mon, Sep 17, 2018 at 1:41 AM, changkun wrote:
>
> Thus, my first question is: Considering the scheduling strategy of goroutines
> in Go universe, will the Go universe IO performance between a user socket and
> socketpair[0] get suffering by such a blocking CGO call?
No.
> The second questi
On Mon, Sep 17, 2018 at 12:17 PM, changkun wrote:
>
> Those overhead you mentioned come from goroutine scheduler for entering a
> system call.
> Apparently, there is no such mechanism in Go to submit an IO "transaction"
> if there are two
> or more syscall close to each other, syscall can be held
On Mon, Sep 17, 2018 at 2:43 PM, Michael Jones wrote:
>
> Firstly, my compliments to Russ, Robbert, and Ian, for patience,
> thoughtfulness, and insight. Whatever the best answer is, no doubt your
> intellectual process is an excellent way to find it.
>
> My comment is a meta-comment, a question/p
: 0
>
> Contents of the .debug_aranges section:
>
> Length: 28
> Version: 2
> Offset into .debug_info: 0x0
> Pointer Size: 4
> Segment Size: 0
>
> AddressLength
> 0000 0014
>
On Tue, Sep 18, 2018 at 10:06 AM, Tamás Gulácsi wrote:
>
> If I read golang.org/src/time/zoneinfo_read.go right, the Go project ships
> with the TZInfo file (zip).
>
> zoneinfo.go has
> //go:generate env ZONEINFO=$GOROOT/lib/time/zoneinfo.zip go run genzabbrs.go
> -output zoneinfo_abbrs_windows.go
On Tue, Sep 18, 2018 at 12:42 PM, Eric Raymond wrote:
>
> If interruption of a function with defers is interrupted by an uncaught
> signal (say, ^C from the keyboard) do its defer hooks fire? What about defer
> hooks in functions up the call stack? If the interrupt happens during a
> defer hook's
On Tue, Sep 18, 2018 at 2:04 PM, Eric Raymond wrote:
> On Tuesday, September 18, 2018 at 4:10:52 PM UTC-4, Ian Lance Taylor wrote:
>>
>> Signals in Go never interrupt functions.
>
>
> Thank you, that was an admirably clear reply.
>
> I think this needs to be docum
file a big for this?
Sure. Thanks. But since it works on Solaris 11 it doesn't seem high priority.
Ian
> On Tuesday, September 18, 2018 at 7:45:06 AM UTC-7, Ian Lance Taylor wrote:
>>
>> Thanks for sending this. Unfortunately, I have no idea what is going
>> wrong. E
On Sun, Sep 23, 2018 at 8:24 PM, Jesse McNelis wrote:
> On Mon, Sep 24, 2018 at 5:33 AM, Tamás Király wrote:
>> Hi,
>>
>> can anyone explain why the following does not work?
>> i want to have the return value's address not the method itself.
>>
>> package main
>>
>> func main() {
>> //first
>> ad
On Mon, Sep 24, 2018 at 4:32 PM, Randall O'Reilly wrote:
>
> This seems like such an obvious idea, but I was unable to find prior
> discussion about it — it is probably at least implicit in various generics
> alternative proposals etc, but anyway, seems like it might be worth at least
> saying
On Mon, Sep 24, 2018 at 7:21 PM, wrote:
>
>I configured everything from scratch again and it seems that this is
> reproducible. I also noticed that while running:
> CGO_LDFLAGS='"-g" "-O2"'
> /usr/gnu/libexec/gcc/sparc-sun-solaris2.10/8.2.1/cgo -debug-gcc -objdir
> $WORK/b001/ -importpath com
On Tue, Sep 25, 2018 at 6:15 PM, wrote:
>
> I am learning sync.map recently, but the implemention of tryStore func makes
> me confused,
> why not use the code below instead
>
>
>
> func (e *entry) tryStore(i *interface{}) bool {
>for {
>p = atomic.LoadPointer(&e.p)
>if p == ex
On Thu, Sep 27, 2018 at 11:13 AM, changkun wrote:
> Works, thanks! Hope the information cloud added to golang.org/doc/gdb
Sent https://golang.org/cl/138182 .
Ian
> On Thursday, September 27, 2018 at 8:02:20 PM UTC+2, David Chase wrote:
>>
>> You did nothing wrong, in 1.11 we started compressing
On Thu, Sep 27, 2018 at 2:57 PM, Amandeep Gautam
wrote:
> Hi,
>I am trying to compile a 64bit executable using gccgo on Solaris 11/10.
> Following is what I have tried:
>
> CGO_LDFLAGS='-m64' go build hello_world.go
> GOARCH=sparc64 CGO_LDFLAGS='-m64' go build hello_world.go
>
> Below is the o
On Thu, Sep 27, 2018 at 4:07 AM, Francis wrote:
> Does anyone have a feeling for when the 1.11.1 release will be ready
>
> I can see from https://github.com/golang/go/milestone/80 that it's about
> half done with no release date. But does anyone have a clearer feeling for
> when it might be read
aris_sparc/github.com/golang/libglog.a
> /opt/go_pkgs/pkg/gccgo_solaris_sparc/github.com/golang/libglog.a:
> current ar archive, 32-bit symbol table
For a package that uses cgo, you'll need to use -gccgoflags=-m64 and
also set both CGO_CFLAGS and CGO_LDFLAGS to -m64.
Ian
> On
On Thu, Sep 27, 2018 at 11:14 PM, Peter Mogensen wrote:
>
> Are you saying this statement from the Go spec is subject to change:
> "Pointer values are comparable. Two pointer values are equal if they
> point to the same variable or if both have value nil. Pointers to
> distinct zero-size variables
On Fri, Sep 28, 2018 at 12:43 AM, wrote:
> Seems like even that does not seem to work. Please see:
>
> amandeep@s113ldom1:/opt/go_pkgs/src/github.com/golang/glog$ sudo
> GOPATH=/opt/go_pkgs CGO_CFLAGS='-m64' CGO_LDFLAGS='-m64' go install -x
> -gccgoflags=-m64
> WORK=/tmp/go-build357879094
> mkdi
On Fri, Sep 28, 2018 at 2:08 AM, Ankit Gupta
wrote:
>
> I am working with confluent-kafka-go library
> (https://github.com/confluentinc/confluent-kafka-go) which builds fine on
> the mac machine (mac OS 10.13.6) along with the code files I wrote. In order
> to deploy it on Linux server (Ubuntu 64
On Fri, Sep 28, 2018 at 6:58 AM, Ankit Gupta
wrote:
> Thanks Ian for responding. Can you point me as to how to get the cross
> compiler. I am farely new to Mac.
Sorry, I don't use Macs at all.
Ian
> On Fri, 28 Sep 2018, 19:23 Ian Lance Taylor, wrote:
>>
>> On Fr
On Fri, Sep 28, 2018 at 7:08 AM, changkun wrote:
>
> 1. Is my suspicion reasonable and correct?
I wouldn't be my first guess. You say that pango memory is
per-thread. That suggests that you need to always call pango on a
consistent thread. That will not happen by default. You likely need
to a
On Fri, Sep 28, 2018 at 7:45 AM, changkun wrote:
>
> On Friday, September 28, 2018 at 4:12:31 PM UTC+2, Ian Lance Taylor wrote:
>>
>> On Fri, Sep 28, 2018 at 7:08 AM, changkun wrote:
>> >
>> > 1. Is my suspicion reasonable and correct?
>>
>> I
On Fri, Sep 28, 2018 at 10:14 AM, wrote:
> nopes...doesn't work either. I tried both variations...with and without
> GOARCH=sparc64 flag. Following is the output with sparc64 flag:
>
> amandeep@s113ldom1:/opt/go_pkgs/src/github.com/golang/glog$ sudo
> GOPATH=/opt/go_pkgs CC='gcc -m64' CGO_CFLAGS
utable for _buildid.o but
>> even after that running ar rcD $WORK/b001/_pkg_.a $WORK/b001/_go_.o
>> $WORK/b001/_buildid.o produces a 32-bit archive. Also, running buildid gives
>> some error about 32 byte hash. Please see:
>>
>> amandeep@s113ldom1:~/workspace$
>>
On Fri, Sep 28, 2018 at 5:33 PM, wrote:
> Hi Ian,
>Setting GCCGO env variable helped. I basically compiled, helloworld.go
> with the following options and it compiled a 64 bit exectable:
>
> CC=/home/amandeep/workspace/mygcc.sh
> GCCGO=/home/amandeep/workspace/mygccgo.sh CGO_CFLAGS='-m64'
> C
On Mon, Oct 1, 2018 at 7:56 AM, Pierre Durand wrote:
>
> My code:
> package main
>
> func main() {
> a := 1
> _ = func() {
> a := 2
> _ = a
> }
> _ = func() (a int) {
> a = 2
> return a
> }
> _ = a
> }
>
> "go vet -shadow" reports a problem with the first function/closure, but
> nothing for the se
On Sun, Sep 30, 2018 at 6:41 PM, Dan Kortschak
wrote:
>
> I have been translating some C socket networking code (not my main area
> of expertise) and there is something that I don't see a way to do with
> net.TCPConn.
>
> The original code sets a revc timeout using
>
> ```
> setsockopt(fd, SOL_SOC
201 - 300 of 3587 matches
Mail list logo
