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
>
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.
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
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,
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
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
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
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.
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
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
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
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
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
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,
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
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
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.
>
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.
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
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
20 matches
Mail list logo
