Re: [go-nuts] Upgrade to Go1.16 from Go1.14 broke my query

[Hugh Myrie]

Yes. It seems that's the case. I'm floored.

On Fri, Jun 25, 2021 at 7:17 PM Hugh Myrie  wrote:

> Bypassing the error returns an empty result set.
>
>  Additional information: "string right truncation /expected length 0,
> actual 3". In the DB the Code field is varchar(3) and Description is
> Varchar(30).
>
> It seems to have something to do with the return field size and the size
> expected in Golang.
> On Friday, June 25, 2021 at 3:24:25 AM UTC-5 rol...@gmail.com wrote:
>
>> Hello,
>>
>> Am Do., 24. Juni 2021 um 18:14 Uhr schrieb Hugh Myrie > >:
>>
>>> I recently updated my Go version to 1.16 and for all my queries I now
>>> get an error:
>>>
>>> {"error":"Dynamic SQL Error\nSQL error code = -303\narithmetic
>>> exception, numeric overflow, or string truncation\nstring right
>>> truncation\n"}
>>>
>>> I'm using  the package:   _ "github.com/nakagami/firebirdsql"
>>>
>>> The following is a simple function:
>>>
>>> func getSystem(w http.ResponseWriter, r *http.Request) {
>>> type system struct {
>>> Tax1float64  `json:"tax1"`
>>> Fees1  float64  `json:"fees1"`
>>> Fees2   float64  `json:"fees2"`
>>> Minus_stk string `json:"minus_stk"`
>>> Discount1 float64 `json:"discount1"`
>>> Discount2 float64 `json:"discount2"`
>>> Discount3 float64 `json:"discount3"`
>>> Discount4 float64 `json:"discount4"`
>>> Elderly float64 `json:"elderly"`
>>> Message NullString `json:"message"`
>>> Binary4 NullString `json:"binary4"`
>>> }
>>> sysdata := []system{}
>>> sql2 := "select tax1, fees1, fees2, minus_stk, discount1, discount2,
>>> discount3, discount4, elderly, cast(mesg as varchar(400)), binary4 from
>>> system"
>>> conn, _ := sql.Open("firebirdsql",  datapath)
>>> defer conn.Close()
>>> rows, err := conn.Query(sql2)
>>> if err != nil {
>>> respondWithError(w, http.StatusBadRequest, err.Error())
>>> return
>>> }
>>> defer rows.Close()
>>> for rows.Next() {
>>> var p system
>>> err := rows.Scan(, , , _stk,
>>> , , , , ,
>>> , )
>>> if err != nil {
>>> respondWithError(w, http.StatusBadRequest, err.Error())
>>> return
>>> }
>>> sysdata = append(sysdata, p)
>>> }
>>> err = rows.Err()  //  <--- errors seem to thrown here.
>>> if err != nil {
>>> respondWithError(w, http.StatusBadRequest, err.Error())
>>> return
>>> }
>>> respondWithJSON(w, http.StatusOK, sysdata)
>>> }
>>>
>>> Your help would be appreciated.
>>>
>>> I'm using Firebird 2.5. Everything worked under the previous version of
>>> Go. I am scanning for null values so I don't believe that is the issue.
>>>
>>> ust a wild guess not "biased" by any close knowledge of Firebird DB or
>> the above mentioned Go module: there has something changed with handling of
>> rows.Next() when the last row of data has been passed. This guess is based
>> on the fact that your mark the error only occurs after reading all data
>> rows.
>>
>> I would try to log a warning to server log and try to return the JSON
>> data instead of returning http.StatusBadRequest. It may be that the data is
>> valid.
>>
>> BR,
>> Roland
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/BHxTxzCpUB4/unsubscribe.
> To unsubscribe from this group and all its topics, 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/9f77d3d8-a666-48f1-8da8-43b0a076a132n%40googlegroups.com
> 
> .
>


-- 
http://www.jaxtr.com/blessed_hope

-- 
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/CAN-X3%3DYvTqF_zAXnjRuX5pPe2uLd3ZkS7szhUP01C4S5S%2BOEcQ%40mail.gmail.com.

Re: [go-nuts] Go and GPUs

[Robert Engels]

Agreed. (Didn’t see your previous message before I sent that). 

> On Jun 25, 2021, at 9:25 PM, David Riley  wrote:
> 
> On Jun 25, 2021, at 10:23 PM, Robert Engels  wrote:
>> 
>> There is also a LOT of support for Java and CUDA/OpenCL. You can essentially 
>> reimplement them Java portion in Go. There are multiple open source projects 
>> in this area. 
>> 
>> Might be a lot easier than starting from scratch. 
> 
> Yes, CGo is going to be similar to JNI in this context.
> 
> 
> - Dave

-- 
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/A8F2881B-7CC9-4E4A-9945-23F9D55BF5D0%40ix.netcom.com.

Re: [go-nuts] Go and GPUs

[David Riley]

On Jun 25, 2021, at 10:23 PM, Robert Engels  wrote:
> 
> There is also a LOT of support for Java and CUDA/OpenCL. You can essentially 
> reimplement them Java portion in Go. There are multiple open source projects 
> in this area. 
> 
> Might be a lot easier than starting from scratch. 

Yes, CGo is going to be similar to JNI in this context.


- Dave

-- 
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/70F2856D-0640-490F-BFAC-366A17A991AD%40gmail.com.

Re: [go-nuts] Go and GPUs

[Robert Engels]

There is also a LOT of support for Java and CUDA/OpenCL. You can essentially 
reimplement them Java portion in Go. There are multiple open source projects in 
this area. 

Might be a lot easier than starting from scratch. 

> On Jun 25, 2021, at 8:03 PM, Michael Poole  wrote:
> 
> On Fri, Jun 25, 2021 at 11:52 AM Nikolay Dubina wrote:
>> 
>> I tried to write down my own CUDA / NVIDIA GPU driver in native Go last 
>> weekend. To my great surprise, CUDA and pretty much all high performance 
>> software/hardware from NVIDIA is proprietary close-source C/C++ code. 
>> Meaning, you can't write native Go driver even if you wanted to. Forget Go, 
>> people are trying to reverse engineer it in C/C++ with limited success. From 
>> what I heard OpenCV is not a priority for NVIDIA either. Then I looked up 
>> what Apple is doing with their Neural Engine in latest chips. It too is 
>> closed-source Objective-C, Swift. I suspect situation with other powerful 
>> hardware is the same. Moore's law seem to be about GPU lately, and everyone 
>> is locking it in. Kind of not in the spirit open-source and Linux. That's 
>> quite bad state of affairs for Go and computing in general. Yikes!
>> 
>> Just want to see what others are thinking.
> 
> That would be a very nice thing to have.  I see four basic areas where
> this becomes tricky or requires a lot of work.
> 
> 1) Getting memory management right for sharing with the accelerator
> device.  Shared memory buffers need to stay locked for longer than
> just the call to a library or to the OS kernel, but in the worse case
> could use something like Manish Rai Jain of Dgraph described at
> https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/
> .  A lot of Nvidia's recent CUDA programmer-productivity improvements
> have focused around transparent data movement, and Go's garbage
> collector probably breaks the assumptions for those.
> 
> 2) "Friendly" source development (like CUDA C) integrates the host and
> target code into a single code base, with some kind of markup or
> compiler hint about which functions should be compiled for the
> accelerator, and which function calls need to be treated specially.
> Those "special" function calls must be translated to dispatch the call
> (usually with additional arguments like the grid/NDRange parameters)
> to the accelerator rather than as a normal function call.  This is a
> compiler front-end problem, which is almost certainly a lot easier
> with Go than with C or C++, but still requires attention and perhaps
> considerable effort because it requires multiple back-ends to run for
> some functions.  In the worst case, do like OpenCL and require the
> programmer to provide or build strings containing program text, along
> with verbose code to set up calls to the accelerator.
> 
> 3) Generating code for the accelerator.  SPIR-V is an obvious
> candidate for portable uses; it integrates reasonably with current
> OpenCL as well as Vulkan.  Nvidia makes a reasonable compromise for
> this with their PTX assembly pseudo-language: They have good
> documentation about which PTX instructions are only supported on some
> GPU generations, they document when the translation to actual machine
> code varies in major ways, and they even have a decent API for
> compiling application-provided PTX code.  This is a compiler back-end
> problem, conditional on not accepting the "worst case" in #2 above.
> 
> 4) Integrating target libraries with the rest of an application.  A
> large part of the value proposition for CUDA is that it has a lot of
> highly optimized libraries available out of the box: cuFFT,
> cuBLAS/NVBLAS, and more.  These are a hybrid between GPU elements and
> host elements, and a lot of the host elements end up being black boxes
> with respect to other languages.  The most general fix is to call out
> to C, which is not satisfying for portability.
> 
> If I were going to spend the time on this, I would probably target
> SPIR-V with Vulkan or OpenCL for portability rather than Nvidia's PTX
> or Apple's Metal.  AMD, Nvidia and Google (Android) all have good
> support for SPIR-V through their Vulkan stacks, and there are
> third-party Vulkan layers that run on MacOS.
> 
> - Michael Poole
> 
> -- 
> 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/CAOU-OAK3dUn0hDAvEt3ayhQO4Ryg2-bMpaKZTCxW086%2BYFFnpQ%40mail.gmail.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 

Re: [go-nuts] Go and GPUs

[David Riley]

On Jun 25, 2021, at 1:32 PM, Robert Engels  wrote:
> 
> Why not develop a Go <> CUDA binding using CGo?

This (ditto for OpenCL, Vulkan, etc) is more likely the path you'll have to go 
down.  Generally all of these interfaces rely on pretty massive libraries from 
NVIDIA, AMD, Intel, etc. which are only going to have a C ABI because basically 
every other language on the planet uses the C ABI (with exceptions for 
interpreted languages like Java or Pythons, which contain adaptations like JNI 
to the C ABI, whose purpose is fulfilled by CGo here).

You're not going to get a non-CGo interface to any mainstream GPU programming 
interface unless you happen to have enough money to convince Intel, AMD and 
NVIDIA to go to the trouble of writing them, at which point you will also be 
involving massive industry committees. You don't want that.

CGo is an acceptable tradeoff here, IMO, because the overhead of bus 
transactions to the GPU is likely to be much worse than any overhead CGo adds 
unless you're doing something terribly wrong. You want large, infrequent 
transactions that you can queue up, otherwise you'll eat up all your time 
waiting for transactions anyway.

Consider that plenty of high performance GPU computation is done using plain 
Python interfaced to CUDA. The interface to the library isn't what matters, 
it's what you do with it.

These interfaces already exist in various states of maintenance, FWIW:

https://github.com/gorgonia/cu (last updated a year or so ago)
https://github.com/rafaelescrich/cuda-go (last updated about half a year ago)


- Dave

-- 
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/7786F4DE-CF75-471B-9709-EE1C9A4DAF1D%40gmail.com.

Re: [go-nuts] Go and GPUs

[Michael Poole]

On Fri, Jun 25, 2021 at 11:52 AM Nikolay Dubina wrote:
>
> I tried to write down my own CUDA / NVIDIA GPU driver in native Go last 
> weekend. To my great surprise, CUDA and pretty much all high performance 
> software/hardware from NVIDIA is proprietary close-source C/C++ code. 
> Meaning, you can't write native Go driver even if you wanted to. Forget Go, 
> people are trying to reverse engineer it in C/C++ with limited success. From 
> what I heard OpenCV is not a priority for NVIDIA either. Then I looked up 
> what Apple is doing with their Neural Engine in latest chips. It too is 
> closed-source Objective-C, Swift. I suspect situation with other powerful 
> hardware is the same. Moore's law seem to be about GPU lately, and everyone 
> is locking it in. Kind of not in the spirit open-source and Linux. That's 
> quite bad state of affairs for Go and computing in general. Yikes!
>
> Just want to see what others are thinking.

That would be a very nice thing to have.  I see four basic areas where
this becomes tricky or requires a lot of work.

1) Getting memory management right for sharing with the accelerator
device.  Shared memory buffers need to stay locked for longer than
just the call to a library or to the OS kernel, but in the worse case
could use something like Manish Rai Jain of Dgraph described at
https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/
.  A lot of Nvidia's recent CUDA programmer-productivity improvements
have focused around transparent data movement, and Go's garbage
collector probably breaks the assumptions for those.

2) "Friendly" source development (like CUDA C) integrates the host and
target code into a single code base, with some kind of markup or
compiler hint about which functions should be compiled for the
accelerator, and which function calls need to be treated specially.
Those "special" function calls must be translated to dispatch the call
(usually with additional arguments like the grid/NDRange parameters)
to the accelerator rather than as a normal function call.  This is a
compiler front-end problem, which is almost certainly a lot easier
with Go than with C or C++, but still requires attention and perhaps
considerable effort because it requires multiple back-ends to run for
some functions.  In the worst case, do like OpenCL and require the
programmer to provide or build strings containing program text, along
with verbose code to set up calls to the accelerator.

3) Generating code for the accelerator.  SPIR-V is an obvious
candidate for portable uses; it integrates reasonably with current
OpenCL as well as Vulkan.  Nvidia makes a reasonable compromise for
this with their PTX assembly pseudo-language: They have good
documentation about which PTX instructions are only supported on some
GPU generations, they document when the translation to actual machine
code varies in major ways, and they even have a decent API for
compiling application-provided PTX code.  This is a compiler back-end
problem, conditional on not accepting the "worst case" in #2 above.

4) Integrating target libraries with the rest of an application.  A
large part of the value proposition for CUDA is that it has a lot of
highly optimized libraries available out of the box: cuFFT,
cuBLAS/NVBLAS, and more.  These are a hybrid between GPU elements and
host elements, and a lot of the host elements end up being black boxes
with respect to other languages.  The most general fix is to call out
to C, which is not satisfying for portability.

If I were going to spend the time on this, I would probably target
SPIR-V with Vulkan or OpenCL for portability rather than Nvidia's PTX
or Apple's Metal.  AMD, Nvidia and Google (Android) all have good
support for SPIR-V through their Vulkan stacks, and there are
third-party Vulkan layers that run on MacOS.

- Michael Poole

-- 
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/CAOU-OAK3dUn0hDAvEt3ayhQO4Ryg2-bMpaKZTCxW086%2BYFFnpQ%40mail.gmail.com.

Re: [go-nuts] Upgrade to Go1.16 from Go1.14 broke my query

[Hugh Myrie]

Bypassing the error returns an empty result set. 

 Additional information: "string right truncation /expected length 0, 
actual 3". In the DB the Code field is varchar(3) and Description is 
Varchar(30).

It seems to have something to do with the return field size and the size 
expected in Golang.
On Friday, June 25, 2021 at 3:24:25 AM UTC-5 rol...@gmail.com wrote:

> Hello,
>
> Am Do., 24. Juni 2021 um 18:14 Uhr schrieb Hugh Myrie  >:
>
>> I recently updated my Go version to 1.16 and for all my queries I now get 
>> an error:
>>
>> {"error":"Dynamic SQL Error\nSQL error code = -303\narithmetic exception, 
>> numeric overflow, or string truncation\nstring right truncation\n"}
>>
>> I'm using  the package:   _ "github.com/nakagami/firebirdsql"
>>
>> The following is a simple function:
>>
>> func getSystem(w http.ResponseWriter, r *http.Request) {
>> type system struct {
>> Tax1float64  `json:"tax1"`
>> Fees1  float64  `json:"fees1"`
>> Fees2   float64  `json:"fees2"`
>> Minus_stk string `json:"minus_stk"`
>> Discount1 float64 `json:"discount1"`
>> Discount2 float64 `json:"discount2"`
>> Discount3 float64 `json:"discount3"`
>> Discount4 float64 `json:"discount4"`
>> Elderly float64 `json:"elderly"`
>> Message NullString `json:"message"`
>> Binary4 NullString `json:"binary4"`
>> }
>> sysdata := []system{}
>> sql2 := "select tax1, fees1, fees2, minus_stk, discount1, discount2, 
>> discount3, discount4, elderly, cast(mesg as varchar(400)), binary4 from 
>> system"
>> conn, _ := sql.Open("firebirdsql",  datapath)
>> defer conn.Close()
>> rows, err := conn.Query(sql2)
>> if err != nil {
>> respondWithError(w, http.StatusBadRequest, err.Error())
>> return
>> }
>> defer rows.Close()
>> for rows.Next() {
>> var p system
>> err := rows.Scan(, , , _stk, , 
>> , , , , , 
>> )
>> if err != nil {
>> respondWithError(w, http.StatusBadRequest, err.Error())
>> return
>> }
>> sysdata = append(sysdata, p)
>> }
>> err = rows.Err()  //  <--- errors seem to thrown here.
>> if err != nil {
>> respondWithError(w, http.StatusBadRequest, err.Error())
>> return
>> }
>> respondWithJSON(w, http.StatusOK, sysdata)
>> }
>>
>> Your help would be appreciated.
>>
>> I'm using Firebird 2.5. Everything worked under the previous version of 
>> Go. I am scanning for null values so I don't believe that is the issue.
>>
>> ust a wild guess not "biased" by any close knowledge of Firebird DB or 
> the above mentioned Go module: there has something changed with handling of 
> rows.Next() when the last row of data has been passed. This guess is based 
> on the fact that your mark the error only occurs after reading all data 
> rows.
>
> I would try to log a warning to server log and try to return the JSON data 
> instead of returning http.StatusBadRequest. It may be that the data is 
> valid.
>  
> BR,
> Roland
>
>

-- 
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/9f77d3d8-a666-48f1-8da8-43b0a076a132n%40googlegroups.com.

Re: [go-nuts] Recomended GOPROXY (or not) for Open Source projects?

[David Finkel]

On Fri, Jun 25, 2021 at 1:23 PM josvazg  wrote:

> When working on internal company projects, it makes sense to use a company
> wide GO Proxy assuring that all go dependency code is available and
> immutable. But when you move to an Open Source project, you cannot longer
> use such private proxy.
>
> I wonder what is the best practice recommendation for Open Source projects.
>
> I can't comment about whether anything specifically is a "best practice",
but here are my thoughts:


> For instance, reading about https://proxy.golang.org/ is says:
> > Why did a previously available module become unavailable in the mirror?
>
> > proxy.golang.org  does not save all modules
> forever.
>
> Which means, your project may *not compile* anymore if someone pulls one
> of your dependencies and proxy.golang.org decides to drop it.
>
The next line in that FAQ section mentions specific reasons why
proxy.golang.org wouldn't persist a module version in its cache. (e.g.
licences it doesn't recognize as letting it keep/distribute copies of the
code)

This seems like a non-issue if you are careful about your dependencies (and
specifically, their licenses (which seems to be easy to tell now that
pkg.go.dev will flag unrecognized licenses)).

> When you read that, you may decide to just track the vendor/ folder in
> your repo and forget about proxies for OSS projects.
>
> What is the recommendation from the Go community about this?
>
> - Are there public go proxies can be used for OSS projects ensuring you
> will never lose any dependency?
>
> - Is https://goproxy.io/ giving such guarantee maybe?
>
> - Should we just vendor and forget about Go-Proxies for Open Source?
>
Now that Go Modules is relatively mature, please don't use vendoring in
open source projects unless you have a really good reason.
Vendoring makes it impossible for the rest of us to tell whether there are
modifications to those dependencies and blows up your repo's size at the
same time. (at least without some really complicated diffing)

> Thanks,
>
> Jose
>
> --
> 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/47c445ca-884d-49b5-8357-aeae8802e937n%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/CANrC0BizsWRjdZSKXBqCKikhHcNbyWpP9d_pnr7odK3YQq_xgA%40mail.gmail.com.

Re: [go-nuts] Go and GPUs

[Tom Mitchell]

As others have said, lots of secret sauce which includes the instruction
set for the function blocks in silicon.
Thus there is no assembler for the compiler that generates the code.  Other
chunks of the necessary tool chain are also absent or homegrown (no
document other than source).

The best advice is to look at the installation scripts that bind secret
sauce to the exposed API wrapper.
Look at wrappers and install scripts for the same GPU on multiple systems
if you can.

Decades ago I had to be careful when debugging customer problems because
depending on the graphics engine you could walk down customer code to GL
library and system C and ASM code to a off the shelf digital signal
processor code and then custrom processors in VHDL. The C>hardware
transition was almost seamless to a reader with a good tag file and the
full source.  Functional symbols inside the graphics library drivers were
not intended to be used except by the GL but some were too tempting and
those symbols had to be edited out of shipped binary objects to clarify the
ABI and keep the system stable.

Ask nicely for help from the vendor.
I would assert() that GO could be more useful in large clusters of GPU rich
systems if facilitated.
Beware bogus asserts().



On Fri, Jun 25, 2021 at 8:52 AM Nikolay Dubina 
wrote:

> I tried to write down my own CUDA / NVIDIA GPU driver in native Go last
> weekend. To my great surprise, CUDA and pretty much all high performance
> software/hardware from NVIDIA is proprietary close-source C/C++ code.
> Meaning, you can't write native Go driver even if you wanted to. Forget Go,
> people are trying to reverse engineer it in C/C++ with limited success.
> From what I heard OpenCV is not a priority for NVIDIA either. Then I looked
> up what Apple is doing with their Neural Engine in latest chips. It too is
> closed-source Objective-C, Swift. I suspect situation with other powerful
> hardware is the same. Moore's law seem to be about GPU lately, and everyone
> is locking it in. Kind of not in the spirit open-source and Linux. That's
> quite bad state of affairs for Go and computing in general. Yikes!
>
> Just want to see what others are thinking.
>
> --
> 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/0913f098-700a-443f-bd02-2db7ad2408a6n%40googlegroups.com
> 
> .
>


-- 

  T o mM i t c h e l l  ( o n   N i f t y E g g )

-- 
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/CAAMy4URdwaqo-AF5-qZAS6GFEod8AF54X5uDBVAX%2BaeeTYCJBQ%40mail.gmail.com.

Re: [go-nuts] Go and GPUs

[Robert Engels]

Why not develop a Go <> CUDA binding using CGo?

> On Jun 25, 2021, at 12:11 PM, Marcin Romaszewicz  wrote:
> 
> 
> Graphics chips have a lot of proprietary IP, some of which the manufacturers 
> would like to keep secret. If you see source for one of these drivers, you 
> will have a good idea about the hardware organization, so they keep 
> everything secret. It stinks for us developers who want to write cross 
> platform open source. The best bet right now, in my opinion, is to write CGO 
> wrappers around platform native libraries, and sadly, they'll only work on 
> some OS/hardware combinations.
> 
> 
>> On Fri, Jun 25, 2021 at 8:53 AM Nikolay Dubina 
>>  wrote:
>> I tried to write down my own CUDA / NVIDIA GPU driver in native Go last 
>> weekend. To my great surprise, CUDA and pretty much all high performance 
>> software/hardware from NVIDIA is proprietary close-source C/C++ code. 
>> Meaning, you can't write native Go driver even if you wanted to. Forget Go, 
>> people are trying to reverse engineer it in C/C++ with limited success. From 
>> what I heard OpenCV is not a priority for NVIDIA either. Then I looked up 
>> what Apple is doing with their Neural Engine in latest chips. It too is 
>> closed-source Objective-C, Swift. I suspect situation with other powerful 
>> hardware is the same. Moore's law seem to be about GPU lately, and everyone 
>> is locking it in. Kind of not in the spirit open-source and Linux. That's 
>> quite bad state of affairs for Go and computing in general. Yikes!
>> 
>> Just want to see what others are thinking.
>> -- 
>> 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/0913f098-700a-443f-bd02-2db7ad2408a6n%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%2Bv29LvH8eZqX8ASryOgBexMVUUyDO%2BTQFtaxz8Y-EDi92hkEA%40mail.gmail.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/3D3DA44D-BEA2-4D05-9484-C2B9A573ED45%40ix.netcom.com.

[go-nuts] Recomended GOPROXY (or not) for Open Source projects?

[josvazg]

When working on internal company projects, it makes sense to use a company 
wide GO Proxy assuring that all go dependency code is available and 
immutable. But when you move to an Open Source project, you cannot longer 
use such private proxy.

I wonder what is the best practice recommendation for Open Source projects.

For instance, reading about https://proxy.golang.org/ is says:
> Why did a previously available module become unavailable in the mirror? 

> proxy.golang.org  does not save all modules 
forever. 

Which means, your project may *not compile* anymore if someone pulls one of 
your dependencies and proxy.golang.org decides to drop it.

When you read that, you may decide to just track the vendor/ folder in your 
repo and forget about proxies for OSS projects.

What is the recommendation from the Go community about this?

- Are there public go proxies can be used for OSS projects ensuring you 
will never lose any dependency?

- Is https://goproxy.io/ giving such guarantee maybe?

- Should we just vendor and forget about Go-Proxies for Open Source?

Thanks,

Jose

-- 
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/47c445ca-884d-49b5-8357-aeae8802e937n%40googlegroups.com.

Re: [go-nuts] Go and GPUs

[Marcin Romaszewicz]

Graphics chips have a lot of proprietary IP, some of which the
manufacturers would like to keep secret. If you see source for one of these
drivers, you will have a good idea about the hardware organization, so they
keep everything secret. It stinks for us developers who want to write cross
platform open source. The best bet right now, in my opinion, is to write
CGO wrappers around platform native libraries, and sadly, they'll only work
on some OS/hardware combinations.


On Fri, Jun 25, 2021 at 8:53 AM Nikolay Dubina 
wrote:

> I tried to write down my own CUDA / NVIDIA GPU driver in native Go last
> weekend. To my great surprise, CUDA and pretty much all high performance
> software/hardware from NVIDIA is proprietary close-source C/C++ code.
> Meaning, you can't write native Go driver even if you wanted to. Forget Go,
> people are trying to reverse engineer it in C/C++ with limited success.
> From what I heard OpenCV is not a priority for NVIDIA either. Then I looked
> up what Apple is doing with their Neural Engine in latest chips. It too is
> closed-source Objective-C, Swift. I suspect situation with other powerful
> hardware is the same. Moore's law seem to be about GPU lately, and everyone
> is locking it in. Kind of not in the spirit open-source and Linux. That's
> quite bad state of affairs for Go and computing in general. Yikes!
>
> Just want to see what others are thinking.
>
> --
> 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/0913f098-700a-443f-bd02-2db7ad2408a6n%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%2Bv29LvH8eZqX8ASryOgBexMVUUyDO%2BTQFtaxz8Y-EDi92hkEA%40mail.gmail.com.

[go-nuts] Linter for immutable structure

[Vitalii Solodilov]

I have an immutable structure. It contains methods that create a new copy, 
modify and return it.
Are there any linters that can verify that the result of the methods will 
be assigned to a variable or returned from a function? I can manually 
specify a list of the methods.
For example, the linter will detect the following 
cases: https://play.golang.org/p/Aje-DeWBnKd

-- 
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/7a0bdf53-e2fe-4598-a800-3fece84b0687n%40googlegroups.com.

[go-nuts] Go and GPUs

[Nikolay Dubina]

I tried to write down my own CUDA / NVIDIA GPU driver in native Go last 
weekend. To my great surprise, CUDA and pretty much all high performance 
software/hardware from NVIDIA is proprietary close-source C/C++ code. 
Meaning, you can't write native Go driver even if you wanted to. Forget Go, 
people are trying to reverse engineer it in C/C++ with limited success. 
>From what I heard OpenCV is not a priority for NVIDIA either. Then I looked 
up what Apple is doing with their Neural Engine in latest chips. It too is 
closed-source Objective-C, Swift. I suspect situation with other powerful 
hardware is the same. Moore's law seem to be about GPU lately, and everyone 
is locking it in. Kind of not in the spirit open-source and Linux. That's 
quite bad state of affairs for Go and computing in general. Yikes!

Just want to see what others are thinking.

-- 
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/0913f098-700a-443f-bd02-2db7ad2408a6n%40googlegroups.com.

[go-nuts] How to make a client auto reconnect back to the server

[LetGo]

I'm trying to write a client  which will be then cross-compiled for both 
win - linux. If for any reason appears something like a wild gandalf saying 
"you shall not pass" killing the connection, I need it to reconnect back to 
the server.

So far I almost achived it. When launched for the first time, it tries to 
connect to the server ( I'm using ncat ) each 3 seconds until it succeeds.

[image: 1.png]

But if the connection is lost, I need it to auto-reconnect back to the 
server. For now, I made it work just if I enter some kind of input from the 
client after it gets a RST.



[image: 2.png]


The code:

// Socket Client

func (nObj NetObject) RunClient(cmd string) {

// Try connection



for {

conn, err := net.Dial(nObj.Type, nObj.Service)

fmt.Print("connect")

if err != nil {

fmt.Println("fail")

}else{

fmt.Println("ok")

defer conn.Close() 

log.Println("Connected to", conn.RemoteAddr())

handleConn(conn, cmd)

if conn != nil {

   fmt.Println("fail again ")

}

// log.Println("Broken pipe")

   } 

  time.Sleep(5 * time.Second)

}


}

---

func handleConn(conn net.Conn, binPath string) {

if binPath != "" {

// Execute command and send Standard I/O net.Conn

cmd := exec.Command(binPath)

cmd.Stdin = conn

cmd.Stdout = conn

cmd.Stderr = conn

cmd.Run()

} else {

// Copy Standard I/O in a net.Conn

go io.Copy(os.Stderr, conn)

go io.Copy(os.Stdout, conn)

io.Copy(conn, os.Stdin)

}

}




Can you please help me fixing the code? Would be AWESOME!

Theory is nice, but is a partial solution if not followed by code. Code 
helps understand better what the problem is and how the solution looks like.

-- 
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/1182fbb7-68c0-4920-b017-75a09a00f0ccn%40googlegroups.com.

Re: [go-nuts] Re: Error when running llvm-goc

['Than McIntosh' via golang-nuts]

Hello again,

Couple of things.

First, it is important to keep in mind that the "llvm-goc" binary is not
intended to be used as a top level go compiler, in the same way that the
"gcc" or "clang" commands are used as top-level C/C++ compilers. The normal
use case is to use "go build" as opposed to invoking llvm-goc directly.
Just to recap: build the 'install-gollvm' ninja target (as described in
https://go.googlesource.com/gollvm/#installing), prepend the install dir
"bin" directory in your path, and then run "go build".

It's also problematic to run llvm-goc directly out of the build area
instead of doing and install and using the copy in the install dir. For
example, if I do a build of llvm-goc in my LLVM build area, then invoke it
directly on a small Go program, this is what I see:

$ ./bin/llvm-goc smallmain.go
/usr/bin/ld.gold: error: cannot find -lgobegin
/usr/bin/ld.gold: error: cannot find -lgo
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o:function
_start: error: undefined reference to 'main'
:1: error: undefined reference to
'runtime.registerTypeDescriptors'
smallmain.go:4: error: undefined reference to 'runtime.printlock'
smallmain.go:4: error: undefined reference to 'runtime.printint'
smallmain.go:4: error: undefined reference to 'runtime.printnl'
smallmain.go:4: error: undefined reference to 'runtime.printunlock'
$

Here the compiler is unable to find the right runtime libraries. I'll see
if I can update the documentation to make this a little clearer.

Regarding the crash you're seeing when building from

 LLVM: 43ff75f2c3feef64f9d73328230d34dac8832a91
gollvm: 44a7a475cfd3b871b7a5a0941b8ab1ea9d489adc
gofrontend: be0d2cc2df9f98d967c242594838f86362dae2e7
libbacktrace: 5a99ff7fed66b8ea8f09c9805c138524a7035ece
libffi: 737d4faa00d681b4c758057f67e1a02d813d01c2


Sorry, but I can't reproduce your crash (I did another build using the
config above and it seems to work ok). What is the exact cmake command
you're using to set up your build area?

You might also try this: in your LLVM build area, run "ninja
llvm-symbolizer" and then set

export LLVM_SYMBOLIZER=${HERE}/bin/llvm-symbolizer

then rerun the failing "llvm-goc" invocation, that might give you a better
stack trace.

Thanks, Than



On Thu, Jun 24, 2021 at 2:53 PM Kavindu Gimhan Zoysa 
wrote:

> I did not use any *go build* command. Sorry if I missed anything. These
> are the steps I followed.
>
> 1. Build gollvm referring to the official documentation. I followed the
> steps until https://go.googlesource.com/gollvm/#cmakeninja.
> 2. I was able to see the *llvm-goc *in the bin folder.  I export the path
> using '*export
> LD_LIBRARY_PATH=/build-debug/libgo/x86_64-unknown-linux-gnu' *
> command.
> 3. Then I tried to dump the llvm IR using '*../bin/llvm-goc -S test.go
> -dump-ir', *and it was successful.
> 4. Then I ran this command '*./bin/llvm-goc test.go'*. I got the above
> error.
>
> Did i miss anything?
>
> Thank you,
> Kavindu
> On Friday, 25 June 2021 at 00:01:41 UTC+5:30 th...@google.com wrote:
>
>> Could you please post the complete "go build" command?
>>
>> Thanks, Than
>>
>> On Thu, Jun 24, 2021 at 2:05 PM Kavindu Gimhan Zoysa 
>> wrote:
>>
>>> Hi all,
>>>
>>> Still, I was unable to figure out the reason for the above error. Really
>>> appreciate your help.
>>>
>>> Thank you,
>>> Kavindu
>>>
>>> On Thursday, 24 June 2021 at 12:06:32 UTC+5:30 Kavindu Gimhan Zoysa
>>> wrote:
>>>
 Hi all,

 I have build the gollvm and now I am trying to run it. So I run
 follwing command against a simple go source code. I am getting below error.
 Really appreciate your input to solve this issue.

 command :
 *./bin/llvm-goc test.go*

 error:
 *llvm-goc:
 /home/kavindu/GIT/llvm-project/llvm/tools/gollvm/driver/Action.cpp:51:
 const char* gollvm::driver::Action::resultFileSuffix() const: Assertion
 `false' failed.*
 *../bin/llvm-goc(+0x2c46a3f)[0x55a113e42a3f]*
 *../bin/llvm-goc(+0x2c46ad6)[0x55a113e42ad6]*
 *../bin/llvm-goc(+0x2c44829)[0x55a113e40829]*
 *../bin/llvm-goc(+0x2c46387)[0x55a113e42387]*
 */lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f67e0aad3c0]*
 */lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f67e056818b]*
 */lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f67e0547859]*
 */lib/x86_64-linux-gnu/libc.so.6(+0x25729)[0x7f67e0547729]*
 */lib/x86_64-linux-gnu/libc.so.6(+0x36f36)[0x7f67e0558f36]*
 *../bin/llvm-goc(+0x827e69)[0x55a111a23e69]*
 *../bin/llvm-goc(+0x8167d5)[0x55a111a127d5]*
 *../bin/llvm-goc(+0x81db02)[0x55a111a19b02]*
 *../bin/llvm-goc(+0x81ddfb)[0x55a111a19dfb]*
 *../bin/llvm-goc(+0x811cb9)[0x55a111a0dcb9]*

 */lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f67e05490b3]*
 *../bin/llvm-goc(+0x81112e)[0x55a111a0d12e]*
 *PLEASE submit a bug report to https://bugs.llvm.org/
  and include the crash backtrace.*
 *Stack dump:*
 *0. Program 

[go-nuts] Re: UML && Golang

[Vitaly]

https://www.dumels.com/

пятница, 25 июня 2021 г. в 14:32:32 UTC+5, alex-coder: 

> Hi All !
>
> I can't find an IDE that has a conversion tool from Golang code to uml 
> diagrams. 
> I will be very grateful for the link to.
> You see, the picture is worth a thousand words :-).
>
> Thank you.
>

-- 
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/486b41ec-8f5a-4260-9125-dfd25ccce87cn%40googlegroups.com.

[go-nuts] UML && Golang

[alex-coder]

Hi All !

I can't find an IDE that has a conversion tool from Golang code to uml 
diagrams. 
I will be very grateful for the link to.
You see, the picture is worth a thousand words :-).

Thank you.

-- 
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/25b47822-0a80-4dcd-983b-00460b3b5e4an%40googlegroups.com.

[go-nuts] how to purge invalid tags from GOPROXY?

[Sebastien Binet]

hi there,

I've forked a fork of a Go package (github.com/jung-kurt/gofpdf).
But as the modus operandi of such a thing is rather unwieldy in github
(PRs would always be created by default against the original package
instead of my fork), I've deleted the forked repo, created a new repo
with the same name and pushed the original git tree there.

so now, my PRs are, by default against my fork, which is great.

unfortunately, I've also decided that my fork would start at v0.1.0
(what would be the last commit from the old gofpdf package) while the
original package was at v1.4.2

and it seems GOPROXY cached it somehow:

$> docker run --rm -it golang
root@clrinfopc42:/go# cd src/
root@clrinfopc42:/go/src# mkdir foo
root@clrinfopc42:/go/src# cd foo/
root@clrinfopc42:/go/src/foo# go mod init foo
go: creating new go.mod: module foo
root@clrinfopc42:/go/src/foo# go version
go version go1.16.5 linux/amd64
root@clrinfopc42:/go/src/foo# cat >> go.mod

require github.com/go-pdf/fpdf v0.3.1
^C
root@clrinfopc42:/go/src/foo# cat >> main.go
package main

import _ "github.com/go-pdf/fpdf"

func main() {}
^C

root@clrinfopc42:/go/src/foo# go mod tidy
go: downloading github.com/go-pdf/fpdf v0.3.1

root@clrinfopc42:/go/src/foo# go build -v
github.com/go-pdf/fpdf
foo

root@clrinfopc42:/go/src/foo# go get -u -v github.com/go-pdf/fpdf@latest
go: downloading github.com/go-pdf/fpdf v1.4.2
go get: github.com/go-pdf/fpdf@v0.3.1 updating to
github.com/go-pdf/fpdf@v1.4.2: parsing go.mod:
module declares its path as: github.com/phpdave11/gofpdf
but was required as: github.com/go-pdf/fpdf

root@clrinfopc42:/go/src/foo# go get -x -u -v github.com/go-pdf/fpdf@latest
# get https://proxy.golang.org/github.com/@v/list
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/list
# get https://proxy.golang.org/github.com/go-pdf/@v/list
# get https://proxy.golang.org/github.com/@v/list: 410 Gone (0.107s)
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/list: 200 OK (0.107s)
# get https://proxy.golang.org/github.com/go-pdf/@v/list: 410 Gone (0.107s)
go get: github.com/go-pdf/fpdf@v0.3.1 updating to
github.com/go-pdf/fpdf@v1.4.2: parsing go.mod:
module declares its path as: github.com/phpdave11/gofpdf
but was required as: github.com/go-pdf/fpdf

of course, it works if I give the explicit new tag of go-pdf/fpdf:

root@clrinfopc42:/go/src/foo# go get -u -v github.com/go-pdf/fpdf@v0.4.0
# get https://proxy.golang.org/github.com/@v/v0.4.0.info
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/v0.4.0.info
# get https://proxy.golang.org/github.com/go-pdf/@v/v0.4.0.info
# get https://proxy.golang.org/github.com/@v/v0.4.0.info: 410 Gone (0.223s)
# get https://proxy.golang.org/github.com/go-pdf/@v/v0.4.0.info: 410 Gone 
(0.223s)
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/v0.4.0.info: 200 OK 
(0.226s)
go: downloading github.com/go-pdf/fpdf v0.4.0
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/v0.4.0.zip
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/v0.4.0.zip: 200 OK 
(0.370s)
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/list
# get https://proxy.golang.org/github.com/go-pdf/fpdf/@v/list: 200 OK (0.029s)
[...]
go get: upgraded github.com/go-pdf/fpdf v0.3.1 => v0.4.0


any idea how one could purge the tags (coming from {jung-kurt,phpdave11}/gofpdf?
I understand that comes a bit at odds with the way the GOPROXY ledger is
supposed to work though...

any idea on how to work around that?
thanks.

cheers,
-s

-- 
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/CCCK5I3B9536.1RAC82P987RAU%40zoidberg.

Re: [go-nuts] Upgrade to Go1.16 from Go1.14 broke my query

[Roland Müller]

Hello,

Am Do., 24. Juni 2021 um 18:14 Uhr schrieb Hugh Myrie :

> I recently updated my Go version to 1.16 and for all my queries I now get
> an error:
>
> {"error":"Dynamic SQL Error\nSQL error code = -303\narithmetic exception,
> numeric overflow, or string truncation\nstring right truncation\n"}
>
> I'm using  the package:   _ "github.com/nakagami/firebirdsql"
>
> The following is a simple function:
>
> func getSystem(w http.ResponseWriter, r *http.Request) {
> type system struct {
> Tax1float64  `json:"tax1"`
> Fees1  float64  `json:"fees1"`
> Fees2   float64  `json:"fees2"`
> Minus_stk string `json:"minus_stk"`
> Discount1 float64 `json:"discount1"`
> Discount2 float64 `json:"discount2"`
> Discount3 float64 `json:"discount3"`
> Discount4 float64 `json:"discount4"`
> Elderly float64 `json:"elderly"`
> Message NullString `json:"message"`
> Binary4 NullString `json:"binary4"`
> }
> sysdata := []system{}
> sql2 := "select tax1, fees1, fees2, minus_stk, discount1, discount2,
> discount3, discount4, elderly, cast(mesg as varchar(400)), binary4 from
> system"
> conn, _ := sql.Open("firebirdsql",  datapath)
> defer conn.Close()
> rows, err := conn.Query(sql2)
> if err != nil {
> respondWithError(w, http.StatusBadRequest, err.Error())
> return
> }
> defer rows.Close()
> for rows.Next() {
> var p system
> err := rows.Scan(, , , _stk, ,
> , , , , ,
> )
> if err != nil {
> respondWithError(w, http.StatusBadRequest, err.Error())
> return
> }
> sysdata = append(sysdata, p)
> }
> err = rows.Err()  //  <--- errors seem to thrown here.
> if err != nil {
> respondWithError(w, http.StatusBadRequest, err.Error())
> return
> }
> respondWithJSON(w, http.StatusOK, sysdata)
> }
>
> Your help would be appreciated.
>
> I'm using Firebird 2.5. Everything worked under the previous version of
> Go. I am scanning for null values so I don't believe that is the issue.
>
> ust a wild guess not "biased" by any close knowledge of Firebird DB or the
above mentioned Go module: there has something changed with handling of
rows.Next() when the last row of data has been passed. This guess is based
on the fact that your mark the error only occurs after reading all data
rows.

I would try to log a warning to server log and try to return the JSON data
instead of returning http.StatusBadRequest. It may be that the data is
valid.

BR,
Roland

-- 
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%2B8p0G0RaDFSysB6RXTj0DP4MQQKuvO82boU64%3D-LAgKUeYeCQ%40mail.gmail.com.