[go-nuts] Re: [ANN] (GUI) Qt binding which supports Windows / macOS / Linux / Android / iOS / Sailfish OS / Raspberry Pi

[Rich]

This looks very well done. I've not done any real programming in it but 
looking over the github it looks like this is well on it's way.  Thank 
you!! i have a few programs I've been meaning to write that needed a 
gui, I'll be giving this a shot.



On Thursday, November 10, 2016 at 3:34:36 PM UTC-5, therecipe wrote:
>
> Hey everyone,
>
> I would like to officially announce the project I'm working on for a while 
> now.
> It's a binding for the Qt framework + some tools to help you with 
> development and deployment of your Qt applications.
>
> The most interesting feature of the Qt framework for the Go community is 
> probably that it can be used to develop native looking GUI applications for 
> various platforms without the need to make platform specific changes to 
> your code.
> Beside the GUI modules Qt also includes: a webengine (chromium), several 
> multimedia functions, access to bluetooth + nfc, access to various hardware 
> sensors, gamepad support, access to position informations and much more ...
> The Qt article on wikipedia: https://en.wikipedia.org/wiki/Qt_(software)
>
>
> There are two caveats for those who intent to use the binding:
>
> 1. You code won't be pure Go anymore, as this binding heavily relies on 
> cgo.
> 2. The binding dynamically links to Qt's libraries, which results in 
> 25-50mb (depending on the platform) uncompressed libs that have to be 
> deployed along with you binary.
> (But it's also possible to link against the static Qt libs and remove this 
> need. And there is also work being done to reduce the size of the dynamic 
> libs in the upcoming versions of Qt.)
>
>
> For the pro side, I should probably mention that:
>
> 1. The deployment to most platforms is pretty trivial (that includes cross 
> compiling). (And there will be even more supported platforms in the future)
> 2. That the binding is almost complete and already supports most Qt 
> modules (30+).
> 3. There are a lot of examples to get you started. (And porting over 
> existing C++ examples should be super simple)
>
>
> If someone is interested in testing it out, it can be found here:
> https://github.com/therecipe/qt
>
>
> Or if you just want to take a quick look and test the examples on Linux 
> and you are familiar with Docker.
> You could use one of the images as well: `docker pull therecipe/qt:base`
> And simply run `qtdeploy build desktop` in one of the `$GOPATH/src/
> github.com/therecipe/qt/internal/examples/` 
>  sub-sub folders. 
> (inside the container)
> There will be a new folder created called `deploy`, which should contain 
> everything that is needed to run the application on a regular 64-bit Linux 
> system.
>
>
> Please let me know what you think.
> Any feedback is welcome :)
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Version Control entire GOPATH

[Dave Cheney]

Have you considered gb, https://getgb.io/ ? It's purpose built for a 
project based workflow.

On Monday, 14 November 2016 09:01:15 UTC+11, Nick Stogner wrote:
>
> Thanks for the replies! I would like to actually vendor the dependencies 
> to ensure repeatable builds (so I want to avoid submodules).
>
> In a perfect world, I would like to be able to use the go toolchain (not 
> abandon go-get quite yet). I have been able to hack together some 
> client-side git hooks which accomplish this: 
> https://github.com/nstogner/gomono. After installing them in the client 
> repo, the gophers should be able to proceed along without worrying about 
> how they use go-get... Let me know what you think.
>
>
> On Saturday, November 12, 2016 at 12:00:08 PM UTC-5, Nick Stogner wrote:
>>
>> I would like to version control my entire GOPATH to store all of my go 
>> code in a monolithic repository. (see http://danluu.com/monorepo/ or 
>> https://blog.gopheracademy.com/advent-2015/go-in-a-monorepo/)
>>
>> The problem that I run into: how to manage dependencies with "go get" ?.. 
>> I would like to vendor these dependencies but git wants to treat them as 
>> nested repos and doesn't end up vendoring them on commit to the parent repo.
>>
>> I have tried: moving nested ".git" directories to ".git-moved", etc. This 
>> works for vendoring go-gotten repos but is a hassle and also messes up 
>> future calls to go get:
>>
>> $ mv   src/github.com/Sirupsen/logrus/.git   src/github.com/Sirupsen/
>> logrus/.git-moved
>> $ git add --all; git commit -m 'this commit vendors the logrus package'
>> $ go get -u github.com/Sirupsen/logrus
>> package github.com/Sirupsen/logrus: directory "/tmp/monorepo/src/
>> github.com/Sirupsen/logrus" is not using a known version control system
>>
>> I would have to mv those .git-moved directories back to .git before using 
>> go-get again and this would be a pain and not scalable to a team.
>>
>> Has anyone come up with a solution for this?
>>
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Version Control entire GOPATH

[Nick Stogner]

Thanks for the replies! I would like to actually vendor the dependencies to 
ensure repeatable builds (so I want to avoid submodules).

In a perfect world, I would like to be able to use the go toolchain (not 
abandon go-get quite yet). I have been able to hack together some 
client-side git hooks which accomplish this: 
https://github.com/nstogner/gomono. After installing them in the client 
repo, the gophers should be able to proceed along without worrying about 
how they use go-get... Let me know what you think.


On Saturday, November 12, 2016 at 12:00:08 PM UTC-5, Nick Stogner wrote:
>
> I would like to version control my entire GOPATH to store all of my go 
> code in a monolithic repository. (see http://danluu.com/monorepo/ or 
> https://blog.gopheracademy.com/advent-2015/go-in-a-monorepo/)
>
> The problem that I run into: how to manage dependencies with "go get" ?.. 
> I would like to vendor these dependencies but git wants to treat them as 
> nested repos and doesn't end up vendoring them on commit to the parent repo.
>
> I have tried: moving nested ".git" directories to ".git-moved", etc. This 
> works for vendoring go-gotten repos but is a hassle and also messes up 
> future calls to go get:
>
> $ mv   src/github.com/Sirupsen/logrus/.git   src/github.com/Sirupsen/
> logrus/.git-moved
> $ git add --all; git commit -m 'this commit vendors the logrus package'
> $ go get -u github.com/Sirupsen/logrus
> package github.com/Sirupsen/logrus: directory "/tmp/monorepo/src/
> github.com/Sirupsen/logrus" is not using a known version control system
>
> I would have to mv those .git-moved directories back to .git before using 
> go-get again and this would be a pain and not scalable to a team.
>
> Has anyone come up with a solution for this?
>

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Using go to write plugins for a C host application

[Justin Israel]

On Mon, Nov 14, 2016, 9:28 AM ebw  wrote:

> Hi!
>
> I tried to come up with a way to write plugins in go for a C host
> application using -buildmode=c-shared.
>
> My first try failed, because
>
> go build -buildmode=c-shared
>
>
> insisted to resolve all symbols. I thought I could leave some symbols
> unresolved, so they can be later
> resolved, when the shared library is opened by the host application with
> dlopen.
>
> I tweaked the commands in the output of
>
> go build -buildmode=c-shared
>
>
> a bit and now it works.
>
> But I am unsure wether I am headed for a train wreck later. I assume the
> behavior of go build -buildmode=c-shared
> was selected with great care.
>
> I have a complete example at
>
> https://github.com/erwo42/golang-dlopen-plugin
>
> I don't know, how to make such an example work with the playground, so
> please go out of your way and look
> at the repo.
>
> If you see problems with this, please let me know.
>
> Yours sincerely,
>
> Eric Wolf
>

I had been down a similar path where I was trying to port a go library to
C++ via building a c-shared library and then delegating to it from a thin
C++ API. Turned out I hit problems with it in practice, in related to
static thread local storage model, as well as signal handling conflicts in
the host app. I ended up having to ditch it and port to pure C++ so that my
C++ users could use it in a large shared host application (lots of plugins)

> --
> 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 https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: Is it a compiler bug?

[Michael Jones]

I think I see the confusion here…

 

When you have a line comment symbol “//” in go, “c” in FORTRAN, “;” in 
assembler, etc. you are safe. There is never confusion.

 

When you have a block comment symbol though, “/*” and “*/” in C/C++/…/Go, “{“ 
and “}” in PASCAL, etc., then you have the problem of nested and overlapping 
comment blocks.

 

One issue is that the body of comments is generally considered free text rather 
than code, text without rules and regulations…which is generally necessary for 
the comment writer to get their job done. However, this freedom comes at the 
price of potential confusion when the end of comment symbol appears somewhere 
miscellaneous in the comment block.

 

It might seem that the end symbol should only be recognized on a line by 
itself. (immediately after a newline)

 

It might seem that nesting should happen, where a begin symbol does a 
“comment++” and the end symbol means “comment—“ and text is a comment when the 
count > 0.

 

It might seem that “innocent end symbols” like the one in the string literal of 
the initial post should be ignored. If you want this then the parser needs to 
know “is this innocent?” which means that the text in the block is no longer 
unstructured.

 

There are other out of bound ways…generally not explored…but imagine if 
comments were always in green and there was a way to mark text in the editor as 
being green. Then in it would just work. Same if the magic orthogonal property 
was “italic” or “serif font” or “underlined” or any otherness from regular 
text. As it is though, with regular and comment text interwoven, the ability to 
embed end of comment symbols in free form comment text is an inherent problem, 
which is why you find that every language you consult has the same truth.

 

From:  on behalf of Marvin Stenger 

Date: Sunday, November 13, 2016 at 12:05 PM
To: golang-nuts 
Cc: 
Subject: [go-nuts] Re: Is it a compiler bug?

 

What should be wrong? It is as intuitive as it can be. Did you ever wrote a 
lexer/tokenizer?

Am Sonntag, 13. November 2016 08:38:03 UTC+1 schrieb imd3c:

OK, I get it. It's in the spec,  I had to check it. But still, isn't it wrong? 
What's the point, is it tradition or something? I checked C, Java, Rust, they 
all do the same.

-- 
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 https://groups.google.com/d/optout.


-- 
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 https://groups.google.com/d/optout.

[go-nuts] Using go to write plugins for a C host application

[ebw]

Hi!

I tried to come up with a way to write plugins in go for a C host 
application using -buildmode=c-shared.

My first try failed, because

go build -buildmode=c-shared

 
insisted to resolve all symbols. I thought I could leave some symbols 
unresolved, so they can be later
resolved, when the shared library is opened by the host application with 
dlopen.

I tweaked the commands in the output of

go build -buildmode=c-shared


a bit and now it works.

But I am unsure wether I am headed for a train wreck later. I assume the 
behavior of go build -buildmode=c-shared
was selected with great care.

I have a complete example at

https://github.com/erwo42/golang-dlopen-plugin

I don't know, how to make such an example work with the playground, so 
please go out of your way and look
at the repo.

If you see problems with this, please let me know.

Yours sincerely,

Eric Wolf

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: A more elegant way to store references with a slice?

[go-question]

Thanks all for the resources! 

So just to confirm, that (ref) is the only way to hold "references" to 
objects (and not a "reference" to a new copy) in a slice, so that I can 
iterate over the original objects using the slice. Correct?

And In my tryref example, the issue is with the append and that it is 
making a copy of the original objects at a state when it had no references, 
is that right?

It would be nice to see some documentation expanded out to more complex 
types. I understand the docs should be simple and easy to understand and it 
may not matter as all types are handled the same (copy-by-value), but in 
practice the difference can introduce bugs or confusion. To clarify, in 
most cases it won't matter when using a copy of an int, but could if the 
function needs to reference an exact object (in that case a pointer is 
needed).

Related, is there a doc explaining what happens (the rules of copy-by-value 
method) when you pass an argument to a function in the various cases of a 
primitive and complex type? 





On Sunday, November 13, 2016 at 6:57:07 AM UTC-8, Rob 'Commander' Pike 
wrote:
>
> There's also https://blog.golang.org/slices
>
> On Sun, Nov 13, 2016 at 1:50 AM, Jan Mercl <0xj...@gmail.com 
> > wrote:
>
>>
>> On Sun, Nov 13, 2016 at 10:45 AM  
>> wrote:
>>
>> > Also I understand that everything is pass-by-value, but what exactly is 
>> getting passed for tryref that retains the id but not the slice of pointers?
>>
>> The answer can be found in the article linked by Volker earlier in this 
>> thread. I can recommend reading it as well.
>> -- 
>>
>> -j
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Is it a compiler bug?

[Marvin Stenger]

What should be wrong? It is as intuitive as it can be. Did you ever wrote a 
lexer/tokenizer?

Am Sonntag, 13. November 2016 08:38:03 UTC+1 schrieb imd3c:
>
> OK, I get it. It's in the spec,  I had to check it. But still, isn't it 
> wrong? What's the point, is it tradition or something? I checked C, Java, 
> Rust, they all do the same.
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] [ANN] Go geospatial libraries: geometries, GeoJSON, WKB, KML, PostGIS, GPX, polyline

[Tom Payne]

A quick announce of a few libraries for geospatial applications that are 
now mature and battle-tested:

https://github.com/twpayne/go-geom : efficient geometry library, using a 
high-performance cache-friendly data representation (more info 
), with import 
and export from multiple formats 
 (e.g. GeoJSON, 
WKB, KML) and many 2D geometry functions 
. Really easy PostGIS 
integration with database/sql 
.


https://github.com/twpayne/go-kml : generate KML files quickly and flexibly.


https://github.com/twpayne/go-gpx : read and write GPX files.


https://github.com/twpayne/go-polyline : encode and decode data to/from 
Google Maps Polyline format.

I think that go-geom's internal data representation 
 is a nice 
example of high performance Go code and a reasonable attempt at practical 
code while the language does not support generics.

All feedback welcome!

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: A more elegant way to store references with a slice?

[Rob Pike]

There's also https://blog.golang.org/slices

On Sun, Nov 13, 2016 at 1:50 AM, Jan Mercl <0xj...@gmail.com> wrote:

>
> On Sun, Nov 13, 2016 at 10:45 AM  wrote:
>
> > Also I understand that everything is pass-by-value, but what exactly is
> getting passed for tryref that retains the id but not the slice of pointers?
>
> The answer can be found in the article linked by Volker earlier in this
> thread. I can recommend reading it as well.
> --
>
> -j
>
> --
> 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 https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: JSON parser

[Sergio Hunter]

I did my code, thanks all who help me. Next task, It is necessary then json 
string pulls out three parameters, counted and discharged into a CSV format 
with the columns Date, Revenue, Gold. 


package main

import (
"database/sql"
"log"
_"github.com/go-sql-driver/mysql"
"compress/zlib"
"os"
"fmt"
"bytes"
"io"
"encoding/json"
)



func main() {
db, err := sql.Open("mysql", "name:password@tcp(127.0.0.1:port)/database")
if err != nil {
panic(err.Error())
}
defer db.Close()

rows, err := db.Query(`SELECT data FROM user_stats ORDER BY created_at 
LIMIT 10`)
if err != nil {
log.Fatal(err)
}
defer rows.Close()

for rows.Next() {
var data []byte
err := rows.Scan()
if err != nil {
log.Fatal(err)
}
type UserStatsData struct {
Date string `json:"d"`
Revenue float64 `json:"r"`
Gold int `json:"g"`
}
userStatsData := UserStatsData{}
err = json.Unmarshal(data, )
if err != nil {
r, err := zlib.NewReader(bytes.NewReader(data))
if err != nil {
log.Panicf("Cannot read archive %v", err);
}
io.Copy(os.Stdout, r)
r.Close()
}

}
}


-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: A more elegant way to store references with a slice?

[Jan Mercl]

On Sun, Nov 13, 2016 at 10:45 AM  wrote:

> Also I understand that everything is pass-by-value, but what exactly is
getting passed for tryref that retains the id but not the slice of pointers?

The answer can be found in the article linked by Volker earlier in this
thread. I can recommend reading it as well.
-- 

-j

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: A more elegant way to store references with a slice?

[question . developer]

Thanks for the reply, I should've put "reference type" in quotes.

The intention of the post was to get another's perspective to any better 
method to accomplish the example, which is to use a slice as a container of 
objects. Is there any other way besides how I implemented it?

Also I understand that everything is pass-by-value, but what exactly is 
getting passed for tryref that retains the id but not the slice of pointers?








On Sunday, November 13, 2016 at 1:03:55 AM UTC-8, Volker Dobler wrote:
>
> Go has no notion of "reference type". And pointer types are just
> that pointers. Never think about pointer types as reference types.
> There are values and pointers to values.
> Slices are a bit complicated: Please read
> https://blog.golang.org/go-slices-usage-and-internals
> carefully. It explains everything you need to know better
> than I could do here.
>
> V.
>
> Am Sonntag, 13. November 2016 05:52:49 UTC+1 schrieb 
> question@gmail.com:
>>
>> To keep a reference to a set of objects in a slice, must it be of type 
>> []*T ?
>>
>> Is there a more elegant way to handle the following example?
>>
>> https://play.golang.org/p/73lfAntNzb
>>
>> tryref.id is an immutable value type and try.others is a reference type 
>> correct? can you explain why the id is copied properly but the reference to 
>> the object as well as tryref.others are not?
>>
>> I assume its because golang is pass by value and the type of 
>> tryref.others is not a pointer so when appending an object it creates a new 
>> instance.
>>
>>

-- 
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 https://groups.google.com/d/optout.