On Saturday, 29 September 2018 00:45:32 UTC+2, Peter Müller wrote:
>
> [...]
> getters would not have to be defined if they simply return a property.
> This would remove boilerplate code.
>
I think I write a getter for a property once a year (at most). I can
live with that amount of "boilerplat
On Friday, September 28, 2018 at 6:44:10 PM UTC+2, Ian Lance Taylor wrote:
>
> 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:
> >> >
> >> >
You put in it a number that has the same bit pattern as a pointer to a
value. There is nothing more to it than that. It does not refer to
anything. They exist so you can do uncomfortable pointer arithmetic.
On Fri, 2018-09-28 at 15:14 +0200, Henrik Johansson wrote:
> I know what a uintptr is but w
There was a similar proposal before. Some people insist that there should
be a clear separation between state and behavior. Struct is for state and
interface is for behavior.
I too was toying with a similar idea before. My reasoning has less to do
with trying to fit into an interface, but it wa
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
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'
CGO_LDFLAGS='-m64' GOARCH=sparc64 CGO_ENABLED=1 go bu
When I do want to define my own custom getter, how might I tell the
language that my new method is a custom getter and not just a method with
no arguments and one return value? I think if Go were to have properties,
they would have to be explicitly marked as a property in some way to avoid
this.
F
On Fri, Sep 28, 2018 at 4:00 PM, wrote:
> Actually, I now understand what you meant. And even that does not work:
>
> amandeep@s113ldom1:/opt/go_pkgs/src/github.com/golang/glog$ sudo
> GOPATH=/opt/go_pkgs CC='/home/amandeep/workspace/mygcc.sh' CGO_CFLAGS='-m64'
> CGO_LDFLAGS='-m64' GOARCH=sparc64
Actually, I now understand what you meant. And even that does not work:
amandeep@s113ldom1:/opt/go_pkgs/src/github.com/golang/glog$ sudo
GOPATH=/opt/go_pkgs CC='/home/amandeep/workspace/mygcc.sh'
CGO_CFLAGS='-m64' CGO_LDFLAGS='-m64' GOARCH=sparc64 CGO_ENABLED=1 go
install -x -gccgoflags=-m64
WO
The other day I had an interesting idea: What if all exported fields have
an implicit getter. Like e.g.
type Human struct {
Age uint
Name string
}
would implicitly get the methods:
func (h Human) Name() string {
return h.Name
}
func (h Human) Age() uint {
return h.Age
}
*When defining an int
hmm...filed a bug here: https://github.com/golang/go/issues/27929
Could you explain the workaround for this again? I did not understand the
fallback option.
Apart from that, I tried to run each command manually to force m64 option
whenever possible. I was able to get a 64 bit executable for _bu
2018. szeptember 28., péntek 15:59:14 UTC+2 időpontban Ankit Gupta a
következőt írta:
>
> Thanks Ian for responding. Can you point me as to how to get the cross
> compiler. I am farely new to Mac.
>
> On Fri, 28 Sep 2018, 19:23 Ian Lance Taylor, > wrote:
>
>> On Fri, Sep 28, 2018 at 2:08 AM, Ank
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
One possibility is to use Docker on your Mac to run Linux in a container; I
use Macs a lot, but don't know how to cross-compile directly when cgo is
involved (works fine for non-cgo binaries, however). This assumes you are
okay with Docker and Linux; in both cases, I flail quite a bit but have
On Fri, Sep 28, 2018 at 10:19:50AM -0700, thepudds1...@gmail.com wrote:
> Hi Harmen,
>
> And my first sentence might not have been clear. When I said "even in your
> current situation, 'go build' is still pulling in exactly what it needs", I
> was trying to reference the actual compilation proce
Hi Harmen,
And my first sentence might not have been clear. When I said "even in your
current situation, 'go build' is still pulling in exactly what it needs", I
was trying to reference the actual compilation process.
In other words, I was just trying to make it clear that even if you have
"ex
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='-m64' CGO_LDFLAGS='-m64'
GOARCH=sparc64 CGO_ENA
> "So if consul adds a go.mod file in the root, then `mod tidy` will
suddenly
behave as I would expect (i.e. not pull in unused dependencies)? "
Hi Harmen,
Just in case this isn't already clear-- note that even in your current
situation, 'go build' is still pulling in exactly what it needs (a
On Fri, Sep 28, 2018 at 04:48:32PM +0100, Paul Jolly wrote:
> Hi Harmen
>
> I described the problem on https://github.com/golang/go/issues/27920, which
> > got
> > closed within three minutes as being "documented", and "works as
> > expected" (which I assume also means "works as intended").
> > Is
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 wouldn't be my first guess. You say that pango memor
Hi Harmen
I described the problem on https://github.com/golang/go/issues/27920, which
> got
> closed within three minutes as being "documented", and "works as
> expected" (which I assume also means "works as intended").
> Is this really the intented behaviour? It seems unexpected to me. Or
> shoul
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 wouldn't be my first guess. You say that pango memory is
> per-thread. That suggests that you need to a
On 09/28/2018 03:43 PM, Ian Lance Taylor wrote:
> That statement is not subject to change. Note that that statement
> does not say that if p1 and p2 are pointer values, and that p1 == p2,
> that uintptr(unsafe.Pointer(p1)) == uintptr(unsafe.Pointer(p2)). You
> must not take intuitions from com
Hi all,
I've been converting some work projects to use go.mod.
Today I ran into a problem that after importing the sub-package
github.com/hashicorp/consul/api `go mod tidy` pulled in everything imported
anywhere in the hashicorp/consul repo, even if it's never imported in my
project.
I described
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
Hi there,
I am encountering a cgo problem (unsure, most likely) when
migrating an old C library to Go.
A cgo call calls a component of the C library, which
internally creates an OS thread and then calls libpango
(pango_cairo_font_map_get_default() call).
The original pure C code is able to go
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 Fri, Sep 28, 2018 at 2:08 AM, Ank
Thanks Ian for responding. Can you point me as to how to get the cross
compiler. I am farely new to Mac.
On Fri, 28 Sep 2018, 19:23 Ian Lance Taylor, wrote:
> On Fri, Sep 28, 2018 at 2:08 AM, Ankit Gupta
> wrote:
> >
> > I am working with confluent-kafka-go library
> > (https://github.com/confl
Does anyone know of any golang packages for printing on desktop ?
I am producing a pdf and need to send it to the users printer on windows and
Mac OS.
Thanks
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and s
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 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 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 09/28/2018 03:29 PM, Robert Engels wrote:
> Use the GC as is unless you have a large static object set, it could work for
> that...
That was a part of the whole premise (see subject).
A huge number of same type/size objects.
/Peter
--
You received this message because you are subscribed
On 09/28/2018 03:24 PM, Robert Engels wrote:
> If you have a object reference then the object is going to tracked by the GC
> anyway, no matter where it is referenced from, so you are not saving
> anything, as that reference still must be somewhere...
... yes.
I haven't really done measuremen
Use the replace directive with relative path.
--
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.
For more options, visit ht
On 09/28/2018 03:18 PM, Tamás Gulácsi wrote:
>
> This is not that.
> My idea could maybe be restated simpler as having a huge double-linked
> list of sync.Pool objects and using wanting to supplement it by a map
> index, but avoiding storing pointers in the map.
>
>
> There's n
Hi,
Supposing I have two projects configured with go.mod files;
module gitlab.com/me/a
module gitlab.com/me/b
require gitlab.com/me/a v0.1.0
or thereabouts.
I'm developing both and would like to test my changes of a in b. What are
my options, besides pushing and tagging a, updating the versi
> This is not that.
> My idea could maybe be restated simpler as having a huge double-linked
> list of sync.Pool objects and using wanting to supplement it by a map
> index, but avoiding storing pointers in the map.
>
>
There's no such thing as a "list of sync.Pool objects" (if you refer the
I know what a uintptr is but what would you put in it if not a pointer to
another object?
Isn't this very analogous to what you said: "a weak hashmap uses weak
references to refer to the contained objects so that they will be collected
if nothing else refers to them".
Maybe I am missing something.
On 09/28/2018 03:11 PM, Robert Engels wrote:
> His statement is correct. First of all, a weak reference in java is not
> like a weak pointer in C++, at least they are not needed to break
> cycles, as the GC is immune to that issue. The difference is that a weak
> hashmap uses weak references to
That's clever but irrelevant for this discussion.
fre 28 sep. 2018 kl 14:57 skrev Jan Mercl <0xj...@gmail.com>:
> On Fri, Sep 28, 2018 at 2:53 PM Henrik Johansson
> wrote:
>
> > The data pointed to by the uintptrs ...
>
> Uintptrs are integers. They do not point to anything.
> --
>
> -j
>
--
Y
On Fri, Sep 28, 2018 at 2:53 PM Henrik Johansson
wrote:
> The data pointed to by the uintptrs ...
Uintptrs are integers. They do not point to anything.
--
-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and
On 09/28/2018 02:53 PM, Henrik Johansson wrote:
> How is storing unintptrs in a map different from say java.util.WeakHashMap?
> The data pointed to by the uintptrs can at any given time have been
> reclaimed by the GC much the same as weak references in Java.
>
> I am not saying you are using i
How is storing unintptrs in a map different from say java.util.WeakHashMap?
The data pointed to by the uintptrs can at any given time have been
reclaimed by the GC much the same as weak references in Java.
I am not saying you are using it the same way as one would normally use
weak references in o
On 09/28/2018 02:04 PM, Robert Engels wrote:
> This is in no way similar to weak references in Java. Weak references
> are safe and appropriate for many caching data structures. The code idea
> presented here is not related.
Correct.
I've used weak references in other languages (not Java) to,
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 bit), I try this -
$> CGO_ENABLED=1 GOOS=linux GOARCH=amd6
On 09/28/2018 09:39 AM, Dan Kortschak wrote:
>
> I don't understand what you are asking. First, uintptr is not a pointer
> type, it's an integer type that is the same size as a pointer and that
> can be interconverted with an unsafe.Pointer. If you hold a uintptr
> that was converted from an un
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
mkdir -p $WORK/b001/
cd $WORK
/usr/gnu/bin/gccgo -fgo-impo
On Fri, 2018-09-28 at 08:14 +0200, Peter Mogensen wrote:
>
> On 09/27/2018 11:12 PM, Dan Kortschak wrote:
> >
> > Unless you are holding a real pointer to the value, they will have
> > no
> > root to hold them and so will by GC'd.
> Also if the pointer is returned by Pool.Get() ?
> That's probabl
On 09/28/2018 09:13 AM, Henrik Johansson wrote:
> This sounds much like the trickery people have used both successfully
> but also disastrously using weak references in Java.
> Is that where you got the idea from?
No.
I think I mentioned in my first post where I got the idea from.
I haven't pro
This sounds much like the trickery people have used both successfully but
also disastrously using weak references in Java.
Is that where you got the idea from?
fre 28 sep. 2018 kl 08:36 skrev Keith Randall :
> On Thu, Sep 27, 2018 at 11:26 PM Peter Mogensen wrote:
>
>>
>>
>> On 09/28/2018 08:17
51 matches
Mail list logo
