Re: [go-nuts] What is The compiler's -json optimization logging

['David Chase' via golang-nuts]

There is also a command-line proof-of-concept that combines it with
profiling information to show you only the missed/unabled optimizations
that are also hot spots in the profile.

https://github.com/dr2chase/gc-lsp-tools

There's a lot of checks and things that can't be optimized away, but very
few have any effect on a typical program's performance.

On Fri, Sep 4, 2020 at 4:51 PM Peter Weinberger (温博格) 
wrote:

> And gopls will compute them as diagnostics. For instance, if using vscode
> and gopls, then in setting.json:
> "gopls": {
>   "codelens": {
> "gc_details": true,
>   }
> }
>
> and a clickable 'Toggle gc annotation details' should appear just above
> the package statement.
>
> On Fri, Sep 4, 2020 at 4:28 PM Ian Lance Taylor  wrote:
>
>> [ + drchase ]
>>
>> On Fri, Sep 4, 2020 at 1:16 PM Falco Wockenfuß 
>> wrote:
>> >
>> > sorry if this is a dumb question, but the Release Notes for go 1.15
>> have the Note:
>> > The compiler's -json optimization logging now reports large (>= 128
>> byte) copies and includes explanations of escape analysis decisions.
>> >
>> > But I didn't find anything about "-json" as a flag for go build or
>> similar and google dind't yield anything for go compiler json optimization
>> logging or similar.
>> >
>> > Can anyone clarify what this json optimiziation logging is and how it
>> can be used/invoked ?
>>
>> It does seem that this option should be mentioned in cmd/compile/doc.go.
>>
>> To use it, try "go build -gcflags=json=0,/my/json/dir".
>>
>> 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/CAOyqgcVB-pJUf6AxSDsAqoEJbzBm_h7Qt4%2BTJyUg0mE63RyDcQ%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/CAHOpXeWf%2BVQg1kXQgOavX4dGtd2Hhku-Xp8u5wyVGMpEwyLP8w%40mail.gmail.com.

[go-nuts] Re: Is it possible to get code coverage information in a way that does not assume you can see color?

['David Chase' via golang-nuts]

Lack of accessibility is a legitimate bug.
Would would be good for you?
For example, is there something in html that would work?

I have no idea what current screen readers do -- would *underlining*, or 
*bolding*, or *italics?*
(I used the three styles for the three words in the line just above.)

On Thursday, January 9, 2020 at 10:39:41 AM UTC-5, Jared Stofflett wrote:
>
> I'm a totally blind developer who is trying to learn go. When running
>
> go tool cover -html=cover.out -o cover.html
>
> It appears the HTML generated uses color to show the lines of code that 
> are not covered without any other way of identifying uncovered lines. This 
> is obviously an issue if your totally blind. Are there any alternative 
> tools that can take a coverage profile and give a text representation of 
> lines that are not covered?
>
>  
>

-- 
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/2f77d687-067d-4100-acb1-53c36ada94f7%40googlegroups.com.

Re: [go-nuts] Re: mutual exclusion algorithm of Dijkstra - strange behaviour

['David Chase' via golang-nuts]

If you want preemption within a particular package, you can compile it "go 
build -gcflags=particular_package=-d=ssa/insert_resched_checks/on" .
That will not fix any problems with underlying raciness, though it may mask 
them.

If you want an entire compiler that defaults to that mode and libraries 
also built that way, "GOEXPERIMENT=preemptibleloops ./make.bash" .
This can slow code down quite a bit.

We're not super-excited about this approach, but a fix that doesn't trash 
performance is tricky (we've been working on it for a while).
When we do get it done right, the flags and the experiment are likely to go 
away.

On Saturday, August 17, 2019 at 12:24:58 AM UTC-4, xkw...@connect.hku.hk 
wrote:
>
> Could you let me know which compiler can support pre-emption and how to 
> enable it? Thanks.
>
> On Saturday, August 17, 2019 at 9:20:07 AM UTC+8, Ian Davis wrote:
>>
>> On Fri, 16 Aug 2019, at 7:09 PM, dr.ch...@gmail.com wrote:
>>
>> Dear Community and dear Go-developers,
>>
>> Meanwhile it is clear why things do not work:
>> The Go-Scheduler is unable to allow to switch to another goroutine in 
>> busy-waiting-loops -
>> the only possibility to get around that problem is either to put 
>> "switch-steps" into the source
>> - either "time.Sleep(1)" or "runtime.Gosched()".
>> I think that THIS SHOULD BE DOCUMENTED IN THE LANGUAGE SPECIFICATION !
>>
>>
>> I don't believe this is a language issue. Different compiler 
>> implementations could support pre-emption if they chose to.
>>
>> 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/a735e0bb-f2a6-4dcc-a041-48357569f379%40googlegroups.com.

Re: [go-nuts] Re: [CoC] screenshot images. Lazines or incompetence?

['David Chase' via golang-nuts]

On Tuesday, March 12, 2019 at 5:45:36 PM UTC-4, Robert Engels wrote:
>
> I did just encounter a case though where trying to copy and paste a table 
> wasn’t happening, and there is no way I am going to type it all in or get 
> the author to change it, so screen shot it is...
>

I have done the same -- but it is really an upstream instance of the same 
problem that Ohir points out:
If all that is needed is text, then text is good, and pictures of text are 
bad.
And when I had to deal with pictures of text, I was furious, and it came 
through loud and clear in the bug report for which the pictures should not 
have been necessary.

There's lots of details for accessibility, it would be nice if we had tools 
to help us remember because otherwise we're certain to forget from time to 
time.
See/hear for example Julia Ferraioli's Gophercon talk on increasing 
accessibility in the code that we 
write: https://www.youtube.com/watch?v=cVaDY0ChvOQ
(Her eyes apparently do not focus dependably, hence the screen reader.)

Sorry if I committed a quoting mistake, I can't tell if that is an issue or 
not, though I saw some mention.


-- 
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] Debugging & breakpoints in Go compiler source code

['David Chase' via golang-nuts]

Wouldn't mind knowing the version of that Go compiler.
What you see there is a bug in generated debugging information (DWARF).
You might be better off using Delve; parts of the compiler are 
multithreaded (with goroutines, not necessarily threads that gdb 
understands) and that is not best case for gdb.

On Monday, March 11, 2019 at 7:01:04 PM UTC-4, MOHIT VERMA wrote:
>
> Thanks Ian. This helped me to identify what processes are launched when go 
> build is called.
> I then ran gdb just for the process that compiled the file for which I 
> wanted to debug the compilation: 
>
> gdb --args /home/administrator/Work/go/src/go/pkg/tool/linux_amd64/compile 
> -o /tmp/go-build037119929/b001/_pkg_.a -trimpath 
> /tmp/go-build037119929/b001 -p main -complete -buildid 
> Y52EEDh5fr669VPNVIvF/Y52EEDh5fr669VPNVIvF -D 
> _/home/administrator/Work/go/src/example_test -importcfg 
> /tmp/go-build037119929/b001/importcfg -pack -c=4 ./example.go
>
> Although I get this error when setting any breakpoint:
> *Dwarf Error: Cannot find DIE at 0x182106 referenced from DIE at 0x1892a7*
>
> *Do I need to build the Go compiler differently to be able to debug it? *
> Currently, I am just building it through make.bash from the src/ 
> directory.
>
> Thanks!
> Mohit
>
> On Fri, Mar 8, 2019 at 4:29 PM Ian Lance Taylor  > wrote:
>
>> On Fri, Mar 8, 2019 at 4:23 PM Mohit Verma > > wrote:
>> >
>> > I was looking to see how the golang compiler works, and wanted to step 
>> in to the compilation process to see what happens. I am looking at the 
>> standard Go compiler in src/cmd/compile from https://github.com/golang/go
>> .
>> >
>> > When I try to run the compilation process with gdb, I see I can put 
>> breakpoints for the code when the "go tool" is triggered (code in 
>> src/cmd/go), but not in the code inside cmd/compile/internal.
>> > I can also put breakpoints for the code in runtime package, and I see 
>> runtime package has a special "runtime-gdb.py" file.
>> >
>> > Can anyone point me to what is going on here? And how can I step-in to 
>> the compiler code?
>>
>> The go tool invokes cmd/compile as a subprocess.  To see exactly what
>> the go tool does, run
>>
>> go tool -x -work
>>
>> That will show you an invocation of cmd/compile that you can run under
>> the debugger.  Using -work ensures that the temporary files passed to
>> the compiler will be available; you will have to replace $WORK in the
>> -x output with the temporary directory printed in the first line of
>> the cmd/go output.
>>
>> Note that in general compilation are cached, so to get a useful
>> cmd/compile execution you may have to first run "go clean -cache".
>>
>> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: How can I try debug.SetMaxHeap?

['David Chase' via golang-nuts]

I think you actually want this stack of CLs.
Despite Gerrit's predictions of doom, in fact they cherry-pick cleanly onto 
tip, and it builds, and passes tests:

git fetch https://go.googlesource.com/go refs/changes/90/66090/4 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/50/46750/6 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/91/66091/4 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/92/66092/4 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/51/46751/13 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/40/151540/5 && git 
cherry-pick FETCH_HEAD
git fetch https://go.googlesource.com/go refs/changes/17/156917/4 && git 
cherry-pick FETCH_HEAD

The API will change, don't get too attached to it.




On Wednesday, February 20, 2019 at 2:12:01 PM UTC-5, Vinicius Fortuna wrote:
>
> My team is struggling with limiting the head size of a Go application and 
> would like to know how to use SetMaxHeap.
>
> We wrote a VpnExtension for iOS which gets killed by the OS if is consumes 
> more than 15MB, but there's no way to tell Go to not pass that limit. I 
> learned about the debug.SetMaxHeap experiment, and it seems that may solve 
> our problem. I'm ok running a custom runtime for now. 
> However, it's unclear how I can use it. it seems to be one a CL that was 
> never submitted and now has merge conflicts: 
> https://go-review.googlesource.com/c/go/+/46751
> How can I get a Go version with SetMaxHeap?
>
> Thanks
>
> Vinicius Fortuna
>
>
>

-- 
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] Go vs C speed - What am I doing wrong?

['David Chase' via golang-nuts]

A general problem with interlanguage benchmarks is that you can only 
compare those features that both languages have, so these always reduce to 
lowest common denominator and are inherently biased against new features.  
So for example, go will get no credit for having a garbage collector, 
checked array and string indexing operations, maps, slices, type 
assertions, interfaces, reflection, channels, resizeable stacks, etc.

On Sunday, February 3, 2019 at 7:15:36 PM UTC-5, Miki Tebeka wrote:
>
> Thanks. You're right - this is not the way to choose a language. I was 
> just curious. Go has many, many more things going for it - multi core 
> support, networking, standard library, community ...
>

-- 
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] Re: Wuffs: a new, memory-safe programming language

['David Chase' via golang-nuts]

I'm curious how much experience people have with hand-translation of one 
language into another.
What I find is that for not-too-different languages (e.g., C to Java, or C 
to Modula-3) I can process about 1000 lines per day.
K C to ANSI C goes a good deal more quickly.

C pointers translated into Java become a pair, the array that you are 
indexing into, and an index.
I used this strategy for gdtoa and it was good enough.
Unstructured and tricky-exit control flow translated into Java was a much 
more interesting change; for that I used a combination of break out of 
single iteration for loops, and sometimes booleans to indicate code that 
should be skipped (that was previously jumped over).

For Go you'd probably replace increment/decrement pointers with slices.

C++ would be harder because of templates, but it depends very much on how 
exciting the old code's use of templates is. The advantage of 
hand-translation is that you don't have to solve all the inputs that mighty 
theoretically arise, instead you need only consider the problem at hand, 
and if you can hack around the tricky bits in some ugly way, the rest tends 
to proceed rather smoothly.  And obviously (I hope this is obvious), if 
your goal is to increase security, you will not do it all with unsafe.

I did once also work on an automated source-to-source checker for C and 
C++, and it turns out that you can get a tremendous amount of mileage out 
of recognizing idioms and special-casing them.

The one problem with the approach I describe -- dealing with the code that 
you've got, selecting idiom-specific translations -- is that if it fails, 
what it means is that you have even more motivation to translate the input 
code out of C, because it is most likely tricksy, squirrelly, and all the 
more untrustworthy because of that.

-- 
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] Re: [ANN] Geometric index Library

['David Chase' via golang-nuts]

Before you have too many people depending on the current interfaces, would 
you consider replacing the point encoding of even/odd array elements with, 
say, "type Point struct { x, y float64}" ?  I think it would be a more 
attractive interface.

Would also be nice to use build tags to allow use of a Go version of the 
amd64 assembly language code on other platforms.

On Saturday, December 8, 2018 at 8:39:14 PM UTC-5, Gabriel Furstenheim 
Milerud wrote:
>
> Hi,
> I've released a super fast and light geometric index implementing a 
> STR-Tree. Here are some benchmarks on the size of the tree:
>
> BenchmarkSimpleRTree_FindNearestPoint/10  1000   
> 124 ns/op
> BenchmarkSimpleRTree_FindNearestPoint/1000 300   
> 465 ns/op
> BenchmarkSimpleRTree_FindNearestPoint/1200   
> 670 ns/op
> BenchmarkSimpleRTree_FindNearestPoint/10   200   
> 871 ns/op
> BenchmarkSimpleRTree_FindNearestPoint/100  100  
> 1210 ns/op
> BenchmarkSimpleRTree_FindNearestPoint/1000 100
>   1593 ns/op
>
>
> You can find the library at: https://github.com/furstenheim/SimpleRTree
>
> and the documentation at: 
> https://godoc.org/github.com/furstenheim/SimpleRTree
>

-- 
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] Re: Unsupported File Format error while building for linux-amd64 on mac os

['David Chase' via golang-nuts]

One possibility is to use Docker on your Mac to run Linux in a container; I 
use Macs a lot, but don't know how to cross-compile directly when cgo is 
involved (works fine for non-cgo binaries, however).  This assumes you are 
okay with Docker and Linux; in both cases, I flail quite a bit but have 
managed to build and debug Linux programs in a container.

On Friday, September 28, 2018 at 5:08:55 AM UTC-4, Ankit Gupta wrote:
>
> I am working with confluent-kafka-go library (
> https://github.com/confluentinc/confluent-kafka-go) which builds fine on 
> the mac machine (mac OS 10.13.6) along with the code files I wrote. In 
> order to deploy it on Linux server (Ubuntu 64 bit), I try this - 
>
> $> CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build program.go
>
>
> I get below linking error -
>
>
> /usr/local/go/pkg/tool/darwin_amd64/link: running clang failed: exit 
> status 1
>
> ld: warning: ignoring file 
> /var/folders/fy/9ph54yjs6cq1kyxgs6cc9rvjvs6t0m/T/go-link-060577916/go.o, 
> file was built for unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 
> 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) which is not the 
> architecture being linked (x86_64): 
> /var/folders/fy/9ph54yjs6cq1kyxgs6cc9rvjvs6t0m/T/go-link-060577916/go.o
>
> Undefined symbols for architecture x86_64:
>
>   "__cgo_topofstack", referenced from:
>
>   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_conf_new in 03.o
>
>   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_conf_set in 03.o
>
>   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_topic_conf_new in 03.o
>
>   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_topic_conf_set in 03.o
>
>   __cgo_f2fa82ea8f11_Cfunc__c_rdkafka_topic_partition_list_entry in 
> 04.o
>
>   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_assign in 04.o
>
>   __cgo_f2fa82ea8f11_Cfunc_rd_kafka_assignment in 04.o
>
>   ...
>
>   "_main", referenced from:
>
>  implicit entry/start for main executable
>
>  (maybe you meant: __cgo_f2fa82ea8f11_Cfunc_rd_kafka_queue_get_main)
>
> ld: symbol(s) not found for architecture x86_64
>
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
>
> It points to /var/folders which I am given to understand is a temp 
> location in mac.
>
>
> Any ideas on how to fix it?
>
>

-- 
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] Re: Debug Go program with GDB on macOS shows nothing

['David Chase' via golang-nuts]

You did nothing wrong, in 1.11 we started compressing the debug information 
to reduce binary size, and gdb on the Mac does not understand compressed 
DWARF.
We had hoped that the several speedbumps involved in running gdb on modern 
OSX would have caused most users to move to Delve, which handles compressed 
DWARF, but obviously this was overoptimistic.

The workaround is to also specify "-ldflags=-compressdwarf=false" which 
does exactly what it claims.
If you wanted to do this generally (so you did not need to remember), 

export GOFLAGS="-ldflags=-compressdwarf=false"

You might try not specifying "-N -l" and see whether optimized binaries 
have adequate debugging information; it's not perfect, but we are hoping to 
get it good enough that core dumps and probes from/on running applications 
will yield useful information.

Sorry for the inconvenience.


On Thursday, September 27, 2018 at 9:38:23 AM UTC-4, changkun wrote:
>
> Debugging with GDB works fine on Linux, it is able to show everything 
> with the breakpoint. However, nothing appears on macOS.
>
> A simple Go program, say `main.go`:
>
> package main
> 
> func main() {
> println("hello, world!")
> }
>
>
> Then build with 
>
> go build -gcflags "-N -l" -o main main.go
>
>
> Using GDB:
>
> $ gdb main
> GNU gdb (GDB) 8.2
> (...)
> Reading symbols from main...(no debugging symbols found)...done.
> Loading Go Runtime support.
> (gdb) source /usr/local/Cellar/go/1.11/libexec/src/runtime/runtime-gdb
> .py
> Loading Go Runtime support.
> (gdb) info files
> Symbols from "/Users/changkun/Desktop/demo/main".
> Local exec file:
> `/Users/changkun/Desktop/demo/main', file type mach-o-x86-64.
> Entry point: 0x1049e20
> 0x01001000 - 0x0104dfcf is .text
> 0x0104dfe0 - 0x01077344 is __TEXT.__rodata
> (...)
> (gdb) b *0x1049e20
> Breakpoint 1 at 0x1049e20
> (gdb)
>
>
> There is no `at` in the GDB outputs, the version of Go is `go version 
> go1.11 darwin/amd64` and:
>
> $ ls -al /usr/local/bin | grep go
> lrwxr-xr-x1 changkun  admin24 Aug 25 16:37 go -> ../Cellar
> /go/1.11/bin/go
>
>
>
> ==
>
> Same process in linux environment:
>
> docker run -it --rm --name golang golang:1.11 bash
>
> then entering container install `gdb`
>
> root@1326d3f1a957:/# gdb main
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> (...)
> (gdb) info files
> Symbols from "/main".
> Local exec file:
> `/main', file type elf64-x86-64.
> Entry point: 0x44a2e0
> 0x00401000 - 0x0044ea8f is .text
> (...)
> (gdb) b *0x44a2e0
> Breakpoint 1 at 0x44a2e0: file 
> /usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.
> (gdb)
>
>
> Linux is able to show with a breakpoint, `(gdb) b *0x44a2e0
> Breakpoint 1 at 0x44a2e0: file 
> /usr/local/go/src/runtime/rt0_linux_amd64.s, line 8.`
>
> What did I do wrong on macOS? How can I perform low-level debugging for Go 
> programs on macOS with GDB?
>

-- 
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] Re: Compile to go languages?

['David Chase' via golang-nuts]

It's not a bad idea, except for the "idiomatic" part.  I guess it depends 
upon how idiomatic you want it to be.

Once upon a time, we compiled code to C (C++, Modula-3, and Cedar Mesa all 
had a compiler of that sort at one time or another).
Some people tried it for Java.

The advantage of targeting Go is that you get a low-latency GC and 
lightweight threads (Goroutines) "for free", as well as a decent bit of 
support for reflection, and the compiler will do a certain amount of escape 
analysis for you.
You might, for example, use goroutines to parallelize whole-array 
operations, if your source language had those (e.g.,m Fortran).

The disadvantage of targeting Go is that it's not that friendly to certain 
type systems, and you don't want to get into too much of a fight with the 
type system.
So Java would probably be a poor choice for a source language.  Smalltalk 
also might not work so well.


On Monday, August 13, 2018 at 6:48:59 PM UTC-4, Andrew Chambers wrote:
>
> Don't get me wrong, I love go, but also wonder if there are any languages 
> that compile to idiomatic go.
> I noticed reasonml compiles to javascript, and wondered to myself if there 
> is any value in such languages using go as a base for 
> interop to take advantage of the libraries and runtime.
>
> Any existing projects? Any thoughts about why its a good or bad idea, or 
> why it doesn't seem to exist already?
>

-- 
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] oksvg and rasterx; SVG 2.0 path compliant renderer and rasterizer

['David Chase' via golang-nuts]

On Tuesday, April 24, 2018 at 10:45:35 AM UTC-4, matthe...@gmail.com wrote:
>
> I’m curious if some companies juggle the GPL. I guess if the app is used 
> internally only then there’s no problem with accidentally requiring a 
> proprietary program to be released as source code to the world. I’d have 
> thought the case would be the same with the AGPL. Do people count as 
> individuals in a corporate license with the ability to freely redistribute?
>
> I can understand completely avoiding the issue. Language is interpretable 
> and only a court or whatever would decide what was really agreed to. The 
> FSF seems to put a lot of work into building up their licenses with legal 
> precedence.
>

I have never worked anywhere that could touch AGPL code.
It was at the level of "just don't, and don't waste anyone's time asking.  
Don't."
This is not legal advice, I am just telling you what the policy is/was at 
all these companies.


-- 
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] Re: All Forms of Wishful Generics

['David Chase' via golang-nuts]

I agree that this is one of the two large risks.
The other is whether the language remains comparatively easy to learn.

The next largest problem after those two is "what exactly do you mean by 
generics"?
Some people want code stenciling, like C++ (it's fast, it's easy to 
understand, code size might explode, generic methods are harder).
Some people want dictionaries (you get type checking and generic methods, 
but not too likely you get speed from specialization).
Some people think erased Java-style generics are fine (these do have issues 
with reflection, and it might look different w/o type tags).

Note that Java-style generics were supposed to be the best choice for 
old/new compatibility.

As a technical problem it is *relatively* easy.

On Monday, February 19, 2018 at 5:55:54 AM UTC-5, Doğan Kurt wrote:
>
> Generics would divide the Go community.
>
> I would probably never use it, like many people who comes to Go from C. 
> People who are already experienced Go programmers also likely to avoid it. 
> Java programmers on the other hand will surely overuse it.
>
> There it is, you have two different Go code bases that looks nothing like 
> each others. One uses Generics and the other does not. Nobody wants Go to 
> have the same fate as C++. We love how there is only one way to accomplish 
> something in Go.
>
> There are billions of lines of code written in Go. Nobody would happily 
> transform all those working codes just to use new idiomatic Go with 
> generics. I suspect even Go team would hesitate to transform all the 
> standard library.
>
> If Go team add generics to Go 2, i am afraid that Go 2 will have the same 
> fate as python 3.
>
> Let's hope it never happens.
>
> On Friday, February 16, 2018 at 7:25:35 AM UTC+1, dc0d wrote:
>>
>> All forms of generics that I would love to have in Go:
>>
>>
>> 
>>
>>

-- 
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] Re: Go Compiler How Work?!

['David Chase' via golang-nuts]

I think one of the best references to this is "BCPL: The Language and Its 
Compiler".
It is shorter than the Dragon Book, accessible, historical, and very well 
written.
I think you can find the PDF online (maybe, not sure).


On Tuesday, December 12, 2017 at 4:03:08 PM UTC-5, Compiler wrote:
>
> Hello,
> Go Compiler How Work at Last Version of GoLang?!
> i mean Go Compiler , Not GoLang.
>
> at the last version of golang. go compiler , generate c code and compile 
> using gcc?!
>
>
>
>
>
>

-- 
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] Elphaba Chess

['David Chase' via golang-nuts]

On Sunday, December 3, 2017 at 1:57:58 AM UTC-5, Ian Lance Taylor wrote:
>
> On Sat, Dec 2, 2017 at 11:37 AM,   
> wrote: 
> > 
> > Google is not going to be happy if somebody uses Go to compete against 
> > Google. 
>
> I think that Go is a nice language, but it's not so nice that it would 
> make any difference whether a Google competitor used Go or used some 
> other language.  Google does not compete at the level of programming 
> language choice. 
>

No need for the subjunctive here.  Twitch, owned by (part of?) Amazon,
uses Go, and Twitch competes with some part of Youtube.  Twitch has been
the source of some interesting bugs that we have worked hard to fix, and
some of them we're still working on.  Rhys Hiltner (of Twitch) gave a nice
talk on how he figured out these bugs at GopherCon earlier this year.
My (work, Google-owned) laptop has a Twitch sticker on it.

Beyond that, see Ian's remarks about companies being rational-mostly,
and we've got some history of how other programming languages fared
with open source and/or standardization.  We're trying to only make
new mistakes.

-- 
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] Re: Generics and readability

['David Chase' via golang-nuts]

One distinction that might be helpful is the difference between people 
using a generic data structure
and people writing a generic data structure.  It's much more important that 
the code that makes use
of generics be readable than it is that the body of the generic be 
readable; after all, the existing generic
map implementation is a mashup of compiler and runtime stuff, and few 
people expect to be reading
that.

This does require that people who use generic data structures don't feel a 
need to grovel around in the
source code to figure out how it works.  


On Thursday, August 24, 2017 at 11:14:58 AM UTC-4, JuciÊ Andrade wrote:
>
> A lot of people like Go because code is very readable even for beginners.
>
> func f(x, y int)
>
> f is a function that receives x and y as int parameters, returning 
> nothing. Simple enough.
>
> func f(x, y int) int
>
> f is a function that receives x and y as int parameters, returning yet 
> another int. Fine.
>
> func f(x, y int) (z int, err error)
>
> f is a function that receives x and y as int parameters, returning two 
> values: a first int, that we name z and an error named err. A little bit 
> weird, but ok.
>
> func (r MyType) f(x, y int) (z int, err error)
>
> f is a method for a value of type MyType, henceforth named r, that 
> receives x and y as int parameters, returning two values: a first int, that 
> we name z and an error named err. Definitely not so simple.
>
>  func (r genType1) f(x, y genType2) (z getType2, err 
> error)
>
> You must be kidding. STOP RIGHT THERE!
>
>

-- 
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] Re: Go's scheduler always “stuck” after certain time when executing the code below

['David Chase' via golang-nuts]

Try compiling your code with -gcflags -d=ssa/insert_resched_checks/on .
You should see the scheduler thrashing stop, at the expense of some loop 
overhead.
(The simpler the loop, the worse the overhead, that is why this phase is 
not normally enabled.
We're working on the overhead issues, they've not been easy so far.)

On Tuesday, June 20, 2017 at 11:40:12 PM UTC-4, Ronald wrote:
>
> Hi, I found when running this code below (play 
> ):
>
>
> package main
> import "fmt"
> import "runtime"
> import "time"
> type callRet struct {
> ret int
> }
> type callIn struct {
> ret_chan chan *callRet
> arg1 int
> }
> func caller(call_in_c chan *callIn, arg1 int) int {
> ret_c := make(chan *callRet, 1)
> ci := callIn{ret_c, arg1}
> t1 := time.Now().UnixNano()
> call_in_c <- 
> ret := <-ret_c
> t2 := time.Now().UnixNano()
> _, _ = t1, t2
> //fmt.Println(t2, t1, float64(t2-t1)/1e6)
> return ret.ret
> }
> func call_srv(call_in_c chan *callIn) {
> //runtime.LockOSThread()
> ct := 0
> for {
> select {
> case in := <-call_in_c:
> ret_c := in.ret_chan
> ret := callRet{3 + in.arg1}
> ret_c <- 
> ct++
> if ct%1000 == 0 {
> fmt.Println(ct)
> }
> //default:
> // time.Sleep(1 * time.Millisecond)
> }
> }
> //runtime.UnlockOSThread()
> }
> func init() {
> //runtime.LockOSThread()
> }
> func main() {
> p := fmt.Println
> runtime.GOMAXPROCS(5)
> call_in_c := make(chan *callIn, 2000)
> fp := func(call_in_c chan *callIn) {
> ct := 0
> for ; ct < 200; ct = ct + 1 {
> caller(call_in_c, 1)
> time.Sleep(100 * time.Nanosecond)
> }
> p("done:)")
> }
> go fp(call_in_c)
> go fp(call_in_c)
> go func() {
> for {
> fmt.Println("heartbeat...")
> time.Sleep(10 * 1000 * time.Microsecond)
> }
> }()
>
>// after delete this little piece code, it will be ok
>
> go func() { 
> for {
> }
> }()
>
>// -^
>
> call_srv(call_in_c)
> return
> }
>
> It will always “stuck” in certain time after start executing (tested in 
> both go 1.7 , 1.8.1 and 1.8.3, 
> and you should run it on your own computer, not on the play because it 
> would cost several seconds). 
> I have checked the code above dozens of times at least and sure it is all 
> right.
>
> I tried to attach the go process with gdb when it is stuck and the `bt` 
> yielded this:
>
>
>> (gdb) info goroutines
>>   1 waiting  runtime.gopark
>>   2 waiting  runtime.gopark
>>   3 waiting  runtime.gopark
>>   4 waiting  runtime.gopark
>>   5 waiting  runtime.gopark
>> * 6 running  runtime.systemstack_switch
>>   7 waiting  runtime.gopark
>> * 8 running  main.main.func3
>>   17 runnable runtime.exitsyscall
>>   33 waiting  runtime.gopark
>>   18 waiting  runtime.gopark
>>   49 waiting  runtime.gopark
>>   50 waiting  runtime.gopark
>>   51 waiting  runtime.gopark
>> (gdb) goroutine 6 bt
>> #0  runtime.systemstack_switch () at 
>> /usr/local/go/src/runtime/asm_amd64.s:281
>> #1  0x00415088 in runtime.gcStart (mode=0, forceTrigger=false)
>> at /usr/local/go/src/runtime/mgc.go:1010
>> #2  0x0040d841 in runtime.mallocgc (size=96, typ=0x4a7fa0, 
>> needzero=true,
>> ~r3=0x507998 ) at 
>> /usr/local/go/src/runtime/malloc.go:785
>> #3  0x0040df68 in runtime.newobject (typ=0x4a7fa0, ~r1=0x0)
>> at /usr/local/go/src/runtime/malloc.go:820
>> #4  0x004035d2 in runtime.makechan (t=0x492960, size=1, 
>> ~r2=0xc4200016c0)
>> at /usr/local/go/src/runtime/chan.go:92
>> #5  0x004840e4 in main.caller (call_in_c=0xc420056060, arg1=1, 
>> ~r2=0)
>> at /root/go/src/chan/x.go:18
>> #6  0x004846ac in main.main.func1 (call_in_c=0xc420056060) at 
>> /root/go/src/chan/x.go:62
>> #7  0x0044da21 in runtime.goexit () at 
>> /usr/local/go/src/runtime/asm_amd64.s:2197
>> #8  0x00c420056060 in ?? ()
>> #9  0x in ?? ()
>
>
>
>

-- 
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] Why golang garbage-collector not implement Generational and Compact gc?

['David Chase' via golang-nuts]

See also: Norman R. Nielsen. Dynamic memory allocation in computer 
simulation. Communications of the ACM, 20(11):864–873, November 1977.
This was the first place I saw this result.  A later improvement was 
realizing this allowed headerless BIBOP organization of allocated memory.

I think the first malloc/free-compatible GC/allocator that used BIBOP like 
this was the Boehm-Weiser conservative collector:
Hans Boehm and Mark Weiser. Garbage collection in an uncooperative 
environment. Software, Practice and Experience, pages 807–820, September 
1988.
I used the technique in a performance-tuned malloc at Sun back in the early 
90s, and its fragmentation was entirely acceptable;
not as good as Cartesian trees (best non-compacting fragmentation at the 
time) but not much worse, and far faster.

On Tuesday, May 16, 2017 at 3:26:42 PM UTC-4, Rick Hudson wrote:
>
> The Johnstone / Wilson paper "The memory fragmentation problem: solved?" 
> [1] is the original source.
>
> Modern malloc systems including Google's TCMalloc, Hoard [2], and Intel's 
> Scalable Malloc (aka Mcrt Malloc [3]) all owe much to that paper and along 
> with other memory managers all segregate objects by size. Many languages, 
> most notable C/C++, use these fragmentation avoidance memory managers to 
> build large system without the need for copy compaction.
>
> [1] Mark S. Johnstone and Paul R. Wilson. 1998. The memory fragmentation 
> problem: solved?. In Proceedings of the 1st international symposium on 
> Memory management (ISMM '98). ACM, New York, NY, USA, 26-36. DOI=
> http://dx.doi.org/10.1145/286860.286864
>
> [2] Emery D. Berger, Kathryn S. McKinley, Robert D. Blumofe, and Paul R. 
> Wilson. 2000. Hoard: a scalable memory allocator for multithreaded 
> applications. SIGPLAN Not. 35, 11 (November 2000), 117-128. DOI=
> http://dx.doi.org/10.1145/356989.357000
>
> [3] Richard L. Hudson, Bratin Saha, Ali-Reza Adl-Tabatabai, and Benjamin 
> C. Hertzberg. 2006. McRT-Malloc: a scalable transactional memory allocator. 
> In Proceedings of the 5th international symposium on Memory management 
> (ISMM '06). ACM, New York, NY, USA, 74-83. DOI=
> http://dx.doi.org/10.1145/1133956.1133967
>
> On Tuesday, May 16, 2017 at 12:48:38 PM UTC-4, Zellyn wrote:
>>
>> Thanks for the enlightening and interesting reply, Ian.
>>
>> One quick question: do you have a link or a short description of why 
>> “modern memory allocation algorithms, like the tcmalloc-based approach used 
>> by the Go runtime, have essentially no fragmentation issues”?
>>
>> I was curious, but a quick search for [tcmalloc fragmentation] yielded 
>> mostly people struggling with fragmentation issues when using tcmalloc.
>>
>> Zellyn
>>
>>

-- 
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] Re: Some best practices for debuging and optimizing with -gcflags?

['David Chase' via golang-nuts]

Goal "best" practice is that there is no need to tinker with -gcflags, and
this is already true for optimization.

In practice -gcflags -N tends to make the generated code easier to debug,
but that is a sort of a bug that we're trying to fix by improving the 
compiler's
Dwarf generation skills.

On Monday, February 27, 2017 at 7:17:39 PM UTC-5, jamalsm...@gmail.com 
wrote:
>
> What are some best practices for general purpose -gcflags to use for 
> debugging and conversely for optimizing code?
>

-- 
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] why "iota"?

['David Chase' via golang-nuts]

If you're looking for Greek pronunciation of Greek letters, there's this:
https://www.youtube.com/watch?v=vPEtRc05G7Q
which agrees with what I learned in high school (and what is now stuck in 
my head).

On Saturday, April 27, 2013 at 8:52:36 PM UTC-4, mb0 wrote:
>
> > Wikipedia says it's a greek alphabet that looks like i, and I am seeing 
> > APL used iota for something like range() in python, which makes 
> > go-lang's use of iota a bit different from that in APL. 
> > 
> > iota sounds cool, and I like it, but I wonder if that coolness was the 
> > primary reason behind the name of an important language construct, or 
> > there are some relevant legacy behind the character. 
>
> from http://en.wiktionary.org/wiki/iota#Noun 
> ... 2. A jot; a very small, inconsiderable quantity. 
>
> hope that helps to clarifies it 
>
>

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