Hi,
True or false, it's better to avoid loading atomic variables unnecessarily?
--
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...@googlegr
tion between threads.*
>
> On Thursday, November 7, 2024 at 3:13:38 PM UTC-8 Ian Lance Taylor wrote:
>
>> On Thu, Nov 7, 2024 at 2:54 PM Roger wrote:
>> >
>> > True or false, it's better to avoid loading atomic variables
>> unnecessarily?
>>
>&g
Two significant issues that need to be thought about:
- When slices can be compared, they can be used as map keys. What happens
if the contents of a slice are changed after it has been added to a map?
- It is possible to have self-referential slices [1]. How would comparison
work in such a case?
On 30 January 2018 at 23:19, wrote:
>> - When slices can be compared, they can be used as map keys. What happens
>> if the contents of a slice are changed after it has been added to a map?
>
>
> I’m not too familiar with Go map internals, but my thought is the key hash
> would depend on the backi
On 5 February 2018 at 08:36, Peter Waller wrote:
> On 31 January 2018 at 16:23, roger peppe wrote:
>>
>> BTW you can already do something like this:
>> https://play.golang.org/p/q4bz8-AckN3
>
>
> Neat trick!
>
>>
>> You can even do it without reflec
On 5 February 2018 at 11:38, Peter Waller wrote:
> On 5 February 2018 at 11:04, roger peppe wrote:
>>
>> > I'll bite, does it involve struct { len int; content [maxCount]int }, or
>> > did
>> > you have something else in mind?
>>
>> S
}
}
return r
}
https://play.golang.org/p/7VG1MWDI-l-
or, somewhat more generally:
https://play.golang.org/p/_vfh2nT5cZL
You can even use this technique to compare arbitrary DAGs.
Not that it would be a good idea :)
On 5 February 2018 at 17:49, roger peppe wrote:
> On 5 February 2018 at 11
On 6 February 2018 at 14:55, wrote:
> Slice pointer keys are another option but that concept is tricky too.
What do you mean by a "slice pointer key" ?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop rec
As someone totally unfamiliar with the GoF patterns, hre's my take.
I looked at the wikipedia articles and tried to work out what
problem I thought the pattern was trying to address and then
wrote some Go code to do that. I'm generally in agreement
with those who say that these patterns are there l
On 19 February 2018 at 17:36, Michael Jones wrote:
> Matthew Juran wrote: "...but if you use maps, slices, append, make, you are
> already using generics."
>
> This seems deeply insightful to me. Perhaps a better question than the
> self-defeatingly open question of "how should Go embrace generics
On 23 February 2018 at 12:31, Nic Pottier wrote:
> Thanks for the great write up Dave, you've inspired me to "try harder" to
> use it on a few of my projects after running into similar issues.
>
> As you noted, my remaining big question mark is how existing libraries that
> are above v1 transition
On 23 February 2018 at 15:00, Nic Pottier wrote:
> On Fri, Feb 23, 2018 at 7:59 AM, roger peppe wrote:
>> As Russ pointed out to me, you can work around that by using a
>> 0.0.0-2101234543-4f34f456eeefdcba version in your go.mod require
>> section. If you've got th
I'm happy to announce the release of goyaml 1.1.
It includes the following improvements:
- Add Encoder and Decoder types
This allows encoding and decode multiple YAML documents in a stream.
- Alternative timestamp support (e.g. 2015-01-01). Credit to anthonybishopric.
- If a value implements an
Of course I mean 2.1. Version two. TWO is the version.
On 23 February 2018 at 19:17, roger peppe wrote:
> I'm happy to announce the release of goyaml 1.1.
>
> It includes the following improvements:
>
> - Add Encoder and Decoder types
> This allows encoding and decode mul
> I once counted there were about 8000 uses of ,error as
> return types for functions in $GOROOT/src which could benefit
> from sum types.
I'm not entirely convinced that sum types are a net win as a
substitute for (T, error) return values.
Where currently we have:
f, err := os.Open(filena
On 24 February 2018 at 22:02, Bakul Shah wrote:
> r := os.Open(filename)
> if isError(r) { return r.(error) }
> f := r.(*os.File) // or better: var f *os.File; f = r
I don't think the "or better" alternative would be possible. The of r
is still `*os.File|error`, not *os.File, and this not assigna
jake6502 is correct - the result is a slice that needs to be indexed
(you might use jsonvals[2].Int()).
I'd suggest that instead of using that gjson package, you might
consider using the
standard library's encoding/json package, which enables you to define
a struct type
that mimics the expected JS
jake6502 is correct - the result is a slice that needs to be indexed
(you might use jsonvals[2].Int()).
I'd suggest that instead of using that gjson package, you might
consider using the
standard library's encoding/json package, which enables you to define
a struct type
that mimics the expected JS
On 12 March 2018 at 17:53, Maverick Woo wrote:
> Hi,
>
> I am exploring a pattern to achieve a desirable aspect of vtable in Go. For
> now please put the vtable consideration aside, and see an example I have put
> together for this post:
>
> https://play.golang.org/p/ctkwGuYGqiy
>
> In the examp
PS kudos for including a go.mod file in that demo code!
On 12 March 2018 at 19:15, roger peppe wrote:
> On 12 March 2018 at 17:53, Maverick Woo wrote:
>> Hi,
>>
>> I am exploring a pattern to achieve a desirable aspect of vtable in Go. For
>> now please put the vtab
Hi Nigel,
It all seems to work as expected for me using this code:
https://play.golang.org/p/QGBT6kqxHBS
I'm using Postgres 9.5.12.
Can you distill your problem into some self-contained code that
demonstrates the issue?
cheers,
rog.
On 7 October 2013 at 10:46, Nigel Vickers wrote:
>
> T
On 14 March 2018 at 01:22, Maverick Woo wrote:
> Having said the above, in your example, you have a (morally) `shape.Print`
> function that takes an interface value of the intended "descendants" and you
> expose their fields using interface methods. This is all very idiomatic---no
> doubt. However
If it helps, you can set deadlines on *os.File now, as of Go 1.10:
https://play.golang.org/p/h3Pg9Ql0CMB
I don't see a way to cancel without deciding the deadline in advance though.
On 15 March 2018 at 08:40, Matt Mueller wrote:
> Hey folks,
>
> I'm trying to figure out how to cancel reading
You might be interested to look at
https://godoc.org/github.com/juju/utils/parallel#Run, a slightly
simpler approach to the same issue, and just about as general, I
think.
On 15 March 2018 at 08:19, Sotirios Mantziaris wrote:
> since the lack of generics i am trying to avoid interface{} as much a
On 16 March 2018 at 02:11, 'Anmol Sethi' via golang-nuts
wrote:
> https://play.golang.org/p/82Um1jSntBo
>
> Please run with the race detector to see the race.
>
> This race condition arises because private variables are read via reflection
> by the fmt package. Is there any elegant way to avoid su
Could you please create a self-contained example where the
YAML is inside the code itself (use a back-quoted string containing the YAML)?
Also, could you please confirm the git commit hashes of the
YAML you're using on each platform?
If you're using a different version on each platform, please co
On 16 March 2018 at 14:45, Sathish VJ wrote:
> All the examples I've seen use some kind of ticker to run various cases of a
> select statement. But how does one run a long running task that is still
> cancelable?
>
>
> In the example below the quit part is never reached.
>
> https://play.golang.o
I was more interested in the specific version of yaml you were using.
What does this command print for you on each platform?
git --git-dir $(go list -f '{{.Dir}}' gopkg.in/yaml.v2)/.git log -1
(I'm assuming you use the bash shell).
thanks.
rog.
On 16 March 2018 at 15:24, Yuichi Sawada wr
Why not something more like this? https://play.golang.org/p/3t4UtoFkoIt
A lot of this comes down to what that long running task is doing.
If it's hard at work doing computational work, the polling approach
might be appropriate.
If it's mostly waiting on external events then passing the context
ins
On 2 April 2018 at 15:42, Paul Jolly wrote:
> Speaking as someone who has written a few (albeit simple) code generators
> that parse Go code, dot imports are a nightmare from my perspective because
> it makes it impossible to work out from just imports alone whether an
> identifier belongs to the
On 9 April 2018 at 03:41, Paul Lalonde wrote:
> A ^ normally matches either the start of string or the start of a new line
> (with the m flag).
> I'd like to match only starts of lines, but not starts of strings, ideally
> without changing the regexp.
>
> My source data is in a ReadSeeker, and if
A simple-as-possible answer might be something like this
https://play.golang.org/p/TO8xoH9gwTF
For a good answer, you'd probably want to go into performance
trade-offs, runtime constraints and other possible implementations.
On 8 April 2018 at 06:05, Xen wrote:
> Hi everyone, I have this mock in
On 9 April 2018 at 09:31, Jan Mercl <0xj...@gmail.com> wrote:
> On Mon, Apr 9, 2018 at 6:47 AM Paul Lalonde
> wrote:
>
>> Any advice?
>
> If regexp cannot solve your task don't use regexp. Write the tiny state
> machine by yourself, it should be not too much code.
Surely that depends whether Paul
That's an interesting case. It does seem to me that if you have an
interface-typed value in a no-condition switch statement then it's quite
likely to be an accident. However, AFAICS this issue applies only to the
empty interface type, so ISTM that it is unlikely to be common.
It's too late for Go
You original example has a problem that others have pointed out because
it's possible for one goroutine to step on the part of the backing array used
by others. In principle though your technique looks OK to me as long
as you prevent that happening, for example by using the three-value slice
operat
On 22 April 2018 at 23:20, Louki Sumirniy
wrote:
> I essentially am trying to find an effective method in Go, preferably not
> too wordy, that lets me create an abstract data type, a struct, and a set of
> functions that bind to a different data type, and that I can write,
> preferably not in too
On 23 April 2018 at 19:58, Louki Sumirniy
wrote:
> The type function bindings are not the problem, the problem is the fact that
> despite in every other way the signatures match, they will not be found by
> the compiler to bind to the type, and thus the need to wrap the invocations.
>
> I maybe sh
On 24 April 2018 at 09:58, Louki Sumirniy
wrote:
>
>
> On Tuesday, 24 April 2018 11:15:34 UTC+3, rog wrote:
>>
>> On 23 April 2018 at 19:58, Louki Sumirniy
>> wrote:
>
>
>>
>> > I set many of those identifiers to export because I wanted to keep
>> > separate
>> > derived libraries that replaced t
On 24 April 2018 at 12:59, Louki Sumirniy
wrote:
> I'll just be brief this time and hit the points quickly:
>
> Yes, technically it is a Complete Binary Tree but you won't find a Complete
> Implementation of one anywhere, I have looked, and there isn't. The concept
> has been rejected without bein
On 25 April 2018 at 08:05, Louki Sumirniy
wrote:
> https://stackoverflow.com/questions/6531543/efficient-implementation-of-binary-heaps
>
> Pretty much what I'm working on here is this, except with left to right sort
> instead of vertical. I think this guy's work will help me iron out the
> perfor
On 25 April 2018 at 10:08, Louki Sumirniy
wrote:
> I think that it's not necessarily non-idiomatic to use closures instead of
> interfaces in Go, it's more that Go has had interfaces longer than it's had
> closures, and so more code has been written this way.
Sorry, that's just not true. Go had b
On 25 April 2018 at 10:24, Louki Sumirniy
wrote:
> As you look deeper into the link discussing the B-heap you can see that
> actually I am pretty much exactly following the same general structure in my
> algorithm. The structure will align neatly with page boundaries and that
> means less page
On 26 April 2018 at 16:29, Jon Bodner wrote:
> Hello,
>
> We were having a discussion at work about passing around references to
> sync.WaitGroup. I said it was a bad idea, because if a goroutine launched a
> goroutine of its own and called sync.WaitGroup.Add() after a goroutine
> called sync.Wait
On 26 April 2018 at 06:13, wrote:
> Hey everyone,
> I've encountered a design issue -
> I have an the following interface -
>
> type Runner interface {
> Run(x X,y Y)
> }
>
> I want to add to it an Init(...) method which will initialize the internal
> fields of the Runner before performing `Run
On 2 May 2018 at 22:06, Michael Jones wrote:
> Ok, weird proposal: Make the per-iteration update part of a for loop change
> from "assignment to assignment or boolean expression" to allow:
>
> while COND do {...}:
>
> for i:=0; x[i]<4; {...}
>
>
> do {...} while COND:
>
> for i:= 0; ; x[i]<4 { ...
FWIW, the thing I miss sometimes is the equivalent of C's:
while((x = next()) != nil) {
something()
}
In Go you need to do either:
for x = next(); x != nil; x = next() {
something()
}
which duplicates the per-iteration expression, or:
for {
On 3 May 2018 at 14:46, wrote:
> Can anybody point me to a single discussion on golang-nuts that led to a
> significant syntax change? These threads are akin to bike shedding thus a
> waste of time.
I can think of a couple, although I haven't got the time to delve for links.
The map key deletion
> do { ... } while is the only construct I some times miss, but then
> again, it occurs fairly rarely in my code, so for now I'm rather happy to
> just rewrite it in another style.
When I programmed in C, I found it pretty rare to use do...while.
These days I think of it more as a special case
The error seems correct to me. From the spec:
"The scope of a type identifier declared inside a function begins at
the identifier in the TypeSpec and ends at the end of the innermost
containing block."
So the type declaration in main is a recursive type - the T it refers
to is not the previously
I believe this optimisation has been implemented now.
Have you tried using Go 1.11 beta (or Go tip) ?
See https://tip.golang.org/doc/go1.11#performance-compiler
On 12 August 2018 at 11:07, Peter Edge wrote:
> With slices, you can do
>
> slice = slice[:0]
>
> to remove the values from the slice,
Please try with Go 1.11 rc1.
(You can explicitly enable modules with GO111MODULE=on, or just try
building outside $GOPATH).
On 11 August 2018 at 19:08, Joseph Lorenzini wrote:
>
> All:
>
> Using vgo, I haven't been able to build a go package with this library.
> Using go 1.10, I can successfully
In my experience, this is rarely a real pain, and where it is, a
simple function can help out.
func either(condition bool, a, b string) string {
if condition {
return a
}
return b
}
fmt.Printf("color is %s", either(temperature>100, "red", "blue"))
Yes, it's conventional to use reflect.Type as a map key. In fact, you
should do that because not all types have different names, even if
they're in the same package.
For example: https://play.golang.org/p/Xqc8hkKPu4_v
On 18 August 2018 at 10:40, Christophe Meessen
wrote:
> I need to index data b
FWIW I've published some ideas about how contracts and interface types
could be partially unified, and contracts significantly simplified,
which I think is quite pertinent to the above discussion.
Doc here:
https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69
On 1 September 2018 a
On Sun, 2 Sep 2018, 5:09 pm Bakul Shah, wrote:
> People may find this excellent paper “Datatype-Generic Programming” by
> Jeremy Gibbons useful in this discussion. It’s 72 pages long.
> https://www.cs.ox.ac.uk/jeremy.gibbons/publications/dgp.pdf
>
> I want generics but I still don’t know if I lik
On 4 September 2018 at 15:41, thwd wrote:
> From the draft proposal I gather two open questions:
> - How free or restricted should contract bodies be?
> - How many implicit constraints can be inferred from usage?
>
> If too much syntax is allowed in contract bodies and no implicit constraints
>
as a single operation, and I think that disallowing it
lets values focus more on behaviour and less on appearance, as
interfaces do.
>
> On Tue, 4 Sep 2018, 17:17 roger peppe, wrote:
>>
>> On 4 September 2018 at 15:41, thwd wrote:
>> > From the draft proposal I gather two ope
ters example in the design doc is trivially implementable
with interfaces, so I haven't yet seen decent motivation for this.
cheers,
rog.
>
>
> On Tue, 4 Sep 2018, 17:49 roger peppe, wrote:
>>
>> On 4 September 2018 at 17:30, Tristan Colgate wrote:
>> >
On Tue, 4 Sep 2018, 5:52 pm xingtao zhao, wrote:
My five cents:
1) the methods of the type template are defined by interface style
2) operators are retrieved implicitly from function body
3) function-calls inside are also retrieved implicitly from the function
body
For graph example, we may dec
I think the escape analysis is at fault here. The two index functions should
have the same characteristics. Both opts.isDigit and the explicit closure
capture the pointer to opts, and I don't see why the compiler shouldn't
be able to detect that the former doesn't escape just as it does the latter.
Personally, I'm happy with the choice to use round brackets.
Go started down this road a long time ago, in my view, by making type
conversions look like function calls.
When `typename(x)` is qualitatively different from `value(x)`, I think
it's quite reasonable that `x(typename)` is qualitatively
Ha, I wrote this version before I saw that response:
https://play.golang.org/p/vO2TI7OeJk_E
On 7 September 2018 at 09:00, Nigel Tao wrote:
> Building on Todd's example, you can add a little more type safety
> (having the map value type be a "func etc" instead of "reflect.Value)
> by Curry'ing th
The key sentence from the draft is this:
"If the contract body uses a type in a certain way, the actual
function is permitted to use the type in the same way."
I like the idea of this, and it feels like it *should* be intuitive,
but the problem is that "in a certain way" needs to be very well
def
In acme (and plan 9 generally), there's a nice set of mnemonic
abbreviations for unicode characters.
It's great, and I miss it in other environments. Alt-<< and Alt->>
work really well for « and » for example.
Here's the full list:
https://github.com/9fans/plan9port/blob/master/lib/keyboard
On 7 S
On 10 September 2018 at 09:46, wrote:
> I don't know whether anyone has suggested this before but why not disallow
> direct method calls on a contract's type arguments altogether and force
> people to use interfaces instead?
I suggested that here FWIW:
https://gist.github.com/rogpeppe/45f5a75785
> 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 the definition of Foo. That
name would shadow the global language
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 has a type parameter S:
>
> func
On 11 September 2018 at 22:17, jimmy frasche wrote:
> I think it would work with interfaces if the interfaces (generic or
> not) can themselves specify generic methods, like
>
> interface {
> Foo(type T)(T) T
> }
The problem with that is, as is pointed out in the draft proposal,
that if you all
On 11 September 2018 at 22:46, Ian Lance Taylor wrote:
> 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 defini
What about here, where the call stack associated with g is still live?
func g() error {
Top:
f := func(err error) { returnfrom Top, nil }
c := make(chan struct{})
go func() {
defer close(c)
f(
On 14 September 2018 at 17:45, Scott Pakin wrote:
> On Friday, September 14, 2018 at 12:30:46 AM UTC-6, rog wrote:
>>
>> What about here, where the call stack associated with g is still live?
>>
>> func g() error {
>> Top:
>> f := func(err error) { returnfrom Top, nil }
>
Personally I very much like the fact that name comes before type because
the name is the most important thing. The type is a secondary consideration.
Limbo (a significant Go predecessor) had the colon there too and I thought
I'd find its lack might make Go declarations hard to read but I really
do
I've also found that multipass (https://github.com/CanonicalLtd/multipass)
works well for running Ubuntu on different platforms FWIW.
On Fri, 28 Sep 2018, 9:28 pm Tamás Gulácsi, wrote:
> 2018. szeptember 28., péntek 15:59:14 UTC+2 időpontban Ankit Gupta a
> következőt írta:
>>
>> Thanks Ian for
On 8 October 2018 at 08:53, Rob Pike wrote:
> Actually the original is a paper:
> https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf
> The book came later and is substantially different although not
> contradictory. Channels were not in the paper and without channels (such as
> in Occam) the flavor
I agree that rand.Shuffle could have used an interface type that's a
subset of sort.Interface. I'm not sure why it didn't, although of
course it's easy to go from one to the other:
func main() {
x := []int{1, 2, 3, 4, 5, 6, 7, 8, 9}
xi := sort.IntSlice(x)
rand.Shuffle(x
While thinking about the draft generics proposal and the complexity of
contracts, it occured to me that if you relax some of the restrictions on
type conversion, it's possible to make data structures containing basic
types amenable to generic algorithms.
Once upon a time, the Go specification allo
On Thu, 18 Oct 2018 at 06:44, Axel Wagner
wrote:
> This is only tangentially related to your specific idea, but I've decided
> that for generics discussions this is the hill I'm dying on:
>
> On Wed, Oct 17, 2018 at 6:44 PM roger peppe wrote:
>
>> The method c
On Thu, 18 Oct 2018 at 08:40, Axel Wagner
wrote:
> On Thu, Oct 18, 2018 at 9:16 AM roger peppe wrote:
>
>> The difference is that for generics, you *always* know the exact set of
>> possible types that a type parameter can be.
>>
>
> If and only if you choose to
On Thu, 18 Oct 2018 at 13:41, Axel Wagner
wrote:
> On Thu, Oct 18, 2018 at 2:06 PM roger peppe wrote:
>
>> For generics, that analysis is trivial - there is no need to do any
>> control flow analysis to determine the set of possible generic type
>> parameters to a ty
On Fri, 19 Oct 2018 at 12:04, roger peppe wrote:
> The algorithm to do it is quite straightforward:
> https://play.golang.org/p/subnLkSSxdI
>
On reflection, that ParamType hack won't work correctly with
types.Identical. This should work better:
https://play.golang.org/p/iswgf7mr8
The dual implementation principle states, that it should be
> possible to compile any parametric function either by compile-time or by
> run-time substitution. That's exactly what I'm saying: The transformation
> in b) is *exactly* the run-time substitution extreme in the implement
On Sat, 20 Oct 2018 at 11:37, Axel Wagner
wrote:
>
> Thank, I feel I can work with this :)
>
> On Sat, Oct 20, 2018 at 10:58 AM roger peppe wrote:
>
>> That transformation might be valid for the simple case you have there,
>> where there's a single parameter of
Channels can work fine for this kind of thing.
The easiest (but probably a little less efficient) way is to write a
function that knows how to merge two channels, then use n-1 of them to
merge n channels. Whenever you don't currently have a value from a channel,
read one, then output the smallest
On Sun, 21 Oct 2018 at 13:40, Axel Wagner
wrote:
> On Sun, Oct 21, 2018 at 2:03 PM roger peppe wrote:
>
>> Yes. The draft proposal says "generic functions, rather than generic
>> types, can probably be compiled using an interface-based approach. That
>> will optim
On Sun, 21 Oct 2018 at 13:53, Axel Wagner
wrote:
> Last addition:
>
> On Sun, Oct 21, 2018 at 2:03 PM roger peppe wrote:
>
>> Ah, I *think* I see where you might be coming from now. You're thinking
>> that the compiler could do some kind of Go-to-Go transformatio
On Thu, 25 Oct 2018, 12:52 am Axel Wagner,
wrote:
> On Thu, Oct 25, 2018 at 12:39 AM roger peppe wrote:
>
>> I understand this argument. By putting some smarts into the compiler, we
>> would hope that we can see benefits not just in our generated generic code,
>> but
I'm not keen on this idea (including Ian's idea too). It makes parsing
context-sensitive because the set of syntactic tokens varies would depend
on the names declared in the package. That is, you can't parse a file in
isolation because without reading all the files in a package, you don't
know whic
On Sat, 27 Oct 2018, 5:46 pm So you're basically saying that an identifier should either be reserved or
> not and that there should be no *contextual* keywords at all, not even
> *contract*.
>
Yes, I agree with this. FWIW the generics draft proposal has at least one
suggestion for avoiding "contr
In case it's of interest, I've been playing around with an experiment about
how Go generic code might be generated. In particular I wanted to see how
it looked when code was shared between generic instances with types that
share the same memory layout (with respect to internal pointers and
alignmen
Sat, 3 Nov 2018, 11:21 am roger peppe In case it's of interest, I've been playing around with an experiment
> about how Go generic code might be generated. In particular I wanted to see
> how it looked when code was shared between generic instances with types
> that share the
Here's a version that runs in the playground.
https://play.golang.org/p/DciTAl8dAxO
On Sat, 3 Nov 2018 at 11:45, roger peppe wrote:
> Ah, I should mention it relies on a slightly modified version of the
> compiler that allow conversion of function values to and from
> unsafe.Poin
g.org/p/W_ruqI22Vhv
>> Seems a fairly straight-forward transformation to me - and again easy to
>> devirtualize.
>>
>> On Thu, Oct 25, 2018 at 8:56 AM roger peppe wrote:
>>
>>>
>>> On Thu, 25 Oct 2018, 12:52 am Axel Wagner, <
>>> axel.w
hOn Sun, 4 Nov 2018 at 12:09, Axel Wagner
wrote:
> On Sun, Nov 4, 2018 at 11:45 AM roger peppe wrote:
>
>> One thing to consider: at any point in your program, someone might call
>> something like the following function with any value in scope:
>>
>>var vals [
On Mon, 5 Nov 2018 at 02:35, Axel Wagner
wrote:
> On Sun, Nov 4, 2018 at 10:14 PM roger peppe wrote:
>
>> This code, for example: https://play.golang.org/p/eaLHBbUJT-d
>> What might your generated code look like for that?
>>
>
> A bit ad-hoc, but WAI: https:/
On Mon, 5 Nov 2018 at 10:21, Axel Wagner
wrote:
> Even though all we did was save some references to values, the code has
>> radically changed (along with its runtime implications).
>>
>
> you'd choose a suitable small subset based on the type-constructors used
> in the signature.
>
For the reco
On Mon, 5 Nov 2018 at 11:38, Jamie Clarkson wrote:
> Thanks Rog, yes that seems to be very similar to what I was converging on
> - I see you're combining the dictionaries per-implied-type (as I suggested
> above) into a single dictionary per generic function with one set of funcs
> for each insta
On Mon, 5 Nov 2018 at 13:19, Jamie Clarkson wrote:
> I was more thinking about your Graph example which you posted where you're
> using an item(type Node,Edge) struct {}, not accessing the members of the
> Node and Edge types (which I agree is a dubious corner case) - looking at
> it again though
On Mon, 5 Nov 2018 at 14:36, Jamie Clarkson wrote:
>
> Yes that does help, looks like a really good solution. In your opinion
> would the resulting code be worthwhile (including all the dictionaries,
> stubs etc.) when compared to the C++ code expansion method? I can see that
> it would save fo
Note that SetField will panic unless the struct value is addressable, so
you must obtain the reflect.Value from an addressable source (for example
via a pointer as in Dan's example).
On Mon, 5 Nov 2018 at 23:12, Eric Raymond wrote:
> I need an equivalent of Python setattr() - that is, set a stru
I will add that I regularly see goimports with modules take many seconds to
run. I'm using acmego and I sometimes end up needing to switch that off
because it corrupts text seconds after a save.
On Fri, 9 Nov 2018, 3:26 pm Joseph Lorenzini Hi Ian/Russ,
>
> I should have clarified that I was doing
1 - 100 of 469 matches
Mail list logo
