Re: [go-nuts] An important proposal will fail without your support

2020-03-12 Thread Jon Perryman 
On Wed, Mar 11, 2020 at 12:23 AM Levieux Michel  wrote
> It seems you missed something here. "Please like my proposal or everyone
loses" is not an argument.

No one has debated the power, importance and virtues of my proposal.
Apparently you didn't read the comments in the proposal. The discussion is
about why they can't be bothered. Maybe enough likes would motivate a
discussion of the merits instead of perceived risks that apparently can't
be solved by a good developer.

On Wed, Feb 19, 2020 at 9:17 AM Robert Griesemer 
wrote:
> An integrated compile-time language makes a compiler essentially
programmable;
> there's no question that this would be very powerful.

This comment is from the proposal. Not one person has disagreed with "very
powerful". If you disagree, please say why? How is this not far more
powerful than GO GENERATE, pre-processors and macro's?

Why isn't a very powerful feature important to everyone? Shouldn't the
compiler developers spend more than 5 minutes consideration on very
powerful features before they dismiss them? Isn't this proposal worth a
"like" just to consider if it's possible?

This proposal is failing because of fear that we will repeat the mistakes
of the past. Great developer's will ask how a powerful feature can be made
safe in their product instead of finding excuses not to consider it.
"liking" a proposal doesn't mean it will be implemented. Instead, it tells
developer's  it's important to you and try to find a way to implement that
feature.

On Wed, Feb 19, 2020 at 9:17 AM Robert Griesemer 
wrote:
 >  It's unclear to me how flexible an approach you are envisioning.

My vision doesn't matter. This must be a team vision. I have a lot of
experience with this so I know what works and what fails. I know how to
address many of the fears mentioned.

On Tue, Feb 25, 2020 at 2:57 PM Ian Lance Taylor 
wrote:
> This proposal is incomplete

Robert put the proposal best: make GO programmable at compile time.
Everything else in the proposal demonstrates possibilities and justifies
the value of the proposal. Anything beyond this is a waste of my time at
this point.

> I made a similar proposal at #32620
,   hygienic macros

Not similar and this should not be allowed. The only part of the AST
affected would be the #xxx( xxx ) which would be replaced with the
generated code.

> turing complete

These issues have been addressed in other compilers. These issues can be
addressed.

> because they slow down the compile times,

Compile time is not affected if #xxx( xxx ) is not used in the code. Does
GO GENERATE or pre-processors save compile time by reading the source
twice? Are they able to produce results as a programmable GO?

> do not follow the simplicity and design goals of Go

Why  is this impossible to be part of the requirements?

> Choose a compile time language. Possibly GO, Python, Java, NodeJS or??),which
is a bad idea for a variety of reasons.

I'm not saying user's have a choice. I'm saying this is a decision to be
made during requirements or design phase.

> What this proposal describes is a language that is very different from Go.


If the language chosen is GO, then it's not different. It could be a brand
new minimal language that is similar to GO. This is a decision to be
discussed.

> It's even more unlikely that that language would be one as powerful

Why would you want a powerful language at compile time. You're not reading
files, using goroutines or most other functionality used at run time.

> It looks like what you want is something like constexpr in C++.

Constexpr is useless for solving complex problems at compile time (e.g.
gettext). It's amazing how a poorly designed feature get's abused because
the language does not meet our needs.

> the args can't be evaluated at compile time

At compile time, everything is a constant. The compiler breaks down #xxx(
yyy ) as constants into AST's. When #xxx is called, the AST's are made
available to the function as ARGS.

> I used make and awk programs that generate assembly code tuned
> to the exact demands of command line make configuration. Then it builds
in go, then runs.

I want consistency for everyone, available with GO and easy to use. I'm
sure this worked for you but compile time does not need to be complex.
Simplicity is your friend.

Thanks, Jon.

-- 
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/CAByJhJn584h2AM_kRr8eZaGShfu-FjKxgBwCWpL-Cq11t79svQ%40mail.gmail.com.

Re: [go-nuts] Is this code in package unix assuming machine endianess?

2020-03-12 Thread Robert Engels 
No disrespect to Rob but it’s a bit more complex than that. Almost certainly 
the code was older and written in C and it used fixed length linked records, so 
back when machines were a lot slower it was far more efficient to point to the 
start of a struct in memory and read/write directly - they weren’t streams. 
Software was usually written for Windows only - ie. Intel (or in rare cases Mac 
for Photoshop and Motorola). 

Only later when seeking greater revenues or interoperability was the software 
ported and when doing this (at minimum cost) required keeping the code nearly 
the same and certainly the file formats the same, you ended up with ifdefs. 

> On Mar 12, 2020, at 5:10 AM, Tom Parkin  wrote:
> 
> 
> Thanks Rob, that was an interesting read.
> 
> I think your pattern is good, and makes perfect sense when you think about 
> it.  It occurred to me when reading that another way of thinking about the 
> pattern is that you're coding to the endianess of the byte stream, and 
> letting the layout of the type in memory be sorted out by the compiler 
> writers, which seems like a reasonable separation of concerns.
> 
> What threw me off the scent somewhat, as someone coming from a C background, 
> is that the code I pointed to superficially resembles the sort of thing you 
> mentioned in your article.  Perhaps even more so as it's taking a uint16 
> value, treating it as a byte array, and then reassembling the byte array into 
> a uint16.  And once your brain has said "aha, byte swapping", its difficult 
> to think outside that box.
> 
> Ah well, TIL, etc, etc.  Thanks again for the link :-)
> 
>> On Thu, 12 Mar 2020 at 01:33, Rob Pike  wrote:
>> More context, in the form of self-promotion: 
>> https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html
>> 
>> -rob
>> 
>> 
>>> On Wed, Mar 11, 2020 at 9:42 PM Tom Parkin  wrote:
 On Tue, 10 Mar 2020 at 23:14, Ian Lance Taylor  wrote:
 On Tue, Mar 10, 2020 at 4:03 PM Tom Parkin  wrote:
 >
 > I'm working on adding a new Linux socket type (L2TPIP) to the unix 
 > package, and I noticed some code in there that appears on the face of it 
 > to be assuming the endianess of the host.  The #networking channel on 
 > the Gophers slack suggested I raise the question here.
 >
 > The code I am struggling with is in this file:
 >
 > https://github.com/golang/sys/blob/master/unix/syscall_linux.go
 >
 > So far as I can make out, this code implements a variety of system calls 
 > for Linux generally, irrespective of GOARCH.
 >
 > In this file, there is a function anyToSockaddr which serves to convert 
 > struct sockaddr from system calls such as getsockname(2) and accept4(2) 
 > into Go representations of the various sockaddr types, for example 
 > unix.SockaddrUnix and unix.SockaddrInet4.  The function anyToSockaddr 
 > switches on the address family in the struct sockaddr, and then converts 
 > based on that.
 >
 > I noticed for the AF_INET case in the switch statement of anyToSockaddr 
 > that the struct sockaddr_in sin_port field is being unconditionally 
 > byte-swapped during conversion:
 >
 > pp := (*RawSockaddrInet4)(unsafe.Pointer(rsa))
 > sa := new(SockaddrInet4)
 > p := (*[2]byte)(unsafe.Pointer())
 > sa.Port = int(p[0])<<8 + int(p[1])
 > for i := 0; i < len(sa.Addr); i++ {
 > sa.Addr[i] = pp.Addr[i]
 > }
 > return sa, nil
 >
 > (where 'rsa' is a pointer to a RawSockaddrAny).
 >
 > Now, ip(7) states of the struct sockaddr_in structure:
 >
 >   "Note that the address and the port are always stored in network byte 
 > order.  In particular, this means that you need to call htons(3) on the 
 > number that is assigned to a port."
 >
 > So the byte swapping that anyToSockaddr is doing makes sense, but only 
 > if the host is a little-endian machine.  It seems as though this code 
 > would do the wrong thing on a big-endian machine.
 >
 > Can anyone suggest what I'm missing here?  Is this code really assuming 
 > that the host is a little-endian machine?
 
 This does not look like byte swapping to me.  Here pp.Port should be
 in network byte order.  To set sa.Port we read the first byte of
 pp.Port, left shift by 8, then or in the second byte of pp.Port.  That
 is, we interpret pp.Port as a two-byte big-endian number, and compute
 the value as a 16-bit integer.  That will work regardless of the
 endianness of the host.
>>> 
>>> Thanks Ian for your answer.
>>> 
>>> It took me a little bit of thinking to get there :-( but I see what you're 
>>> saying now.
>>> 
>>> For anyone else playing along at home who may be struggling like I was...
>>> 
>>> By treating the uint16 pp.Port value as an array of bytes, the code can 
>>> access the bytes

Re: [go-nuts] McAfee and the module cache on WSL: rename : permission denied

2020-03-12 Thread Jonathan Reiter 
I don't think McAfee ENS officially supports WSL. At least that was the
case in 2018 when I last tried.

This would probably be evident in its labelling WSL /tmp writes as the
beginnings of an attack - you could always check your scan logs (at
%ProgramData%\McAfee\Endpoint Security\Logs) to see what is actually
happening - if this is a blacklisted directory, a rule firing, or if EDR is
picking up the sketchy behavior.

Feel free to raise a ticket to support on this topic - there's probably an
active community internal to McAfee who would love to get more momentum for
WSL support.

Some potentially dated sources on this topic:
1. ENS log manifest

2. ENS lack of support for WSL

3. A rather interesting article

which spells out why WSL might not be well supported, i.e. it has the
tendency to be used for fileless attack behaviors.

Hope this helps!

-- 
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/CAC41hdON9_x54Fe6Yso8hd97%3DKCQ3Z6GRkfFjkwH6mB-Y5C2pQ%40mail.gmail.com.

Re: [go-nuts] Re: Mem-Leak in Go method

2020-03-12 Thread Michael Jones 
That code looks wrong. I see the end but not the start. Look here and copy
carefully:
https://golang.org/pkg/runtime/pprof/

Call at end, on way out.

Also, as shared by others above, there are no promises about how soon the
dead allocations go away, The speed gets faster and faster version to
version, and is impressive indeed now, so old versions are not the best to
use, ubt even so, if the allocation feels small to th GC the urgency to
free it will be low. You need to loop in allocating and see if the memory
grows and grows.

On Thu, Mar 12, 2020 at 9:22 AM Nitish Saboo 
wrote:

> Hi,
>
> I have compiled my Go binary against go version 'go1.7 linux/amd64'.
> I added the following code change in the main function to get the memory
> profiling of my service
>
> var memprofile = flag.String("memprofile", "", "write memory profile to
> `file`")
>
> func main() {
> flag.Parse()
> if *memprofile != "" {
> f, err := os.Create(*memprofile)
> if err != nil {
> fmt.Println("could not create memory profile: ", err)
> }
> defer f.Close() // error handling omitted for example
> runtime.GC() // get up-to-date statistics
> if err := pprof.WriteHeapProfile(f); err != nil {
> fmt.Println("could not write memory profile: ", err)
> }
> }
> ..
> ..
> (Rest code to follow)
>
> I ran the binary with the following command:
>
> nsaboo@ubuntu:./main -memprofile=mem.prof
>
> After running the service for couple of minutes, I stopped it and got the
> file 'mem.prof'
>
> 1)mem.prof contains the following:
>
> nsaboo@ubuntu:~/Desktop/memprof$ vim mem.prof
>
> heap profile: 0: 0 [0: 0] @ heap/1048576
>
> # runtime.MemStats
> # Alloc = 761184
> # TotalAlloc = 1160960
> # Sys = 3149824
> # Lookups = 10
> # Mallocs = 8358
> # Frees = 1981
> # HeapAlloc = 761184
> # HeapSys = 1802240
> # HeapIdle = 499712
> # HeapInuse = 1302528
> # HeapReleased = 0
> # HeapObjects = 6377
> # Stack = 294912 / 294912
> # MSpan = 22560 / 32768
> # MCache = 2400 / 16384
> # BuckHashSys = 2727
> # NextGC = 4194304
> # PauseNs = [752083 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
> # NumGC = 1
> # DebugGC = false
>
> 2)When I tried to open the file using the following command, it just goes
> into interactive mode and shows nothing
>
> a)Output from go version go1.7 linux/amd64 for mem.prof
>
> nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof mem.prof
> Entering interactive mode (type "help" for commands)
> (pprof) top
> profile is empty
> (pprof)
>
> b)Output from go version go1.12.4 linux/amd64 for mem.prof
>
> nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof mem.prof
> Type: space
> No samples were found with the default sample value type.
> Try "sample_index" command to analyze different sample values.
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) o
>   call_tree = false
>   compact_labels= true
>   cumulative= flat //: [cum | flat]
>   divide_by = 1
>   drop_negative = false
>   edgefraction  = 0.001
>   focus = ""
>   granularity   = functions//: [addresses |
> filefunctions | files | functions | lines]
>   hide  = ""
>   ignore= ""
>   mean  = false
>   nodecount = -1   //: default
>   nodefraction  = 0.005
>   noinlines = false
>   normalize = false
>   output= ""
>   prune_from= ""
>   relative_percentages  = false
>   sample_index  = space//: [objects | space]
>   show  = ""
>   show_from = ""
>   tagfocus  = ""
>   taghide   = ""
>   tagignore = ""
>   tagshow   = ""
>   trim  = true
>   trim_path = ""
>   unit  = minimum
> (pprof) space
> (pprof) sample_index
> (pprof) top
> Showing nodes accounting for 0, 0% of 0 total
>   flat  flat%   sum%cum   cum%
>
>
> 3)Please let me know if it is this the correct way of getting the memory
> profiling ?
>
> 4)Can we deduce something from this memory stats that points us to
> increase in memory usage?
>
> 5)I am just thinking out loud, since I am using go1.7, can that be the
> reason for the issue of increase in memory usage that might get fixed with
> latest go versions ?
>
> Thanks,
> Nitish
>
> On

Re: [go-nuts] Locked and closed issue 30400 but has it resolved the OPS report?

2020-03-12 Thread Ian Lance Taylor 
On Wed, Mar 11, 2020 at 4:20 AM Kevin Chadwick  wrote:
>
> https://github.com/golang/go/issues/30400
>
> It is still not clear without testing for yourself after the commit in the 
> docs
> that "(before umask)" is referring to using os.umask after file creation or 
> the
> executors inherited umask (secure reality).
>
> The referenced Commit:
> "https://github.com/golang/go/commit/4b05dc91b0fe99724721e3545807f3b8f1310c52;

I don't know what you mean by os.umask.  There is no identifier umask
in the os package.

Ian

-- 
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/CAOyqgcX5OqckgRAH-2gepQMGmT7LG%3DyeA%2BqAZyAhbLscB8g_KQ%40mail.gmail.com.

[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly

2020-03-12 Thread Scott Pakin 
On Thursday, March 12, 2020 at 1:14:43 PM UTC-6, howar...@gmail.com wrote:
>
> If the  was off-screen or hidden, couldn't you still reference it to 
> get the data into the canvas like:
>   var img = document.getElementById('targetImg');
>   ctx.drawImage(img, 10, 10);
>
> Might not be the most efficient way, but it seems like it should work.
>

 Yes, that definitely sounds like it's worth a shot.

Thanks,
— Scott

-- 
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/7bb51a2b-bbc8-4c7c-851a-6feaaa5be300%40googlegroups.com.

Re: [go-nuts] SFTPGo: a Golang performance story and some questions

2020-03-12 Thread Nicola Murino 

Il 12/03/20 01:54, Adrian Ratnapala ha scritto:

BTW: Thanks for all this investigation and writeups, they are
interesting, and I look forward to your test results.

Desipte my question, I think using a custom allocator is perfectly
reasonable.  go/issues/23199 is showing us that sync.Pool's interface
isn't great for allocating byte-bufffers (it'd be better to explicitly
ask for objects of a given size). In that sense, a custom allocator
with an appropriate interface is more future-proof.

Hi Adrian,

I did some more tests, you can find some test implementations in my 
branches here:


https://github.com/drakkan/sftp

- allocator branch uses a variable size allocator
- allocator2 branch uses a fixed size allocator with a sync.Pool
- allocator1 branch uses a fixed size allocator: the first commit has an 
implementation very similar to the other ones, in last commit I replaced 
the pagelist with a list of byte array slices


In a single SFTP request more than one allocation could be required, so 
we need to keep track of all the allocations and release them after the 
request is served, so inside the allocator each allocated byte array has 
a reference to the request unique ID.


Based on the benchmarks here:

https://github.com/drakkan/sftp/blob/allocator1/allocator_test.go#L97

allocator1 seems the fastest implementation: both versions (with a 
without the pagelist) are a bit faster than allocator2 that uses the 
sync.Pool. The allocator branch has the slowest implementation.


If you have suggestions for improving my implementations they are welcome!

In a real SFTP test I think the performances of these allocators are 
very similar.


I'll add an interface later, after discussing about the allocation 
strategies with pkg/sftp maintainers,


thanks
Nicola




what I understand reading that issue is that sync.Pool is not the best
choice to store variable-length buffers and my first allocator

I think the problem is that the total memory usage of the pool ends up
O(size of large objects * total numer of objects kept).  This is very
wasteful if you need lots of small objects and only a few large ones.


implementation accepts buffers of any size, each received packet can
have different sizes (between 20 and 262144 bytes).

So every 20 byte object will pin down ~100kiB of actual memory, which
sounds pretty wasteful, but might be acceptable.


in general and currently, in my not yet public branch, I only allocate
packets of 2 different sizes and so sync.Pool could be appropriate, I'll

You could have two separate pools, one for each size.  This is
basically a bucketed-allocator, but simpler because you already know
the structure of your buckets.




--
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/dd77159c-50b0-e350-67f2-9adebe064e0f%40gmail.com.

[go-nuts] McAfee and the module cache on WSL: rename : permission denied

2020-03-12 Thread Chris Burkert 
Dear all,

besides other environments I have a company laptop running Windows 10
Enterprise with WSL and Ubuntu. In Ubuntu I installed Go 1.14 and wanted to
play around with Gio for fun. However it seems that McAfee doesn't want me
to.

In short this is what I do and (mostly) get:

$ cd ~
$ mkdir test
$ cd test
$ go mod init test;
$ wget
https://git.sr.ht/~eliasnaur/gio/blob/master/example/kitchen/kitchen.go
$ go run kitchen.go
go: finding module for package gioui.org/unit
go: finding module for package gioui.org/layout
go: finding module for package gioui.org/app/headless
go: finding module for package gioui.org/font/gofont
go: finding module for package golang.org/x/exp/shiny/materialdesign/icons
go: finding module for package gioui.org/app
go: finding module for package gioui.org/io/system
go: finding module for package gioui.org/text
go: finding module for package gioui.org/widget
go: finding module for package gioui.org/widget/material
go: downloading gioui.org v0.0.0-20200312174220-af68e17dd324
go: downloading golang.org/x/exp v0.0.0-20200228211341-fcea875c7e85
kitchen.go:20:2: rename
/home/d055539/go/pkg/mod/gioui@v0.0.0-20200312174220-af68e17dd324.tmp-663496537
/home/d055539/go/pkg/mod/gioui.org@v0.0.0-20200312174220-af68e17dd324:
permission denied
kitchen.go:21:2: rename
/home/d055539/go/pkg/mod/gioui@v0.0.0-20200312174220-af68e17dd324.tmp-663496537
/home/d055539/go/pkg/mod/gioui.org@v0.0.0-20200312174220-af68e17dd324:
permission denied
kitchen.go:31:2: rename
/home/d055539/go/pkg/mod/gioui@v0.0.0-20200312174220-af68e17dd324.tmp-663496537
/home/d055539/go/pkg/mod/gioui.org@v0.0.0-20200312174220-af68e17dd324:
permission denied
kitchen.go:22:2: rename
/home/d055539/go/pkg/mod/gioui@v0.0.0-20200312174220-af68e17dd324.tmp-663496537
/home/d055539/go/pkg/mod/gioui.org@v0.0.0-20200312174220-af68e17dd324:
permission denied
kitchen.go:23:2: rename
/home/d055539/go/pkg/mod/gioui@v0.0.0-20200312174220-af68e17dd324.tmp-663496537
/home/d055539/go/pkg/mod/gioui.org@v0.0.0-20200312174220-af68e17dd324:
permission denied
kitchen.go:24:2: rename
/home/d055539/go/pkg/mod/gioui@v0.0.0-20200312174220-af68e17dd324.tmp-663496537
/home/d055539/go/pkg/mod/gioui.org@v0.0.0-20200312174220-af68e17dd324:
permission denied
kitchen.go:25:2: rename
/home/d055539/go/pkg/mod/gioui@v0.0.0-20200312174220-af68e17dd324.tmp-663496537
/home/d055539/go/pkg/mod/gioui.org@v0.0.0-20200312174220-af68e17dd324:
permission denied
kitchen.go:26:2: rename
/home/d055539/go/pkg/mod/gioui@v0.0.0-20200312174220-af68e17dd324.tmp-663496537
/home/d055539/go/pkg/mod/gioui.org@v0.0.0-20200312174220-af68e17dd324:
permission denied
kitchen.go:27:2: rename
/home/d055539/go/pkg/mod/gioui@v0.0.0-20200312174220-af68e17dd324.tmp-663496537
/home/d055539/go/pkg/mod/gioui.org@v0.0.0-20200312174220-af68e17dd324:
permission denied
kitchen.go:29:2: rename /home/d055539/go/pkg/mod/
golang.org/x/e...@v0.0.0-20200228211341-fcea875c7e85.tmp-991628004
/home/d055539/go/pkg/mod/golang.org/x/exp@v0.0.0-20200228211341-fcea875c7e85:
permission denied

I wrote that this is the output I mostly get because in some cases I get a
slightly different error. For example after repeating the go run often
enough the golang.org/x/exp was cached fine.

I was not able to reproduce this on any of the other environments (various
pure Linux VMs).

During the go run McAfee is busy and I assume it causes the errors.
Unfortunately I cannot switch off McAfee to prove that.

Do you see similar issues with this combination of WSL and the McAfee
scanner? Or am I doing something stupid here and just don't see my fault?

thanks - Chris

-- 
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/CALWqRZpbQvv5JaHB3Me7qL-nYW27Jqsx88Xv4n_nF7fFR0sMxQ%40mail.gmail.com.

Re: [go-nuts] Re: Where is the version number for a golang module declared?

2020-03-12 Thread Nick 
Hi Wojciech,

> We need to dance this quadrille because go tools won't look at the
> go.mod.local (https://github.com/golang/go/issues/26640)
> 
> Unfortunately "go.mod.local" was not invented at Google, so chances we
> would ever have sane G-independent setup are miniscule now. Mind also
> that GOPATH is now led to the guillotine, to force all this "local server / 
> crafted hosts / GOPRIVATE setup" fun on everyone not willing to share
> her development setup with the big G.

Forgive my ignorance, but why aren't gohack and replace statements 
in the go.mod file perfectly good replacements for these use cases?  
I get the feeling I'm missing something...

I agree that anything that penalises people for not using Google 
services is problematic, but I don't see how that's happening here.

Nick

-- 
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/20200312191148.GA12892%40mussel.lan.

[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly

2020-03-12 Thread howardcshaw 

>
>   let blob = new Blob([buf], {'type': imageType});
>>   document.getElementById('targetImg').src = URL.createObjectURL(blob);
>> } 
>>
>
> I see.  In your case, targetImg is an , right?  Do you know how I 
> could use this same technique with a ? 
>
>
If the  was off-screen or hidden, couldn't you still reference it to 
get the data into the canvas like:
  var img = document.getElementById('targetImg');
  ctx.drawImage(img, 10, 10);

Might not be the most efficient way, but it seems like it should work.

-- 
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/8dbab1d3-fc01-471c-9dbd-b0132b613c5f%40googlegroups.com.

[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly

2020-03-12 Thread Scott Pakin 
On Thursday, March 12, 2020 at 11:35:30 AM UTC-6, Agniva De Sarker wrote:
>
> There is no base64 conversion now anywhere. If you read the code below, 
> you'll see I use 
>
> dst := js.Global().Get("Uint8Array").New(len(s.outBuf.Bytes()))
> n := js.CopyBytesToJS(dst, s.outBuf.Bytes())
> s.console.Call("log", "bytes copied:", strconv.Itoa(n))
> js.Global().Call("displayImage", dst)
>
> Essentially, I copy over the bytes to the array and pass the array over to 
> JS land.
>
> And then displayImage does this:
>
> function displayImage(buf) {
>   let blob = new Blob([buf], {'type': imageType});
>   document.getElementById('targetImg').src = URL.createObjectURL(blob);
> } 
>

I see.  In your case, targetImg is an , right?  Do you know how I 
could use this same technique with a ? 

Thanks for the code.  It's good to see that there's a way to skip base64 
conversions during the Go-to-JavaScript data transfer.

— Scott

-- 
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/633d160f-4636-40f9-84be-d59af911eedd%40googlegroups.com.

[go-nuts] Re: panic: interface conversion: ... (types from different scopes)

2020-03-12 Thread yy0125 
Just encountered the same problem. Would you mind sharing how you solved 
it? Thanks a lot.

On Friday, February 8, 2019 at 8:11:47 AM UTC-6, clement...@gmail.com wrote:
>
> Hello
>
> i was playing with the plugin mode and i met this error
>
> *panic: interface conversion: interface {} is func(string, func([]string) 
> error) error, not func(string, func([]string) error) error (types from 
> different scopes)*
>
> the code is a regular conversion, without test because i was not expecting 
> such failure, something like *x := arg.(func(...))*
>
> as https://github.com/golang/go/issues/26094 i understand that i declared 
> a type with identical signature but within two different programming scopes.
>
> i was working with go1.11 when i got that error specifically. 
> go1.10 is also having this behavior, the error is a bit less expressive.
>
> the binary file was build with *go build  -buildmode=plugin ...*
> the program does not break during the plugin loading sequence, 
> it breaks later at runtime with a panic as demonstrated.
>
> its unmanageable behavior for me, i have no way to overcome that error,
> i wonder if there is anyway i can dynamically load generated code,
> i wonder if this behavior is intended to remain forever.
>
> 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/9fbc1f18-db8d-4acd-a448-96eec2d4786c%40googlegroups.com.

[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly

2020-03-12 Thread Agniva De Sarker 


On Wednesday, 11 March 2020 18:52:15 UTC+5:30, howar...@gmail.com wrote:
>
> I've no relevant experience, but I can recommend a couple of projects to 
> look at in the absence of anyone chiming in with actual experience:
>
> https://agniva.me/wasm/2018/06/18/shimmer-wasm.html
> https://github.com/agnivade/shimmer
> This is a play-project that involves loading images. It appears to be 
> using a side-load method of converting the image to Base64 and assigning it 
> to the image's src attribute - so it is not using the canvas directly, but 
> if a call to the canvas can draw an image from a URL, this might work - 
> have a look at
>
> // updateImage writes the image to a byte buffer and then converts it to 
> base64.
> // Then it sets the value to the src attribute of the target image.
> func (s *Shimmer) updateImage(img *image.RGBA, start time.Time) 
>

Woops, that comment is outdated and needs to be fixed. The blog post is 
also outdated now :D.
There is no base64 conversion now anywhere. If you read the code below, 
you'll see I use 

dst := js.Global().Get("Uint8Array").New(len(s.outBuf.Bytes()))
n := js.CopyBytesToJS(dst, s.outBuf.Bytes())
s.console.Call("log", "bytes copied:", strconv.Itoa(n))
js.Global().Call("displayImage", dst)

Essentially, I copy over the bytes to the array and pass the array over to 
JS land.

And then displayImage does this:

function displayImage(buf) {
  let blob = new Blob([buf], {'type': imageType});
  document.getElementById('targetImg').src = URL.createObjectURL(blob);
} 

Before the CopyBytesToJS  
API, 
I used unsafe to get the slice header and then pass it to JS, and populate 
the slice with the image contents. Definitely hacky, but that did not 
require passing the entire image from JS to wasm. With the new API, we are 
back to passing data, but it's a lot safer.

Coming to the original problem, yes there is no Uint8ClampedArray support. 
People have already raised it here: 
https://github.com/golang/go/issues/32402. I think you can use a similar 
hack for your purposes.

Feel free to hop in to #webassembly slack channel if you have more 
questions.

-Agniva


> in https://github.com/agnivade/shimmer/blob/master/shimmer.go
>
> Here is another project that also went with the Base64 method of passing 
> the array, look for the section labeled "Pixels are Pixels": 
>
> https://blog.jeremylikness.com/blog/2019-03-03_gopher-meet-plasma-a-webassembly-experiment/
>
> His final verdict was that the pure Javascript version performed better 
> than the Go-WASM+JS version.
>

-- 
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/2eab5b50-9168-4584-ab42-11bac47ea8d4%40googlegroups.com.

Re: [go-nuts] Re: [ANN] Gio: portable immediate mode GUI programs in Go for iOS/tvOS, Android, macOS, Linux, Windows

2020-03-12 Thread Elias Naur 
On Thu, Mar 12, 2020 at 6:03 PM husam alkdary  wrote:
>
> where I can find a simple examples of GIO with golang so I can try it
>

There are 4 examples here:

https://git.sr.ht/~eliasnaur/gio/tree/master/example

You can run them from a Go module with `go run`. For example:

$ go run gioui.org/example/kitchen

For a primer of the unusual stateless approach to GUI programming, see the
article

https://eliasnaur.com/blog/immediate-mode-gui-programming

-- elias

-- 
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/CAMAFT9U5N4sSmRpcd2cYzu6UWALKzqqmz-YN%3DyOvVifMPxmMHQ%40mail.gmail.com.

[go-nuts] Re: [ANN] Gio: portable immediate mode GUI programs in Go for iOS/tvOS, Android, macOS, Linux, Windows

2020-03-12 Thread husam alkdary 
where I can find a simple examples of GIO with golang so I can try it

On Sunday, March 31, 2019 at 3:16:44 PM UTC+2, ma...@eliasnaur.com wrote:
>
> Hi,
>   
> I'm very happy to announce the first public release of Gio, a project for 
> writing portable, hardware accelerated, immediate mode GUI programs in Go.
>
> If you have Go 1.12 installed,
>
> $ export GO111MODULE=on
> $ go run gioui.org/apps/hello
>
> should display the proverbial hello world message. If not, please follow 
> the setup guide at
>
> https://gioui.org/
>
> The setup guide describes how to run the gio programs on Android an iOS. 
>
> The command
>
> $ go run gioui.org/apps/gophers
>
> runs a simple demo displaying Go contributors fetched from Github. Specify 
> a github token with the -token flag if you run out of quota.
>
> Gio programs run on all the major platforms: iOS/tvOS, Android, Linux 
> (Wayland), macOS and Windows. The project is very much experimental; don't 
> expect Gio to produce production ready programs and apps yet.
>
> Gio only depends on the platform libraries for drawing and input and 
> avoids the platform toolkits. Gio has an immediate mode design where no 
> structure is imposed on the program, not even for the layout hierachy. 
> Unlike any other Go project I know of, Gio runs on all the major platforms, 
> mobile and desktop alike: iOS/tvOS, Android, macOS, Linux, Windows.
>
> Gio includes an efficient vector renderer based on the Pathfinder project (
> https://github.com/pcwalton/pathfinder). Text and other shapes are 
> rendered without baking them into texture images, to support efficient 
> animations, transformed drawing and pixel resolution independence.
>
> I decided to release Gio a little earlier than planned because of 
> increasing activity in the Go GUI space. Fyne recently reached 1.0 and just 
> two days ago Johann Freymuth released his ui library.
> It is my ambition to make Go a natural choice for GUI programs everywhere. 
> I hope you will be inspired to help me with Gio, but if you don't, Gio is 
> dual licensed under MIT and the UNLICENSE, anyone is free to use Gio's code 
> as their own, even without attribution. The gioui.org/ui/app package is 
> particularly interesting; it abstracts window management, input and vector 
> drawing into a simple Go API. The gioui.org/cmd/gio tool packages Gio 
> programs into iOS/tvOS frameworks or Android AAR files.
>
> The wide platform support is Gio's eye-catcher, but I'm most proud of its 
> design. I've spent more than a year on the project and most of that time 
> went into designing the API. However, this early release contains very 
> little documentation (and no tests!); expect much more documentation in the 
> coming months.
>
> The project is hosted on Sourcehut (https://git.sr.ht/~eliasnaur/gio). 
> Despite its very young age, I chose Sourcehut because it is strictly open 
> source, its business model is simple and because it supports contributions 
> without registration. The mailing list (
> https://lists.sr.ht/~eliasnaur/gio-dev) is open to everyone and patches 
> are sent with git send-email. I expect that even bug reports (
> https://todo.sr.ht/~eliasnaur/gio) can be filed with an email in the 
> future.
>
>  - elias
>
>

-- 
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/0f01f106-718a-40a7-a0b4-550ff659494d%40googlegroups.com.

Re: [go-nuts] Re: Mem-Leak in Go method

2020-03-12 Thread Nitish Saboo 
Hi,

I have compiled my Go binary against go version 'go1.7 linux/amd64'.
I added the following code change in the main function to get the memory
profiling of my service

var memprofile = flag.String("memprofile", "", "write memory profile to
`file`")

func main() {
flag.Parse()
if *memprofile != "" {
f, err := os.Create(*memprofile)
if err != nil {
fmt.Println("could not create memory profile: ", err)
}
defer f.Close() // error handling omitted for example
runtime.GC() // get up-to-date statistics
if err := pprof.WriteHeapProfile(f); err != nil {
fmt.Println("could not write memory profile: ", err)
}
}
..
..
(Rest code to follow)

I ran the binary with the following command:

nsaboo@ubuntu:./main -memprofile=mem.prof

After running the service for couple of minutes, I stopped it and got the
file 'mem.prof'

1)mem.prof contains the following:

nsaboo@ubuntu:~/Desktop/memprof$ vim mem.prof

heap profile: 0: 0 [0: 0] @ heap/1048576

# runtime.MemStats
# Alloc = 761184
# TotalAlloc = 1160960
# Sys = 3149824
# Lookups = 10
# Mallocs = 8358
# Frees = 1981
# HeapAlloc = 761184
# HeapSys = 1802240
# HeapIdle = 499712
# HeapInuse = 1302528
# HeapReleased = 0
# HeapObjects = 6377
# Stack = 294912 / 294912
# MSpan = 22560 / 32768
# MCache = 2400 / 16384
# BuckHashSys = 2727
# NextGC = 4194304
# PauseNs = [752083 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
# NumGC = 1
# DebugGC = false

2)When I tried to open the file using the following command, it just goes
into interactive mode and shows nothing

a)Output from go version go1.7 linux/amd64 for mem.prof

nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof mem.prof
Entering interactive mode (type "help" for commands)
(pprof) top
profile is empty
(pprof)

b)Output from go version go1.12.4 linux/amd64 for mem.prof

nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof mem.prof
Type: space
No samples were found with the default sample value type.
Try "sample_index" command to analyze different sample values.
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) o
  call_tree = false
  compact_labels= true
  cumulative= flat //: [cum | flat]
  divide_by = 1
  drop_negative = false
  edgefraction  = 0.001
  focus = ""
  granularity   = functions//: [addresses |
filefunctions | files | functions | lines]
  hide  = ""
  ignore= ""
  mean  = false
  nodecount = -1   //: default
  nodefraction  = 0.005
  noinlines = false
  normalize = false
  output= ""
  prune_from= ""
  relative_percentages  = false
  sample_index  = space//: [objects | space]
  show  = ""
  show_from = ""
  tagfocus  = ""
  taghide   = ""
  tagignore = ""
  tagshow   = ""
  trim  = true
  trim_path = ""
  unit  = minimum
(pprof) space
(pprof) sample_index
(pprof) top
Showing nodes accounting for 0, 0% of 0 total
  flat  flat%   sum%cum   cum%


3)Please let me know if it is this the correct way of getting the memory
profiling ?

4)Can we deduce something from this memory stats that points us to increase
in memory usage?

5)I am just thinking out loud, since I am using go1.7, can that be the
reason for the issue of increase in memory usage that might get fixed with
latest go versions ?

Thanks,
Nitish

On Tue, Mar 10, 2020 at 6:56 AM Jake Montgomery  wrote:

>
> On Monday, March 9, 2020 at 1:37:00 PM UTC-4, Nitish Saboo wrote:
>>
>> Hi Jake,
>>
>> The memory usage remains constant when the rest of the service is
>> running.Only when LoadPatternDB() method is called within the service,
>> Memory Consumption increases which actually should not happen.
>>  I am assuming if there is a memory leak while calling this method
>> because the memory usage then becomes constant after getting increased and
>> then further increases on next call.
>>
>
> Its possible that I am not fully understanding, perhaps a language
> problem. But from what you have written above I still don't see that this
> means you definitely have a memory leak. To test for that you would need to 
> *continuously
> *call LoadPatternDB() and monitor memory for a

Re: [go-nuts] Re: Where is the version number for a golang module declared?

2020-03-12 Thread Wojciech S. Czarnecki 
Dnia 2020-03-11, o godz. 08:22:46
"'Bryan C. Mills' via golang-nuts"  napisał(a):

> (But note that you can always set up a local HTTP server using the remote 
> import path  protocol, 
> and use a local DNS entry and the GOPRIVATE environment variable to tell 
> the Go command where to find the repo.)

The very need for such a workaround tells that something is severely broken.

1. set up local server just to serve what GOPATH provided seamlessly

2. tinker with your /etc/hosts or c:\Windows\System32\Drivers\etc\hosts or 
/private/etc/hosts.
Do it **every time** you want to work locally on a module from other domain.

3. Reconfigure hosts and your local web server **every time** you want to work 
locally
on a next module. Keep all these configs forever, because you may need to 
maintain your
patches

4. do not forget to set up GOPRIVATE, otherwise you will leak to the outer world
rinse and repeat on any host you do tests etc

We need to dance this quadrille because go tools won't look at the
go.mod.local (https://github.com/golang/go/issues/26640)

Unfortunately "go.mod.local" was not invented at Google, so chances we
would ever have sane G-independent setup are miniscule now. Mind also
that GOPATH is now led to the guillotine, to force all this "local server / 
crafted hosts / GOPRIVATE setup" fun on everyone not willing to share
her development setup with the big G.

my ¢2

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20200312161646.5c19d89d%40xmint.

Re: [go-nuts] Is this code in package unix assuming machine endianess?

2020-03-12 Thread Tom Parkin 
Thanks Rob, that was an interesting read.

I think your pattern is good, and makes perfect sense when you think about
it.  It occurred to me when reading that another way of thinking about the
pattern is that you're coding to the endianess of the byte stream, and
letting the layout of the type in memory be sorted out by the compiler
writers, which seems like a reasonable separation of concerns.

What threw me off the scent somewhat, as someone coming from a C
background, is that the code I pointed to superficially resembles the sort
of thing you mentioned in your article.  Perhaps even more so as it's
taking a uint16 value, treating it as a byte array, and then reassembling
the byte array into a uint16.  And once your brain has said "aha, byte
swapping", its difficult to think outside that box.

Ah well, TIL, etc, etc.  Thanks again for the link :-)

On Thu, 12 Mar 2020 at 01:33, Rob Pike  wrote:

> More context, in the form of self-promotion:
> https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html
>
> -rob
>
>
> On Wed, Mar 11, 2020 at 9:42 PM Tom Parkin  wrote:
>
>> On Tue, 10 Mar 2020 at 23:14, Ian Lance Taylor  wrote:
>>
>>> On Tue, Mar 10, 2020 at 4:03 PM Tom Parkin  wrote:
>>> >
>>> > I'm working on adding a new Linux socket type (L2TPIP) to the unix
>>> package, and I noticed some code in there that appears on the face of it to
>>> be assuming the endianess of the host.  The #networking channel on the
>>> Gophers slack suggested I raise the question here.
>>> >
>>> > The code I am struggling with is in this file:
>>> >
>>> > https://github.com/golang/sys/blob/master/unix/syscall_linux.go
>>> >
>>> > So far as I can make out, this code implements a variety of system
>>> calls for Linux generally, irrespective of GOARCH.
>>> >
>>> > In this file, there is a function anyToSockaddr which serves to
>>> convert struct sockaddr from system calls such as getsockname(2) and
>>> accept4(2) into Go representations of the various sockaddr types, for
>>> example unix.SockaddrUnix and unix.SockaddrInet4.  The function
>>> anyToSockaddr switches on the address family in the struct sockaddr, and
>>> then converts based on that.
>>> >
>>> > I noticed for the AF_INET case in the switch statement of
>>> anyToSockaddr that the struct sockaddr_in sin_port field is being
>>> unconditionally byte-swapped during conversion:
>>> >
>>> > pp := (*RawSockaddrInet4)(unsafe.Pointer(rsa))
>>> > sa := new(SockaddrInet4)
>>> > p := (*[2]byte)(unsafe.Pointer())
>>> > sa.Port = int(p[0])<<8 + int(p[1])
>>> > for i := 0; i < len(sa.Addr); i++ {
>>> > sa.Addr[i] = pp.Addr[i]
>>> > }
>>> > return sa, nil
>>> >
>>> > (where 'rsa' is a pointer to a RawSockaddrAny).
>>> >
>>> > Now, ip(7) states of the struct sockaddr_in structure:
>>> >
>>> >   "Note that the address and the port are always stored in network
>>> byte order.  In particular, this means that you need to call htons(3) on
>>> the number that is assigned to a port."
>>> >
>>> > So the byte swapping that anyToSockaddr is doing makes sense, but only
>>> if the host is a little-endian machine.  It seems as though this code would
>>> do the wrong thing on a big-endian machine.
>>> >
>>> > Can anyone suggest what I'm missing here?  Is this code really
>>> assuming that the host is a little-endian machine?
>>>
>>> This does not look like byte swapping to me.  Here pp.Port should be
>>> in network byte order.  To set sa.Port we read the first byte of
>>> pp.Port, left shift by 8, then or in the second byte of pp.Port.  That
>>> is, we interpret pp.Port as a two-byte big-endian number, and compute
>>> the value as a 16-bit integer.  That will work regardless of the
>>> endianness of the host.
>>>
>>
>> Thanks Ian for your answer.
>>
>> It took me a little bit of thinking to get there :-( but I see what
>> you're saying now.
>>
>> For anyone else playing along at home who may be struggling like I was...
>>
>> By treating the uint16 pp.Port value as an array of bytes, the code can
>> access the bytes in network byte order, since that's how byte arrays are
>> laid out in memory (e.g. if [0] is address A, [1] is A+1, etc).
>>
>> The left shift and addition effectively convert to host byte order, since
>> that's how uint16 value will be stored in memory.
>>
>>
>> --
>> 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/CACzvQmaCcqfuZNyX43-%2Bb51z6bK8LLMrc7VxtLCMctBSg_fkJg%40mail.gmail.com
>> 
>> .
>>
>

-- 
Tom Parkin

-- 
You received this message because you are

Re: [go-nuts] Where is the version number for a golang module declared?

2020-03-12 Thread 'Benjamin' via golang-nuts 
Go programming language has no version mechanism.
Like java jar files that contains class files.

If you want to use special version, the version can be included in the import 
path


> On Mar 11, 2020, at 13:32, Tamás Gulácsi  wrote:
> 
> AFAIK tags are for concrete version (vMajor.Minor.Patch), branches and a 
> subdirectory for maintaining different major versions concurrently.
> 
> -- 
> 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/ac8b47d5-3b5f-421d-a577-f7861281af84%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/5BE671B2-3154-49F4-85DC-83FBFC9CD359%40icloud.com.

Re: [go-nuts] Re: Where is the version number for a golang module declared?

2020-03-12 Thread Volker Dobler 
The go tool works well if you use package import path
as arguments.

On Wednesday, 11 March 2020 20:49:53 UTC+1, Dean Schulze wrote:
>
> Well here's what I get in my module with a single directory with a single 
> file with a single package called lib:
>

To be concrete let the module name be dean.schulz/awsome
and containing one folder lib containing package lib.
With this setup the import path of this package lib is
   dean.schulz/awsome/lib 

>
> $ go install lib
> can't load package: package lib is not in GOROOT 
> (/home/dean/bin/go1.14.linux-amd64/go/src/lib)
>

Try cd' _into_ the lib folder and either
$ go install
$ go install  dean.schulz/awsome/lib
 

> If I add the pwd to my GOPATH (the way things worked before modules) I get:
>
> $ go install lib
> $GOPATH/go.mod exists but should not
>

It is either GOPATH or go modules. Don't try mixing stuff. 

If I remove the go.mod file and give it the relative path to a source file 
> it works but doesn't install anything:
> $ go install src/lib/conf.reader.go 
>

Again: Most subcommands of the go tool work best if
invoked with the "import path" of a package. The import
path with modules is formed like this:
/
What works very well too is cd'ing into the folder and calling
build, install, test, etc _without_ any arguments.

V.

-- 
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/b52999b5-ec7c-4b1d-847c-51b618efc9ad%40googlegroups.com.

[go-nuts] Re: go tip: random high CPU usage on VirtualBox

2020-03-12 Thread Mhd Shulhan 


> My question is any one have idea how to debug this so I can provide more
> detailed report?
> 
> Thank you in advance.

So, I try to debug with gdb 9.1.  Here is the sample of stack when the CPU got 
high,

...
[New LWP 1885]
[New LWP 1886]
[New LWP 1887]
[New LWP 1888]
[New LWP 1889]
^C
Thread 1 "XYZ" received signal SIGINT, Interrupt.
runtime.futex () at /Users/XXX/share/go/src/runtime/sys_linux_amd64.s:568
568 /Users/X/share/go/src/runtime/sys_linux_amd64.s: No such file or 
directory.
(gdb) where
#0  runtime.futex () at /Users/XXX/share/go/src/runtime/sys_linux_amd64.s:568
#1  0x00431666 in runtime.futexsleep (addr=0xd6a3e8 , 
val=0, ns=-1) at /Users/XXX/share/go/src/runtime/os_linux.go:44
#2  0x0040bd9f in runtime.notesleep (n=0xd6a3e8 ) at 
/Users/XXX/share/go/src/runtime/lock_futex.go:151
#3  0x0043b858 in runtime.stoplockedm () at 
/Users/XXX/share/go/src/runtime/proc.go:1972
#4  0x0043d4c6 in runtime.schedule () at 
/Users/XXX/share/go/src/runtime/proc.go:2455
#5  0x0043d89d in runtime.park_m (gp=0xc000166c00) at 
/Users/XXX/share/go/src/runtime/proc.go:2691
#6  0x004651fb in runtime.mcall () at 
/Users/XXX/share/go/src/runtime/asm_amd64.s:318
#7  0x00465114 in runtime.rt0_go () at 
/Users/XXX/share/go/src/runtime/asm_amd64.s:220
#8  0x in ?? ()
...

Rebuild with `-gcflags=all="-N -l"` and running it again result in the same 
stack trace.


Looking at git blame for each files does not shown any new commit introduced 
since after Go 1.14. Maybe others can look.

The next thing I will do is bissecting and rebuild and report again.

-- 
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/3094C38B-39A4-4DBB-B54E-7FD4D6971330%40gmail.com.