[go-nuts] micro review and hello gio: portable GUI code, all in Go

[Jason E. Aten]

Somehow I missed Gio ( https://gioui.org/ ) on its first announcement 
earlier this year.

Gio -- as a pure Go GUI framework -- really ought to be better known.

Hence I offer here a short review, and a getting started example project.


A) The micro review: 

I am impressed. Gio provides an immediate mode (read sane, no callback 
soup) graphics framework. Animation and rendering were smooth.

Supporting mobile, wasm, macOS desktop, iOS, android, windows desktop, and 
wayland linux -- with x11 linux in the works, I'm told, is a bold and 
stunning prospect. 

 I've verified myself that macOS and Windows work well.  The same smooth 
experience across platforms that we've come to expect from Go command line 
tools. But now in GUI form.  A game engine based on Gio cannot be far 
behind (anyone want a fun project?!)

One caveat on Windows -- you may need to ship along the ANGLE DLLs from 
Chrome that are included in hello_gio below.  Eventually, the author of 
Gio, Elias Naur, posted that he plans to also have Vulkan underneath, which 
might prove more native to Windows. But relying on the same battle hardened 
OpenGL translation layer DLLs that Chrome and Firefox utilize on Windows is 
a minor packaging addendum at worst.

While still young and evolving quickly, I appreciate the ambition of Gio. 
What if Go were the preferred language for writing (portable) Apps and 
Games of all kinds?


B) The example, starter code:

I think it is worth posting my hello world experience with Gio. Both as a 
demonstration of its prowess, and a guide to help 
others getting started. Should you be so inclined, hello_gio will get you 
drawing graphics in no time.

https://github.com/glycerine/hello_gio

Any questions, raise an issue on the github issues tracker, or see the Gio 
mailing list https://lists.sr.ht/~eliasnaur/gio


Enjoy.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b1c325b0-5b20-475e-9338-2927a1249f41%40googlegroups.com.

[go-nuts] PKCs8 generated using go has errors when doing a openssl check

[rajesh nataraja]

Hi All, 

I have the following piece of code to generate a private key in PKCS8 form 
and save it in a file. It does generate a file, but when I try to check 
using the openssl command 

openssl rsa -in rsapk.key -check 
I get the following errors 

140092967139232:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong 
tag:tasn_dec.c:1199:
140092967139232:error:0D06C03A:asn1 encoding 
routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:767:
140092967139232:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:699:Field=n, 
Type=RSA
140092967139232:error:04093004:rsa routines:OLD_RSA_PRIV_DECODE:RSA 
lib:rsa_ameth.c:121:


Anyone knows what is wrong with my method?

package main

import (
"crypto/x509"
"crypto/rsa"
"encoding/pem"
"io/ioutil"
"crypto/rand"
"encoding/asn1"
)

type privateKeyInfo struct {
Version int
PrivateKeyAlgorithm []asn1.ObjectIdentifier
PrivateKey  []byte
}


func NewPKCS8PrivateKey() {

var pkey privateKeyInfo
var bKey []byte
oidPublicKeyRSA  := asn1.ObjectIdentifier{1, 2, 840, 113549, 1, 1, 1}


key, err := rsa.GenerateKey(rand.Reader, 2048)
if err != nil {
return
}

pkey.Version = 0
pkey.PrivateKeyAlgorithm = make([]asn1.ObjectIdentifier, 1)
pkey.PrivateKeyAlgorithm[0] = oidPublicKeyRSA
pkey.PrivateKey = x509.MarshalPKCS1PrivateKey(key)

bKey , _ = asn1.Marshal(pkey)

block := pem.Block{Type: "RSA PRIVATE KEY", Bytes: bKey}

ioutil.WriteFile("./rsapk.key",  pem.EncodeToMemory(), 0600)

}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c3ee6970-555f-43d2-a3ca-6d67f5475bbf%40googlegroups.com.

Re: [go-nuts] ent: an entity framework for Go

[Ariel Mashraki]

Yes. PostgreSQL support will be added soon.
You can track its progress in our roadmap to v1 - 
https://github.com/facebookincubator/ent/issues/46

On Thursday, October 3, 2019 at 7:52:01 PM UTC+3, Marcin Romaszewicz wrote:
>
> That looks very nice, congrats! I like that it's simple and doesn't try to 
> solve every problem, just simple relationships, so you can solve most of 
> your simple DB schema needs (and most DB usage is quite simple in most 
> services).
>
> Do you have any plans to add a Postgres driver?
>
> -- Marcin
>
> On Thu, Oct 3, 2019 at 8:11 AM Noam Schachter  > wrote:
>
>> Hi gophers,
>>
>> My team at Facebook Connectivity has just open-sourced a new ORM for Go 
>> and would love your feedback about it.
>> GitHub repo at: https://github.com/facebookincubator/ent
>> Story behind it in our blog post: 
>> https://entgo.io/blog/2019/10/03/introducing-ent/ 
>>
>> Thanks!
>> Noam
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/16a50745-1744-4fe5-be93-aca2b96fcebc%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f9b7637c-e946-46b0-adc0-59612ea81662%40googlegroups.com.

Re: [go-nuts] Channels may not be the best solution in Go

[burak serdar]

On Thu, Oct 3, 2019 at 11:59 AM JuciÊ Andrade  wrote:
>
> Burak, feel free to correct me if I am wrong, but now I think I understood 
> the heart of the matter:
>
> Your approach to software development is different from mine. Nothing wrong 
> with that.
>
> . you normally write sequential code, and uses concurrent code where it fits 
> best. That is fine.
> . I use to write concurrent code, and use sequential code where it fits best. 
> That is fine as well.
>
> Concurrency mechanisms in Go are so easy to use that it allows me to take 
> that approach.
> With a little bit of caution to not create a big ball of mud[1], you can 
> write clean concurrent code.
> You said there is a synchronization overhead when a program uses channels. 
> That is true.
> On the other hand, when we divide the load among several cores we end up with 
> a net gain.
> Depending on the task at hand the difference can be staggering! I mean 15x 
> faster or more!
>
> If we consider that nearly all CPU is multicore these days [2], we will soon 
> conclude that writing concurrent code even for simple tasks makes sense, in 
> order to leverage that processing power.
>
> Your concurrent code will run keep running well in newer CPUs. Your single 
> threaded code won't.

Not all programs benefit from concurrency. Writing concurrent code for
essentially sequential programs will not benefit from multiple cores,
like generating prime numbers. Do not forget that concurrency includes
overhead for context switch and memory barriers. Using channels in a
sequential program is I think misuse of channels. There is no
performance gain in having a sequence of goroutines, each waiting for
the previous one the complete.


>
> Again, nothing wrong with your approach, ok? To each its own.
>
> [1] http://laputan.org/mud/
> [2] https://www.amd.com/en/products/cpu/amd-epyc-7742
>
>
>
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/41a107de-e426-456a-abab-d0b058e39373%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqqGSQd61EE_UfdMYKYAWbZ1mXK8mTPDLv18igE%2BA2R0OQ%40mail.gmail.com.

Re: [go-nuts] Channels may not be the best solution in Go

[Robert Engels]

A point to consider though, is that often sequential code is used and concurrency is achieved by running multiple processes. This is pretty much the design of the cloud. A top-level coordinator partitions the work-load, and sequential programs process it, and the top-level assembles the results - think map/reduce at scale. Often the complexity of concurrency within a process is not needed (or is completely hidden away).-Original Message-
From: JuciÊ Andrade 
Sent: Oct 3, 2019 12:58 PM
To: golang-nuts 
Subject: Re: [go-nuts] Channels may not be the best solution in Go

Burak, feel free to correct me if I am wrong, but now I think I understood the heart of the matter:Your approach to software development is different from mine. Nothing wrong with that.. you normally write sequential code, and uses concurrent code where it fits best. That is fine.. I use to write concurrent code, and use sequential code where it fits best. That is fine as well.Concurrency mechanisms in Go are so easy to use that it allows me to take that approach.With a little bit of caution to not create a big ball of mud[1], you can write clean concurrent code.You said there is a synchronization overhead when a program uses channels. That is true.On the other hand, when we divide the load among several cores we end up with a net gain.Depending on the task at hand the difference can be staggering! I mean 15x faster or more!If we consider that nearly all CPU is multicore these days [2], we will soon conclude that writing concurrent code even for simple tasks makes sense, in order to leverage that processing power.Your concurrent code will run keep running well in newer CPUs. Your single threaded code won't.Again, nothing wrong with your approach, ok? To each its own.[1] http://laputan.org/mud/[2] https://www.amd.com/en/products/cpu/amd-epyc-7742



-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/41a107de-e426-456a-abab-d0b058e39373%40googlegroups.com.




-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1136160789.5311.1570130467434%40wamui-cheeto.atl.sa.earthlink.net.

Re: [go-nuts] Channels may not be the best solution in Go

[JuciÊ Andrade]

Burak, feel free to correct me if I am wrong, but now I think I understood 
the heart of the matter:

Your approach to software development is different from mine. Nothing wrong 
with that.

. you normally write sequential code, and uses concurrent code where it 
fits best. That is fine.
. I use to write concurrent code, and use sequential code where it fits 
best. That is fine as well.

Concurrency mechanisms in Go are so easy to use that it allows me to take 
that approach.
With a little bit of caution to not create a big ball of mud[1], you can 
write clean concurrent code.
You said there is a synchronization overhead when a program uses channels. 
That is true.
On the other hand, when we divide the load among several cores we end up 
with a net gain.
Depending on the task at hand the difference can be staggering! I mean 15x 
faster or more!

If we consider that nearly all CPU is multicore these days [2], we will 
soon conclude that writing concurrent code even for simple tasks makes 
sense, in order to leverage that processing power.

Your concurrent code will run keep running well in newer CPUs. Your single 
threaded code won't.

Again, nothing wrong with your approach, ok? To each its own.

[1] http://laputan.org/mud/
[2] https://www.amd.com/en/products/cpu/amd-epyc-7742




-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/41a107de-e426-456a-abab-d0b058e39373%40googlegroups.com.

Re: [go-nuts] ent: an entity framework for Go

[Marcin Romaszewicz]

That looks very nice, congrats! I like that it's simple and doesn't try to
solve every problem, just simple relationships, so you can solve most of
your simple DB schema needs (and most DB usage is quite simple in most
services).

Do you have any plans to add a Postgres driver?

-- Marcin

On Thu, Oct 3, 2019 at 8:11 AM Noam Schachter  wrote:

> Hi gophers,
>
> My team at Facebook Connectivity has just open-sourced a new ORM for Go
> and would love your feedback about it.
> GitHub repo at: https://github.com/facebookincubator/ent
> Story behind it in our blog post:
> https://entgo.io/blog/2019/10/03/introducing-ent/
>
> Thanks!
> Noam
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/16a50745-1744-4fe5-be93-aca2b96fcebc%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LsNFjMkPj_PfFTyjSD2KhwQkAXFssUaUvXUAeuAanv9gQ%40mail.gmail.com.

[go-nuts] Show rows affected from query

[Tamás Gulácsi]

Query is for SELECT. Everything else needs Exec.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a662ba2c-be5e-4f37-adc1-ac1fd479a05b%40googlegroups.com.

[go-nuts] encoding/json character escaping question

[Poussier William]

Hello

The encoding/json package escapes 0xA (line feed), 0xD (carriage return) 
and 0x9 (horizontal tab) using the escape character '\'. However, when it 
comes to 0x8 (backspace) and 0xc (form feed), it uses the Unicode escape 
sequence staring with '\u'.

Reproducer: https://play.golang.org/p/jihv9sZUjvY

I can't really grasp the reason behind this difference for characters < 
0x20, even tho it is perfectly valid JSON, I expected to see \f and \b.

Does anyone know the reason, if there is one that lead to this?

Thanks

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f3c65b8c-c612-4b75-852a-fda7b246a77e%40googlegroups.com.

[go-nuts] ent: an entity framework for Go

[Noam Schachter]

Hi gophers,

My team at Facebook Connectivity has just open-sourced a new ORM for Go and 
would love your feedback about it.
GitHub repo at: https://github.com/facebookincubator/ent
Story behind it in our blog post: 
https://entgo.io/blog/2019/10/03/introducing-ent/ 

Thanks!
Noam

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/16a50745-1744-4fe5-be93-aca2b96fcebc%40googlegroups.com.

Re: [go-nuts] Channels may not be the best solution in Go

[burak serdar]

On Thu, Oct 3, 2019 at 8:40 AM JuciÊ Andrade  wrote:
>
> On Thursday, October 3, 2019 at 10:47:27 AM UTC-3, burak serdar wrote:
>>
>> On Thu, Oct 3, 2019 at 6:18 AM JuciÊ Andrade  wrote:
>> > I use channels exactly that way and they work pretty well.
>>
>> Then you're paying some penalty for synchronization where the same
>> thing can be achieved without that penalty.
>>
>
> Yes, indeed, but channels offer some significant advantages:
>
> 1. a division of labor between several goroutines is made possible without 
> much effort. That can mean a lot, depending on how much complex is the logic 
> involved in generating each value;

When there are multiple goroutines involved, you have to use channels.

> 2. a possibly very complex state is preserved between each generated value 
> (the execution stack);

This I disagree. A list achieves the same purpose without
synchronization overhead.

>
> I would dare to say that a prime number generator is more of an exception, 
> because the state to be preserved between calls is well understood. Now think 
> about some evolving code, where you can't know beforehand how complex that 
> will be some years from now. Channels are a safer bet.

Honestly, I don't understand this argument. Complexity of sequential
code has got nothing to do with concurrent behavior. If there is no
concurrency, then there is no need to use channels.

>
> Anyway, you are correct: each use must be evaluated in it's pros an cons. You 
> will see that in the vast majority of cases channels performance is more than 
> enough.
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/eb84a84c-be8d-4b81-8c5c-33cb09b70168%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrD6U8giuDp0WSNr6Yqtwq7K6JO9J4rqVtKTgtXKC4Ehg%40mail.gmail.com.

Re: [go-nuts] Channels may not be the best solution in Go

[JuciÊ Andrade]

On Thursday, October 3, 2019 at 10:47:27 AM UTC-3, burak serdar wrote:
>
> On Thu, Oct 3, 2019 at 6:18 AM JuciÊ Andrade  > wrote: 
> > I use channels exactly that way and they work pretty well. 
>
> Then you're paying some penalty for synchronization where the same 
> thing can be achieved without that penalty. 
>
>
Yes, indeed, but channels offer some significant advantages:

1. a division of labor between several goroutines is made possible without 
much effort. That can mean a lot, depending on how much complex is the 
logic involved in generating each value;
2. a possibly very complex state is preserved between each generated value 
(the execution stack);

I would dare to say that a prime number generator is more of an exception, 
because the state to be preserved between calls is well understood. Now 
think about some evolving code, where you can't know beforehand how complex 
that will be some years from now. Channels are a safer bet.

Anyway, you are correct: each use must be evaluated in it's pros an cons. 
You will see that in the vast majority of cases channels performance is 
more than enough.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/eb84a84c-be8d-4b81-8c5c-33cb09b70168%40googlegroups.com.

[go-nuts] Re: Call of a Go-function inside C-code

[dr . ch . maurer]

Dear Ian Lance Taylor,

thankyou very much for your hint!

Kind regards, Christian

Am Mittwoch, 2. Oktober 2019 04:36:4D8 UTC+2 schrieb Christian Maurer:
>
> Dear community,
>
> what is wrong with the following simple code, which yields "undefined 
> reference for F" ?
>
>
> file f.go:
>
> package main
> // #include "f.h"
> // void f (int a) { F(a) }
> import "C"
>
> func F(a int) { println(a) }
> func main() { C.f(7) }
>
>
> file f.h:
>
> extern void F (int a);
>
> //export F
>
>
> Thanks in advance for any help,
> Christian
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0b53181a-eb6c-4c0f-a1f9-df5013c0eb55%40googlegroups.com.

[go-nuts] Re: Go WASM question

[Leopoldo Caballero]

A map in Go is not ordered, so even the iteration is not the same between 
several iterations. You can see: https://blog.golang.org/go-maps-in-action
I suppose something similar occurs with objects in JS.

So, maybe you can iterate the map and output a slice and then sort the 
slice, that is maybe your currently approach.


On Wednesday, October 2, 2019 at 7:45:34 AM UTC-5, Tad Vizbaras wrote:
>
> I have sizable Go WASM application that creates map[string]interface{} and 
> passes to JS or reads from JS library.
> Go maps do not have predefined key order. But JS has object property order 
> predictable in JavaScript objects since ES2015.
>
> Problem: when JS objects are transferred from JS into Go and back they key 
> order becomes scrambled.
> At this point I have a small fix inside JS application that simply 
> reorders keys coming from Go back into JS.
> A bit of a hack but works.
>
> Question: is there better solution?
>
> My environment:
> 1. Go 1.13.
> 2. Chrome and Edge browsers.
> 3. Windows 10 desktop 64bits.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e22b0838-cc8f-4ea5-9586-dafd9f976542%40googlegroups.com.

[go-nuts] Re: Call of a Go-function inside C-code

[dr . ch . maurer]

Dear Ian Lance Taylor,

thankyou very much for your hint!

Kind regards, Christian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/969b21e9-7b90-4e39-bb63-2f9a6418d198%40googlegroups.com.

Re: [go-nuts] Channels may not be the best solution in Go

[burak serdar]

On Thu, Oct 3, 2019 at 6:18 AM JuciÊ Andrade  wrote:
>
> On Thursday, October 3, 2019 at 2:24:20 AM UTC-3, burak serdar wrote:
>>
>> It can be argued that you were misusing channels. Channels are
>> synchronization mechanisms between goroutines. They are not generic
>> data pipes.
>
>
> I use channels exactly that way and they work pretty well.

Then you're paying some penalty for synchronization where the same
thing can be achieved without that penalty.

>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/8be28087-29d9-4544-8a1d-d6108b95c4b3%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqosctJtTU4OT00q0w3tUGaF%2BVGhpy8Nysi6RiL9KFGV9w%40mail.gmail.com.

[go-nuts] Show rows affected from query

[Rich]

I've written a program that allows users to put in MySQL queries and get 
results from it. Those queries can be selects, inserts, update, delete etc. 
I would a better sample of the code but currently the code is over 1000+ 
lines, but I do something like this:

db,err :=sql.Open(mysql, loginCreds)
rows, err db.Query("")

This works, and you can do selects, inserts, deletes, drop -- basically any 
query you can run with the mysql client will work, but what you're missing 
is when it doesn't have any rows to display is the rows affected (such as 
an insert or update).  I have nothing to return to the user other than the 
query worked.  So the user has no idea if 1 or 1 rows were updated or 
deleted from the query.  For this I'd have to be using db.Exec which 
returns an sql.Result, where I can pull the rows affected. Is there a way 
to get rows affected from a query? I don't want to have a decision tree to 
figure out based on the query given to use sql.Exec or sql.Query.  I am not 
that good of a DBA to be able to figure that out. :)

Thanks,

Rich

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cdddfce5-0fd8-4776-844b-1f5cd5ef33b0%40googlegroups.com.

Re: [go-nuts] Channels may not be the best solution in Go

[JuciÊ Andrade]

On Thursday, October 3, 2019 at 2:24:20 AM UTC-3, burak serdar wrote:
>
> It can be argued that you were misusing channels. Channels are 
> synchronization mechanisms between goroutines. They are not generic 
> data pipes.
>

I use channels exactly that way and they work pretty well. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8be28087-29d9-4544-8a1d-d6108b95c4b3%40googlegroups.com.

[go-nuts] GoLang's ReverseProxy

[Patrik Iselind]

Hi,

I'm using the ReverseProxy from the httputil package and cannot figure out 
how the director can communicate to the reverse proxy that the director 
failed to rebuild the request. The result, as I see it, should become an 
HTTP 500/502 error being returned to the caller and the request not proxied.

Is there anyone here that can see how to communicate that failure? Is this 
something that should be added to the reverse proxy implementation?

Sincerely,
Patrik

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d51dd7e7-b3ae-4ffb-9058-a9822a58a8b6%40googlegroups.com.