should be: "i can't get it to work", instead of "i can get it to work",
sadly enough
On Sunday, June 7, 2020 at 3:20:40 PM UTC+2, Erwin Driessens wrote:
>
> Hello people
> i have always found modules very scary and complicated but now there seems
> to be no
Hello people
i have always found modules very scary and complicated but now there seems
to be no way round any longer.
I have a lot of packages that i do now want to put in repositories. I want
them to be locally accessible, without internet access.
Everything always worked great for me with the
i wish the the blender GUI would be made stand-alone, ready to port to
Go... so clean and fast!
--
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+unsub
bravo!
--
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 could let your application generate valid Go source, call the compiler
to build a plugin, and load that plugin. I haven't tried that yet, but i
think it should work. Downside is that you need to Go tools on the target
machine for it to work. I don't know how many times you have to generate
When I 'go test -bench . -benchmem', I sometimes see small numbers reported
in allocs/op that I can't spot in the code for the function that was
benchmarked. For example,
the following function:
func Mul_c(m1, m2, m3 *Matrix) {
// validate
r1, c1 := m1.Dim()
r2, c2 := m2.Dim()
r3, c3 := m3.Dim(
I'd love to see SIMD intrinsics in the Go compiler(s), even if it would
mean separate packages for all the architectures. I'm not experienced
enough to tell how far one could get with designing a cross-platform set of
intrinsics instructions? Using the hardware when it is available, falling
bac
