Re: [go-nuts] Obtaining compiled module information at run time

[Maxim Khitrov]

Ha! Yes, that looks exactly like what I needed. Thanks for the tip!

-Max

On Mon, Jan 21, 2019 at 11:44 AM roger peppe  wrote:
>
> Perhaps you were looking for this, which will be available in the upcoming
> go1.12 release?
>
> https://tip.golang.org/pkg/runtime/debug/#ReadBuildInfo
>
> On Mon, 21 Jan 2019 at 02:50, Maxim Khitrov  wrote:
>>
>> I was working on a tool that needed to know the file system paths and
>> version information of some of its dependencies from go.mod for code
>> generation. I couldn't find any official way of obtaining these
>> (debug/gosym was close, but didn't work for the current binary on any
>> OS), so I wrote this package:
>>
>> https://github.com/mxk/go-gomod
>>
>> It's basically a hack that looks through all file name strings used
>> for stack traces in the current binary, identifies those containing
>> "@v", and extracts root directory and version information from there.
>>
>> This got me thinking whether there should be a more general (and
>> unsafe-free) way of obtaining module information at run time. 'go
>> list' command defines a Module struct containing pretty much all
>> information one might want. Would it make sense to compile this
>> metadata into the binary (if not already done) and expose it via the
>> runtime package?
>>
>> -Max
>>
>> --
>> 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] Obtaining compiled module information at run time

[Maxim Khitrov]

I was working on a tool that needed to know the file system paths and
version information of some of its dependencies from go.mod for code
generation. I couldn't find any official way of obtaining these
(debug/gosym was close, but didn't work for the current binary on any
OS), so I wrote this package:

https://github.com/mxk/go-gomod

It's basically a hack that looks through all file name strings used
for stack traces in the current binary, identifies those containing
"@v", and extracts root directory and version information from there.

This got me thinking whether there should be a more general (and
unsafe-free) way of obtaining module information at run time. 'go
list' command defines a Module struct containing pretty much all
information one might want. Would it make sense to compile this
metadata into the binary (if not already done) and expose it via the
runtime package?

-Max

-- 
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] Performance difference between named and literal stack variables

[Maxim Khitrov]

I'm curious about why go 1.11 compiler is doing different things for
functions f1 and f2 in the following example:

type T [512]byte

//go:noinline
func use(*T) {}

func f1() {
   s := T{}
   use()
}

func f2() {
   use({})
}

T{} stays on the stack in both cases according to -gcflags=-m, but
benchmarking shows f1 to be almost twice as fast as f2. Looking at the
disassembly, f2 contains two DUFFZERO instructions, which I'm guessing
is what accounts for the performance difference. Why isn't the
compiler generating identical code here?

-Max

-- 
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] Go 1.11 module cache not safe for concurrent use?

[Maxim Khitrov]

I'm running into non-deterministic errors when I try to build multiple
binaries from the same module with goreleaser in a CI/CD system. Here
are some examples:

go: finding github.com/pkg/browser v0.0.0-20170505125900-c90ca0c84f15
go: github.com/pkg/browser@v0.0.0-20170505125900-c90ca0c84f15: git
fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in
/go/pkg/mod/cache/vcs/8755ee3fe34afbf0e42bd94de4ff233c0a12a60e9ddcc7a72c38f16620d3eebf:
chdir 
/go/pkg/mod/cache/vcs/8755ee3fe34afbf0e42bd94de4ff233c0a12a60e9ddcc7a72c38f16620d3eebf:
no such file or directory

go: github.com/davecgh/go-spew@v1.1.1: git remote add origin
https://github.com/davecgh/go-spew in
/go/pkg/mod/cache/vcs/b9a4b9bbdb4a59723f2348415ad7ffda91568455a1cfd92e97976132bdfbaf57:
exit status 128:
fatal: remote origin already exists.

go: github.com/pmezard/go-difflib@v1.0.0: unknown revision v1.0.0

go: error loading module requirements

If I run 'go mod download' before the build, everything works fine, so
I believe that this problem is caused by goreleaser starting multiple
parallel builds with an empty module cache. I've tested this several
times now by removing pkg/mod and GOCACHE directories.

My question is whether it should be possible to do so or if this is
just a known limitation of how the module cache works? The following
issue suggests that GOCACHE is safe for concurrent use, but I couldn't
find information on the module cache:

https://github.com/golang/go/issues/26677

-Max

-- 
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] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

[Maxim Khitrov]

I didn't have anything specific in mind, just curious about what is
possible and how much work is required. Sounds like it's something
I'll probably avoid for now. Thanks for the API and info about adding
special commands!

I can't offer much feedback about Mozilla Public License because it's
not one that my company has vetted. To me, it seems more
commercial-friendly than [L]GPL, but IANAL.

On Sun, Apr 29, 2018 at 9:52 AM, Max <massimiliano.ghila...@gmail.com> wrote:
> About the "other languages extensions":
>
> it's obviously easier than modifying the official Go compiler, but it's
> usually still a major task,
> especially if it involves modifying the "poor man's compiler" fast.Comp
> which converts a parsed ast.Node into a tree of function closures for
> execution.
>
> If you have a specific example in mind and you describe it, I can be more
> specific.
>
> On Saturday, April 28, 2018 at 11:59:41 PM UTC+2, Maxim Khitrov wrote:
>>
>> Do you have examples of adding custom ":xyz" or other language extensions?

-- 
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] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

[Maxim Khitrov]

Do you have examples of adding custom ":xyz" or other language extensions?

Also, are you still deciding what to do with the license (I see there
is an open issue about it)? I was thinking of using gomacro for an
internal project at work, but use of LGPL libraries is not allowed,
unfortunately.

On Fri, Apr 27, 2018 at 1:33 PM, Max  wrote:
>
> website: https://github.com/cosmos72/gomacro
> install: go get github.com/cosmos72/gomacro
>
> At version 2.6, gomacro has almost complete Go language support, including
> import of third-party libraries (easy on Linux, requires a recompiling on
> other platforms),
> declaring new interface types and implementing them.
>
> Extensions with respect to compiled Go:
> * integrated debugger, see https://github.com/cosmos72/gomacro#debugger
> * untyped constants can be manipulated directly at prompt, providing a handy
> arbitrary precision calculator. Example:
>   ```
>   const c = 1<<1000
>   c + 1<<500 * 1<<200
>   ```
> * implicit conversion from untyped constants to *big.Int, *big.Rat and
> *big.Float. Example:
>   ```
>   import "math/big"
>   var i *big.Int = 1<<1000
>   var r *big.Rat = 1.01
>   var f *big.Float = 1e123456
>   ```
>
> Currently missing features:
> * out-of-order code is not supported: symbols must be declared before using
> them.
> * some rarely used corner cases with interpreted interfaces are not
> implemented
>
> For a graphical front-end, see https://github.com/gopherdata/gophernotes,
> the Go kernel for Jupyter notebooks and nteract (uses a slightly older
> version of gomacro).
>
> As usual, feedback is welcome :)
>
> Max
>
> --
> 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] pure-Go MATLAB file I/O package ?

[Maxim Khitrov]

Maybe you already know this, but that PDF seems to cover the format
that was used by MATLAB Version 5 (R8). Versions since R2006b use an
HDF5-based format:

https://www.mathworks.com/help/matlab/import_export/mat-file-versions.html

Unless you only need to work with the old format, you should look for
an HDF5 implementation in Go. I only found bindings for the C library.

-Max

On Thu, Jul 7, 2016 at 5:27 AM, Seb Binet  wrote:
> hi there,
>
> before I go ahead and implement it, has anyone released a pure-Go read/write
> package for MATLAB files ?
>
> https://www.mathworks.com/help/pdf_doc/matlab/matfile_format.pdf
>
> I've found:
>  https://github.com/ready-steady/mat
>
> but that package is actually using the C-API exposed by a MATLAB
> installation...

-- 
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.