I'm new to golang, and am hitting some seemingly strange territory that I
couldn't find much prior discussion about -- here's one example of the
phenomenon in question:
https://stackoverflow.com/questions/22153269/how-to-reflect-fields-of-containing-struct-from-a-method-of-the-embedded-struct/49
type
> assertion: in.(InType) (non-interface type *Inner on left)
>
> Here you can't use type assertion on `in` because it only works on interfaces
> (https://www.programming-books.io/essential/go/a-25362-type-assertion) and
> `in` isn't an interface. The compiler tells
On Mar 5, 2018, at 10:32 PM, Ian Lance Taylor wrote:
>
> Go doesn't have anything like inheritance in C++. What you are
> calling the "true underlying type" simply doesn't exist in Go. Go has
> embedded fields, and methods of embedded fields are promoted to become
> methods of the outer type in
I just made a few mods to the stringer tool to generate a function that
converts a string back to the const int type, e.g., for this const int type:
// SignalType provides standard signals -- can extend by starting at iota +
last signal here
type SignalType int64
const (
NilSignal
I implemented a type registry solution for this situation:
https://github.com/rcoreilly/goki/tree/master/ki/kit
you just add a one-liner after every struct you want to register, and it builds
the map for you — makes it fully modular, etc. Cheers,
- Randy
> On Mar 28, 2018, at 12:59 PM, Alex Ef
https://github.com/goki/goki — key demo in:
https://github.com/goki/goki/tree/master/gi/examples/widgets
This is the first release of a new Go framework built around the Tree as a core
data structure (Ki = Tree in Japanese), which includes as its first application
a fully-native Go GUI (built o
e PaintServer is closer to what I’d expect with an
> interface, and Labeler seems idiomatic.
>
> I like the screenshot.
>
> // check for interface implementation
> var _ Node2D = &Line{}
>
> I don’t like this pattern.
>
> Given the amount of code and projec
the “alpha” status of
this project and can easily be cleaned up. The README files in particular were
mostly just “notes to self” and really need to be rewritten. :)
> On May 4, 2018, at 3:35 PM, Randall O'Reilly wrote:
>
>>
>> The Ki interface is a code smell to me.
of problems, just like intermittent hangups. Even with
> something as well supported as SDL, I was getting an intermittent bug until I
> realized I absolutely need to call runtime.LockOSThread(). Something like
> that might be going on here, and again we can follow up offline if you wish,
&
On May 5, 2018, at 8:38 AM, matthewju...@gmail.com wrote:
> In a generic container I would expect to see items typed as interface{} and
> the behavior defined on a slice of interface{} or struct with private slice
> of interface{} field.
>
> From the godoc it looks like type Node implements type
wrt the compilation slowdown issue, the cgo code that I adapted from shiny in
the “as native as you can reasonably get in Go" GoGi GUI
(https://github.com/goki/gi) is certainly the slowest part of the build, but
even so, it is a *tiny* fraction of the compilation time of Qt (which can take
over
The implicit nature of contracts seems like a major sticking point. If you are
writing something like 1 << t to express “unsigned integer” then it seems like
it would obviously be more explicit to directly state “unsigned integer”.
contracts look really elegant, powerful, and well-defined from
Given all the challenges associated with generics, it might be productive to
follow up on this alternative approach of identifying a (small set) of new
primitive containers and functions that would otherwise have been written using
generics, that are of sufficiently general applicability as to m
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 why
this wouldn’t be useful to provide in standard packages?
Idea:
We are excited to finally announce the beta version of the GoGi cross-platform
graphical interface toolkit (a preliminary announcement was made back in May),
and the Gide IDE application written in it:
* https://github.com/goki/gi
* https://github.com/goki/gide
Given the recent discussion about
s in
> /Users/dharani/gopath/src/github.com/goki/gi
>
> (this is my general question anyway when the packages give this output. In
> such cases, are we supposed to use "git clone"?)
>
> Also, it seems to have many dependencies. Any details on them?
>
> Regards
Tom,
One very common and seemingly effective structure is the tree / scenegraph,
which is used in Qt and, as the DOM, in HTML, and lots of other places. GoGi
https://github.com/goki/gi uses this, so you can see native Go examples there.
In Qt and GoGi in particular, you leverage the Layout to
I’m trying to figure out the best convention for the basic function of
accessing elements in a container (specifically in the context of GUI elements
in the case of GoGi / GoKi https://github.com/goki/gi, and also in our new
biological neural network simulator in Go: https://github.com/emer/emer
019, at 9:26 PM, Randall O'Reilly wrote:
>
> I’m trying to figure out the best convention for the basic function of
> accessing elements in a container (specifically in the context of GUI
> elements in the case of GoGi / GoKi https://github.com/goki/gi, and also in
> ou
I’m probably missing something very basic, but I have a go/types.Type and I
want to find which package it was defined in. I can get the path of the
Package using TypeString but somehow I can’t seem to figure out how to get the
*Package itself! I can’t find a “lookup package by path” and Lookup
nevermind - I think I figured it out — just need to drill down Underlying until
you find types.Named and get the Obj().Pkg() from that. Only Named types have
a package home..
- Randy
> On Feb 16, 2019, at 12:51 AM, Randall O'Reilly wrote:
>
> I’m probably missing something ver
On the topic of “selling” the advantages of Go vs. other languages such as
Python and C++, has anyone used the metaphor of other products that strongly
emphasize clean, elegant design, such as Apple hardware (I wouldn’t make this
case about their software, given the nature of objective-C and Swi
I’m building a shared library of Go code that is loaded as a module by python,
and called from there. Somehow, I need to ensure that one particular function
is called on the main thread (Mac OS cocoa gui event loop code requires this).
I tried adding an init() function in the library and calle
stuff comment about whether it might have
something that automatically avoids the main thread when running as a library??
Thanks,
- Randy
> On Feb 25, 2019, at 11:49 AM, Kurtis Rader wrote:
>
> On Mon, Feb 25, 2019 at 1:56 AM Randall O'Reilly wrote:
> I’m building a shared libr
8:13 PM, Kurtis Rader wrote:
>
> On Mon, Feb 25, 2019 at 6:03 PM Randall O'Reilly wrote:
> Kurtis — thanks for the suggestion — I had assumed that python always just
> runs in the main thread, and when I added this code to my python script, it
> shows that it is inde
for reference, here is a very basic Qt-style signal / slot style subscribe /
publish model in Go, just using a map of receivers and their receiver callback
functions:
https://github.com/goki/ki/blob/master/ki/signal.go
- Randy
> On Mar 10, 2019, at 11:07 PM, Kasun Vithanage wrote:
>
> Yes, wh
This seems similar to previous proposals based on introducing kind-based type
categories for contracts. Putting the kind right there in the arg instead of a
separate contract seems like an improvement, keeping it more local to where it
is used. Why not just take this one step further and just
any violations of existing static
type safety. Curious to hear what others think! Cheers,
- Randy
> On May 31, 2019, at 4:28 PM, Randall O'Reilly wrote:
>
> This seems similar to previous proposals based on introducing kind-based type
> categories for contracts. Putting the
It’s great to see that so many people share my considerable enthusiasm for this
proposal! Seriously, nobody is willing to take a look and provide any feedback?
- Randy
> On Jun 3, 2019, at 2:53 AM, Randall O'Reilly wrote:
>
> I wrote up a coherent proposal based on the core of
On Jun 5, 2019, at 12:03 PM, Ian Lance Taylor wrote:
>
> On Wed, Jun 5, 2019 at 10:47 AM Randall O'Reilly wrote:
>>
>> It’s great to see that so many people share my considerable enthusiasm for
>> this proposal! Seriously, nobody is willing to take a look
That is a good point of clarification about the specific limitation of this
proposal: it specifically reifies the existing Go type system and does NOT
enable the generic-ification of arbitrary novel types. If you can build a
specialized type out of generic versions of existing Go types, then yo
On Jun 5, 2019, at 8:36 PM, Burak Serdar wrote:
>
> On Wed, Jun 5, 2019 at 11:47 AM Randall O'Reilly wrote:
>>
>> It’s great to see that so many people share my considerable enthusiasm for
>> this proposal! Seriously, nobody is willing to take a look and provid
In case it helps anyone else with this problem, there is an issue with the
standard layout, and any project where all the code is in various
subdirectories but there is no .go code at the top level: godoc.org won’t find
it!
https://github.com/golang-standards/project-layout/issues/19
https://gi
I also like this proposal, and have a related proposal with a somewhat
different syntax that is even simpler and is essentially identical to existing
Go code, just with “Generic Native Types” (GNT). Here’s a couple of
side-by-side comparisons:
///
// Min
Michal’s:
func Min(x,
Here’s some partial SVG renderers in Go:
* https://github.com/srwiley/oksvg
* https://github.com/goki/gi (uses srwiley’s rasterx rasteriser, has separate
SVG parsing / painting impl).
Cheers,
- Randy
> On Jan 31, 2020, at 6:54 PM, Michael Jones wrote:
>
> Just to be clear: PNG is a descriptio
Apologies for being really slow on the uptake here, but I’m just now realizing
that the master plan is to actually get rid of the GOPATH mode! Is there any
chance of possibly retaining it? Is it too much work to maintain both modules
and GOPATH modes? I have absolutely no qualms with the modu
Thanks for the tip — that led me to these other relevant discussions:
*
https://groups.google.com/forum/#!searchin/golang-nuts/gohack$20replace$20modules
*
https://www.reddit.com/r/golang/comments/cvapcu/go_mod_how_to_get_it_to_find_packagesmodules_in/
* And now I understand the point of this to
The GoGi GUI system https://github.com/goki/gi has now been released at version
1.0 -- the 3D framework is now in place and interoperates with the 2D framework
(including embedding 2D in 3D scenes), and everything is working reliably so we
can keep the API stable from this point onward. There a
I think map[string]struct{} takes no storage for the value and is the most
efficient way to do this.
- Randy
> On Apr 27, 2020, at 7:20 PM, Shishir Verma wrote:
>
> I think the idiomatic way to implement a set in golang is to use a map with
> bool values. Here is an example from effective go
https://github.com/anthonynsimon/bild has parallel image ops of all sorts and
is widely used & well supported.
- Randy
> On May 10, 2020, at 9:52 PM, robert engels wrote:
>
> I don’t know and I doubt anyone else does off the top of their head, so why
> don’t you write a test and see?
>
> Ima
I noticed a kind of circularity in the arguments around this issue. The simple
"inline the if block" issue was created and rejected earlier:
https://github.com/golang/go/issues/27135 -- in part because the central issue
of error handling logic was supposed to be resolved by some other upcoming
You could save a fair amount of typing and eyestrain by not replicating the
type params for types, in their methods:
type Vector(type T) []T
func (v *Vector) Push(x v.T) { *v = append(*v, x) }
type Map(type K, V) struct {
root*node(K, V)
compare func(K, K) int
> ms.T = t
> }
>
> In this example. ms.T means two very different things depending on where they
> are used.
>
> On Wed, Jun 17, 2020 at 3:45 AM Randall O'Reilly wrote:
> You could save a fair amount of typing and eyestrain by not replicating the
> type param
Here's a proposal for a syntactic modification to the draft proposal that
removes explicit type parameters from functions, and just uses generic types
directly (e.g., the new interface types):
https://github.com/golang/go/issues/39669
This would go a long way toward simplifying the syntax and a
Would it make sense to mark the methods requiring pointer receiver types on the
interface definition, instead of on the function type parameters? It seems more
logical given that this should be a general property of the semantics of the
interface method in question, and not something each functi
Tagging onto this point: while Go deviates from other languages in a number of
important ways, syntax at the level of things like parens, brackets, etc is not
one of these key differences. It is almost entirely consistent with the "de
facto" C-style choices in this respect (to the extent that p
a, b = (w < x), (y > (z))
This seems like a very rare case, and a small price to pay for following the
established convention..
- Randy
> On Jul 14, 2020, at 11:53 PM, Randall O'Reilly wrote:
>
> Tagging onto this point: while Go deviates from other languages in a number
Regarding the parsing: as I suggested in my email, but perhaps was unclear, in
case of two conflicting *purely syntactic* interpretations (without using any
type information), you could just choose the more high-frequency interpretation
(i.e., type parameters) and force the programmer to use add
FWIW, the "generic types" alternative syntax proposal:
https://github.com/golang/go/issues/39669 includes an explicit distinction
between generic interfaces and regular interfaces, and an earlier iteration of
this idea included a new keyword, e.g., `prototype`, that would signal this
distinctio
I just wrote a wrapper around open mpi in Go: https://github.com/emer/empi
Also, here's a set of random go bindings I found:
• https://github.com/yoo/go-mpi
• https://github.com/marcusthierfelder/mpi
• https://github.com/JohannWeging/go-mpi
Even a from scratch implementati
Jon's points probably sink this proposal. Go is a very different language, and
making it less self-consistent to solve some fraction of syntactic readability
is almost certainly not going to get over the very high threshold for changing
the language.
If you're going to switch over to Go, you'l
I think we all agree that Python has some major issues.. :)
But the point of Jon's argument which struck me as very compelling is that Go
would really need full operator overloading to serve as a serious competitor
given the standards to which people have become accustomed. I didn't see in
yo
Those are good points and FWIW I would be excited to use the proposed indexing
functions and agree that they are a big part of the issue, independent of the
operator overloading. There has been a lot of discussion about supporting
multidimensional indexing etc so this has been a major issue ove
There's also this: https://github.com/golang/go/issues/37755 -- just retain
GOPATH mode
Although, now that I've been using modules more, and my various interdependent
packages are more stable, I am more sympathetic to something like #26640
instead of retaining GOPATH. Anyway, having SOME kind
Is the slowness here related to https://github.com/golang/go/issues/29427 ?
I'm not sure the earlier fix for that actually fixed the issues I was having
(and the issue remains open) -- I need to do more research for my situation,
but just in case this might be another reason to revisit the slow
It would be great if there were a universal standard location in the user's
$HOME directory that is already on the PATH, because that always trips up new
users when starting to use a CLI.
But that does not appear to be the case on the mac -- this seems to be what a
default user gets, at least o
https://github.com/go-python/gopy can manage the python bindings for you
automatically. The bigger issue for ML is GPU. I wrote a gosl (Go shader
language) package that converts Go to hlsl which can be compiled in vulkan for
compute shaders -- works well for my needs: https://github.com/emer/g
57 matches
Mail list logo
