Re: [go-nuts] Recursive type definition

[Max]

The package go/types, which can represent Go types,
represents recursive types with cycles.

It also has explicit code to detect and handle such cycles when comparing 
types
for identity, assignability, etc.

Go compiler represents type with a different package, internal to Go 
compiler which is not importable
by user code - but my guess is that it uses the same technique.



On Tuesday, May 4, 2021 at 3:09:39 PM UTC+2 jesper.lou...@gmail.com wrote:

> On Tue, May 4, 2021 at 1:16 AM Delta Echo  wrote:
>
>> > Not sure what "handle" means in this case.
>>
>> I want to know how this is implemented.
>>
>> At some point in the compiler, you have type erasure, and you have an 
> untyped language. From there on, it's a function pointer / label. And you 
> allow for it to be nil, because the type is really a nil-able type[1]. At 
> this point, you don't have to worry about types: it already passed the type 
> checker so the program is sound. If you are interested in the type-level 
> implementation, the background is usually that of recursive types and their 
> treatment. That is the code will implement the theory of recursive types. 
> There are two overarching ways we currently know of which makes the system 
> sound: equi-recursion and iso-recursion.
>
> In the equirecursive scheme, you essentially take the limit (limes) of the 
> infinite rollout of the type and define that as the canonical 
> representation. You then "equi"-valize the types and make them all equal to 
> this limit-type, so they are the "same". It corresponds to having a cycle 
> in a representation graph, and you define running an "infinite amount of 
> times around the cycle" as your type.
>
> In the isorecursive scheme, the types are defined to be different but 
> "iso"-morphic, i.e., with the same structure. You have conversion 
> functions, usually called fold/unfold or roll/unroll to translate between 
> the different types, so we can "unroll" to the next isomorphic type as we 
> work through the recursion. It's kind of building the next cycle in the 
> graph on demand by asking for an unroll of the next cycle.
>
> To get there, when you have notation such as `type stateFn func(*Scanner) 
> stateFn` you treat the type identifier "stateFn" as a variable at the type 
> level, and detect it occurs inside the type definition body. The notation 
> you will see is μX. 1 + (*Scanner -> X). The mu is a binding site for the 
> X variable. it corresponds to a lambda in the lambda-calculus but at the 
> type level. The 1 is a representation of nil. + means "or". The arrow is a 
> function type from a *Scanner to an X. This makes it explicit what is going 
> on: either we are done, and return nil, or we have yet another state in the 
> state machine in which case it is represented as a function from a scanner 
> to X.
>
> To be honest, I haven't studied Go's recursive types enough to know if one 
> or the other of the above are being used. But it is very likely that one of 
> these schemes is used, perhaps in disguise. Many systems using 
> iso-recursion hide the roll/unroll functions inside other constructs of the 
> language, so the programmer doesn't have to explicitly work with the 
> isomorphism. As a general rule, the equi-recursive scheme tends to be 
> harder to work with, because the infinite expansion makes it hard to do 
> type inference and also invites algorithms to have infinite loops.
>
> Finally, if you want to pursue this to a larger extent, you will need 
> someone who treats it with more than a few paragraphs. Benjamin C. Pierce's 
> "Types and programming languages" spends an entire chapter on the above, 
> giving it proper treatment, formally. Searching for iso- and equi-recursion 
> also works, but note that people often take a lot of notation for granted 
> which means it could look like gibberish and bad handwriting (or as we tend 
> to say in Danish: feet of a crow --- it's not about eyes here).
>
> [1] Slight aside: modern compilers, that is any compiler using post ~2000 
> architecture design will type all intermediate representations as well as 
> the assembly, only performing erasure just before machine code emission. By 
> typing intermediate languages, you obtain the extra power that you can type 
> check your optimizations, catching many errors early on.
>
>

-- 
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/114b8584-4ba3-4bdc-ac06-b5d95ab63eb5n%40googlegroups.com.

Re: [go-nuts] go build error in darwin: duplicate symbol

[Max Xu]

But I didn't write cgo code in my project. 
The weird part is I can build success with *GOOS=linux go build*, but 
failed with *GOOS=darwin go build*

On Friday, March 19, 2021 at 5:11:57 AM UTC+8 Ian Lance Taylor wrote:

> On Thu, Mar 18, 2021 at 9:55 AM Max Xu  wrote:
> >
> > I'm running into a weird bug:
> >
> > Failed with command:
> > GOOS=darwin go build
> >
> > Bug success with:
> > GOOS=linux go build
> >
> > The failed Message:
> >
> > /usr/local/opt/go/libexec/pkg/tool/darwin_amd64/link: running clang 
> failed: exit status 1
> > duplicate symbol '_readdrivestat' in:
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/11.o
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/36.o
> > duplicate symbol '_get_temperature' in:
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
> > duplicate symbol '_open_smc' in:
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
> > duplicate symbol '_close_smc' in:
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
> > ld: 4 duplicate symbols for architecture x86_64
> > clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
> Hard to say without seeing the code, but my first guess would be
> erroneous cgo code. It looks like you have multiple cases of cgo code
> that are defining the same symbol in the C preamble without declaring
> it as `static`.
>
> 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/f9ac679f-09f5-44c1-826f-387b2adf2e7fn%40googlegroups.com.

[go-nuts] go build error in darwin: duplicate symbol

[Max Xu]

Hi all,

I'm running into a weird bug:

Failed with command:
GOOS=darwin go build

Bug success with:
GOOS=linux go build

The failed Message:

/usr/local/opt/go/libexec/pkg/tool/darwin_amd64/link: running clang failed: 
exit status 1
duplicate symbol '_readdrivestat' in:

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/11.o

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/36.o
duplicate symbol '_get_temperature' in:

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
duplicate symbol '_open_smc' in:

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
duplicate symbol '_close_smc' in:

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o

/var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
ld: 4 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)


My Environment:

go version go1.16.2 darwin/amd64

-- 
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/3979f9aa-1f9e-43b4-b128-b06cf69bb9b5n%40googlegroups.com.

Re: [go-nuts] should I pass functions as parameter of a go routine?

[Max Renaud]

In your second example, the address of wg doesn't change with each 
iteration so you can use:
for _, onedoer := range d {
go func(od *doer) {
od.do()
}(onedoer)
}
https://play.golang.org/p/A1dAUuyvg9T


On Thursday, March 4, 2021 at 8:50:19 AM UTC-8 Julien Pivotto wrote:

> Thank you for your quick answer, it is of a great help.
>
> have a nice day.
>
> On Thursday, March 4, 2021 at 5:11:40 PM UTC+1 axel.wa...@googlemail.com 
> wrote:
>
>> Interesting question. I think the code is fine. From the spec 
>> :
>>
>> > The function value and parameters are evaluated as usual in the calling 
>> goroutine, but unlike with a regular call, program execution does not wait 
>> for the invoked function to complete.
>>
>> This means `onedoer.do` is immediately evaluated, before the loop 
>> continues. The usual issue with loops is due to closures. So, this would be 
>> wrong and have exactly the issue you are worried about:
>>
>> for _, onedoer := range d {
>> go func() { oneoder() }
>> }
>>
>> But the go statement isn't equivalent to that, it doesn't close over the 
>> function value, it evaluates it.
>>
>> On Thu, Mar 4, 2021 at 5:01 PM Julien Pivotto  
>> wrote:
>>
>>> Hello,
>>>
>>> In the following example: https://play.golang.org/p/yz_ifHC-Hut
>>>
>>> for _, onedoer := range d {
>>>   go onedoer.do()
>>> }
>>>
>>> Should I pass the function onedoer.do as a parameter of the go routine:  
>>> https://play.golang.org/p/WHPahoayDbM ?
>>>
>>> for _, onedoer := range d {
>>>   go func(od *doer, w *sync.WaitGroup) {
>>> od.do(w)
>>>   }(onedoer, )
>>> }
>>>
>>> I am wondering if `go func()` could return before figuring out which 
>>> function to run, creating a race with the loop.
>>>
>>>
>>> Thanks in advance!
>>>
>>> -- 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/6547c92f-a009-4fd4-abb2-801b2c44ea67n%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/a9aecf32-556d-4b3f-862f-0f979e6194d8n%40googlegroups.com.

[go-nuts] Re: Java version of keydb

[max...@gmail.com]

i can not open the java version link https://github.com/robaho/jkeydb . 
it's returns 404 code

On Saturday, December 12, 2020 at 10:04:42 PM UTC+3 ren...@ix.netcom.com 
wrote:

> Hi all,
>
> I thought this might be of interest to some. I released a Java version of 
> keydb  at jkeydb 
> . I primarily did the exercise to keep 
> my Java skills fresh and do an updated performance comparison between Go 
> and Java.
>
> Tests performed using OSX Big Sur.
>
> Using Go 1.15.5:
>
> insert time  1000 records =  24670 ms, usec per op  2.4670965
> close time  16945 ms
> scan time  10631 ms, usec per op  1.063149
> scan time 50%  470 ms, usec per op  0.941686
> random access time  9.658001 us per get
> close with merge 1 time  0.681 ms
> scan time  11253 ms, usec per op  1.1253718
> scan time 50%  471 ms, usec per op  0.942876
> random access time  9.702651 us per get
>
> Using Java 1.15:
>
> insert time 1000 records = 24102ms, usec per op 2.4102
> close time 13564ms
> scan time 10259ms, usec per op 1.0259
> scan time 50% 474ms, usec per op 0.948
> random access time 13.209us per get
> close with merge 1 time 0ms
> scan time 10142ms, usec per op 1.0142
> scan time 50% 501ms, usec per op 1.002
> random access time 13.28us per get
>
> Performance is very similar, except that Go is significantly faster in the 
> random access tests. I attribute this to the JNI overhead in making lots of 
> small IO requests. In a previous life I wrote some custom JNI code for 
> ultrafast IO and I might resurrect that to see if it makes a difference.
>
> You can vary the ‘keyIndexInterval’ to trade memory for speed which 
> significantly helps the Java version by reducing the IO.
>
> There are significantly fewer source (non test) code files in the Go 
> version, 10 vs. 26 which highlights the simplicity of Go.
>
> Anyway, feel free to ask any questions if you wish.
>
>
>

-- 
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/3ea0dd7a-f7bb-46a5-b036-0f464f71761en%40googlegroups.com.

[go-nuts] Re: CSS-like selectors for Go AST?

[Max]

Yes, it could be extracted to a separate module, but package  
github.com/cosmos72/gomacro/ast2 already has very few dependencies.
In particular, it does *not* depend on the Go interpreter 
github.com/cosmos72/gomacro/fast

The integer arguments are simple:
`y.Get(0)` means "get the first (index = 0 ) child node of y"
`y.Get(1)` means "get the second (index = 1) child node of y"
and so on.

The interface `ast2.Ast` also has methods to query the number of children, 
and to modify the AST:
```
type Ast interface {
Interface() interface{}
Op() token.Token
Size() int
Get(i int) Ast
Set(i int, child Ast)
New() Ast // returns a copy of Ast. the children are not copied
}
```

On Wednesday, October 14, 2020 at 8:06:57 PM UTC+2 cpu...@gmail.com wrote:

> Hi Max,
>
> Great answer, thank you! Exactly what I was looking for in terms of a 
> fluid api, no need for parsing the selectors.
>
> The API is not quite suitable for public consumption. I feel this could be 
> a great success if extracted into its own module.
> Could you kindly clarify what the meaning of the int parameters is, i.e. 
> is there a general rule or does it depend on the function?
>
> I‘ll play a bit with it and will comment on GH if ok.
>
> Much appreciated,
> Andi
>
> On Wednesday, October 14, 2020 at 6:09:08 PM UTC+2 Max wrote:
>
>> I can only agree, traversing or navigating Go AST is cumbersome for at 
>> least two reasons:
>> 1. each type has its own fields - no uniform API is available
>> 2. you often need type assertions on fields because they have interface 
>> type instead of concrete type
>>
>> I developed a wrapper around them to mitigate these problems for my Go 
>> interpreter https://github.com/cosmos72/gomacro
>> If you are interested, it is the package 
>> https://github.com/cosmos72/gomacro/tree/master/ast2
>>
>> You may find it helps by providing an uniform API and removing the need 
>> for type assertions, but it still requires compile-time code,
>> not CSS-style strings that can be created at runtime.
>>
>> A quick example:  this uses plain go/ast
>> ```
>> package main
>> import (
>> "fmt"
>> "go/ast"
>> "go/parser"
>> )
>> func main() {
>> x, _ := parser.ParseExpr("foo[1 + 2 * 3]")
>> // we want to extract the "3"
>> var three string = 
>> x.(*ast.IndexExpr).Index.(*ast.BinaryExpr).Y.(*ast.BinaryExpr).Y.(*ast.BasicLit).Value
>> fmt.Printf("%s\n", three) // prints 3
>> }
>> ```
>> while this is the equivalent using github.com/cosmos72/gomacro/ast2
>> ```
>> package main
>> import (
>> "fmt"
>> "go/ast"
>> "go/parser"
>> "github.com/cosmos72/gomacro/ast2"
>> )
>> func main() {
>> x, _ := parser.ParseExpr("foo[1 + 2 * 3]")
>> y := ast2.AnyToAst(x, nil) // wrap the existing AST. does not 
>> allocate memory.
>> 
>> ythree := y.Get(1).Get(1).Get(1) // extract the "3" as ast2.Node
>>
>> // now unwrap it, getting the *ast.BasicLit and the Value inside it
>> var three string = ast2.ToBasicLit(ythree).Value
>> fmt.Printf("%s\n", three) // prints 3
>> }
>> ```
>>
>> On Tuesday, October 13, 2020 at 9:37:21 AM UTC+2 cpu...@gmail.com wrote:
>>
>>> Good morning.
>>>
>>> I've recently found myself writing a code generator for dynamic 
>>> interface composition at runtime. It became ugly and I had to pass in quite 
>>> a number of parameters that should have been available from reading the 
>>> source code.
>>>
>>> In a second attempt I've reimplemented the generator using stringer-like 
>>> AST handling. It worked well but was cumbersome to code.
>>>
>>> Now an idea surfaced: wouldn't it make sense to implement a selector 
>>> interface on top of the golang AST, something like CSS or JQ selectors but 
>>> targeted at the go language constructs? I've stumbled across Guru but it 
>>> does seem to target a slightly different use case.
>>>
>>> Is anybody aware of such a selector lib/module or does the idea even 
>>> sound interesting?
>>>
>>> Cheers,
>>> Andi
>>>
>>

-- 
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/a335ed5e-782b-4f55-baf3-e801b9b9f007n%40googlegroups.com.

[go-nuts] Re: Any embedded scripting language for Go

[Max]

It's also possible to embed a Go interpreter in a Go App - in this way, the 
scripting language is Go itself.

There are several fairly complete Go interpreters around, including at 
least:
https://github.com/cosmos72/gomacro (disclaimer: I am the author)
https://github.com/traefik/yaegi
https://github.com/yunabe/lgo
https://github.com/motemen/gore

On Wednesday, October 21, 2020 at 7:33:16 AM UTC+2 aravind...@gmail.com 
wrote:

> Hi,
>
> I am looking for a way to build interactive app,where user will be giving 
> instructions to draw as a script,rendering of the script will be displayed 
> live.
> I would like to use below 2d drawing package for same,
> github.com/fogleman/gg
>
> Is there scripting language that would be able generate bindings to 
> arbiratory go packages back and forth? and I could embed it in Go App as 
> well.
>
> Thanks,
> Aravindhan K
>

-- 
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/33fdb657-e18a-443c-98d3-0373444bd46an%40googlegroups.com.

[go-nuts] Re: CSS-like selectors for Go AST?

[Max]

I can only agree, traversing or navigating Go AST is cumbersome for at 
least two reasons:
1. each type has its own fields - no uniform API is available
2. you often need type assertions on fields because they have interface 
type instead of concrete type

I developed a wrapper around them to mitigate these problems for my Go 
interpreter https://github.com/cosmos72/gomacro
If you are interested, it is the package 
https://github.com/cosmos72/gomacro/tree/master/ast2

You may find it helps by providing an uniform API and removing the need for 
type assertions, but it still requires compile-time code,
not CSS-style strings that can be created at runtime.

A quick example:  this uses plain go/ast
```
package main
import (
"fmt"
"go/ast"
"go/parser"
)
func main() {
x, _ := parser.ParseExpr("foo[1 + 2 * 3]")
// we want to extract the "3"
var three string = 
x.(*ast.IndexExpr).Index.(*ast.BinaryExpr).Y.(*ast.BinaryExpr).Y.(*ast.BasicLit).Value
fmt.Printf("%s\n", three) // prints 3
}
```
while this is the equivalent using github.com/cosmos72/gomacro/ast2
```
package main
import (
"fmt"
"go/ast"
"go/parser"
"github.com/cosmos72/gomacro/ast2"
)
func main() {
x, _ := parser.ParseExpr("foo[1 + 2 * 3]")
y := ast2.AnyToAst(x, nil) // wrap the existing AST. does not allocate 
memory.

ythree := y.Get(1).Get(1).Get(1) // extract the "3" as ast2.Node

// now unwrap it, getting the *ast.BasicLit and the Value inside it
var three string = ast2.ToBasicLit(ythree).Value
fmt.Printf("%s\n", three) // prints 3
}
```

On Tuesday, October 13, 2020 at 9:37:21 AM UTC+2 cpu...@gmail.com wrote:

> Good morning.
>
> I've recently found myself writing a code generator for dynamic interface 
> composition at runtime. It became ugly and I had to pass in quite a number 
> of parameters that should have been available from reading the source code.
>
> In a second attempt I've reimplemented the generator using stringer-like 
> AST handling. It worked well but was cumbersome to code.
>
> Now an idea surfaced: wouldn't it make sense to implement a selector 
> interface on top of the golang AST, something like CSS or JQ selectors but 
> targeted at the go language constructs? I've stumbled across Guru but it 
> does seem to target a slightly different use case.
>
> Is anybody aware of such a selector lib/module or does the idea even sound 
> interesting?
>
> Cheers,
> Andi
>

-- 
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/4af9f13d-6f41-45ff-80e9-e9dd77bd7b92n%40googlegroups.com.

Re: [go-nuts] Go 2 review process

[Max]

I have a proposal for improving Go proposal procedure.

It stems from two "issues" highlighted in several occasions:

   1. core Go team is spending an increasing amount of time discussing a 
   larger number of proposals.
   All of them are commented and discussed by core Go team, and in the end 
   most of them are declined.
   
   2. participation of Go community at large to the proposal procedure is 
   limited:
   single individuals can create new proposals or comment on them, but 
   there is no concept of "community support" or "community effort"

In short, there is no *filter* between single individuals and core Go team.
Direct communication is good in a small group, but it does not scale to 
large groups.

My proposal is conceptually simple:
delegate some power (rights) and responsibility (duties) to the 
community.

How? I propose the following:

1. proposals must collect enough "community support" before being evaluated 
by core Go team.
   Initially, this can be as simple as waiting for enough thumbs up (and 
fewer thumbs down) on the corresponding github issue.
   If/when need arises, it may also become a more formal process.

   The core Go team will have less work:
 they would be *required* to evaluate only those with enough "community 
support", not *all* proposals as they do now.
 Of course they will still be free to evaluate also other proposals if 
they want, but they will not be required to.

   The Go community would be empowered by this change:
 it will have a more active role, acting as a first filter for 
proposals,
 and a proposal with strong community support should receive more focus 
from core Go team
 than a proposal with weak (or no) community support.

   This may require a web page that lists active proposals (is it allowed 
to scrape github content?),
   with mechanisms to filter them by keyword(s) and sort them at least by 
date/thumbs up/thumbs down.

2. proposals must follow a template, which contains at least:
 
   a. the list of existing similar proposals and, if they were not 
approved, the reasons why the new proposal
  is believed to be better
 
   b. a first evaluation of pros and cons

   This is expected to improve the quality of new proposals, by doing a 
basic background check of prior art
   and a first (self) evaluation.



On Friday, July 17, 2020 at 7:54:46 PM UTC+2, Ian Lance Taylor wrote:
>
> On Fri, Jul 17, 2020 at 10:20 AM medienwer...@gmail.com 
> > wrote: 
> > 
> > With your considerations in mind I suggest a well defined triage 
> mode/"traffic light" - system for processing language feature proposals. 
> > 
> > When your/the teams bias is clear, the indication shows the proposer/the 
> community feasible and/or practicable "next steps". 
> > 
> > Also a collection of "reference cases" can guide the growing number of 
> gophers, viable ideas and solutions. 
> > 
> > Following posts explain the needs: 
> > 
> > https://blog.golang.org/toward-go2 
> > 
> > https://blog.golang.org/experiment 
> > 
> > https://blog.golang.org/go2-here-we-come 
>
> Thanks for the suggestion.  However, I don't understand how to make 
> that work in practice.  Who is going to take the time to show feasible 
> and practical next steps for each proposal?  How is that different 
> from what we have been doing for the last year? 
>
> 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/25f267d8-9d90-4a92-9435-04c5d958dc0do%40googlegroups.com.

Re: [go-nuts] Re: Generics and parentheses

[Max]

I think square brackets are better than parentheses for several reasons:

1. fewer parser ambiguities (see the post that started this thread) - thus 
fewer cases where programmers must remember "oh, this is a special case, I 
must put additional parentheses somewhere"
2. programmers can distinguish more easily between a template instantiation 
`T1[T2]` and a function call `T1(T2)`. Index expressions would have the 
same syntax as single-type template instantiations `T1[T2]`, but I believe 
they are somewhat less common than function calls in most code
3. Go already uses a similar syntax for builtin types: `map[K]V`. A generic 
key/value container would look like `Map[K, V]` which is pretty close

In my Go interpreter, I went a step further and implemented the syntax 
`T1#[T2, T3]` for generics instantiation. It may not be everybody's 
favorite, but removes all parsing ambiguities.

An alternative syntax, more similar to other proposals I have seen, is 
`T1:[T2, T3]` - it could be visually better, but I think it introduces 
ambiguities in `case` and labels marking `goto` destinations - both already 
use ':' as delimiter.

On Wednesday, July 15, 2020 at 6:14:31 AM UTC+2, Ian Lance Taylor wrote:
>
>
> The advantage of parentheses is that the language already uses 
> parentheses for lists in various places.  Of course that is also the 
> disadvantage. 
>
> When considering something other than parentheses, I encourage people 
> to look for objective reasons why one syntax is better than another. 
> It's going to be different from other aspects of the language.  So 
> what reason would we have for preferring one syntax over another? 
>
> For example: 
>
> Robert already gave reasons why square brackets are better than angle 
> brackets. 
>
> The disadvantage of guillemets is that they are hard to type on many 
> keyboards.  So to me either square brackets or angle brackets would be 
> better than guillemets. 
>
> The disadvantage of a two character sequence such as <: :> is that it 
> is more typing.  So again either square brackets or angle brackets 
> seem to me to be better. 
>
> An example of a reason that square brackets might be a poor choice 
> would be ambiguous parsing, or cases where the code is harder to read. 
>
> It's true that some other languages use angle brackets, but Go already 
> does many things differently.  That is only a minor advantage for 
> angle brackets.  To me at least it does not outweigh the 
> disadvantages. 
>
> In short, please try to provide reasons for a different syntax.  "It 
> looks good" is a valid reason, but please try to explain why it looks 
> better than square brackets or parentheses. 
>
> Thanks. 
>
> 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/1e8397a5-bcc9-48b8-924b-1d35f4434d14o%40googlegroups.com.

[go-nuts] Re: [generics] Zero value

[Max]

Types are not first-class in Go, thus T.someMethod() is somewhat an unusual 
syntax.

The proposal  to use 'T{}' to 
mean zero value of T breaks Go compatibility promise:
if T is a map type or a slice type, 'T{}' already has a meaning:
create a non-nil, zero-elements map (or slice).
Instead the zero value of such types is nil.

Using '_' could be an elegant solution in places where type inference can 
deduce the correct type.

Two more ideas that I did not see yet are:
1. use 'T()' to mean zero value of T - currently does not compile, thus Go 
compatibility promise is preserved.
2. define a new compiler builtin 'zero(T)'

On Friday, June 19, 2020 at 1:59:59 PM UTC+2, Ivan Ivanyuk wrote:
>
> What about something like int.CreateZeroValue(), or T.CreateZeroValue() 
> and CreateZeroValueInterface?
>
> On Thursday, June 18, 2020 at 7:34:55 PM UTC+3, bruno...@gmail.com wrote:
>>
>> First, congratulations on the working compiler! Very cool to try out 
>> generics in Go.
>>
>> I was experimenting  with 
>> some simple generic functions and felt the need for the zero value of a 
>> generic type. I've read the discussion anticipated in your proposal 
>> ,
>>  
>> so I'd like to use this topic just to provide my sentiment, and perhaps 
>> gather it from others.
>>
>> In my opinion, the most Go-like proposal 
>>  is using '_' to signify the 
>> zero value in RHS. We are already used to having '_' in LHS to accept 
>> whatever type, and although the meaning is slightly changed (from 
>> 'whatever' to 'zero'), it's conceptually close.
>>
>> I'm opposed to a change that uses '{}' or 'T{}' to mean zero type, as in 
>> this proposal , because in my 
>> mind curly braces are used for composite types. Imagining that 'T' is a 
>> placeholder, It's weird replacing 'T{}' for 'int{}', for example. I'm super 
>> in favor of having a leaner syntax for composite types, though .
>>
>> Whatever is decided, please don't punt on this issue and recommend 
>> '*new(T)'. That's really ugly and feels wrong to allocate and immediately 
>> dereference the value just to circumvent a syntax change. Even if the 
>> compiler is smart enough not to allocate anything, that's what's written in 
>> the source code.
>>
>> Thanks.
>>
>

-- 
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/ab0248d6-c292-4e22-a1bd-b5d0b0df6aeeo%40googlegroups.com.

[go-nuts] Re: go/types: types.Named hides intermediate names

[Max]

Addendum:

this may be surprising from the point of view of object-oriented 
programming, class inheritance etc.
but at risk of stating the obvious, in Go there is no class inheritance:
type X time.Time

creates a new type X that is (almost) completely unrelated to time.Time:
1. the new type X does not have the methods of time.Time,
2. and X cannot be used interchangeably with time.Time.

So it makes sense that `types.Type` does not provide any information to 
link them.

the only connection is their identical underlying type, which allows to 
*explicitly* convert between them, i.e. the following works:
var x X
var t time.Time = time.Time(x)
var x2 X = X(t)



On Wednesday, November 20, 2019 at 12:18:28 PM UTC+1, Max wrote:
>
>
> It's part of the language specifications https://golang.org/ref/spec#Types. 
> It says:
> type (
>   B1 string
>   B2 B1
> )
>
> "The underlying type of [...] B1 and B2 is string"
>
> In other words, when you write 
> type X time.Time
> there is absolutely *no direct* connection between the types X and 
> time.Time:
> the only connection is that they both have the same *underlying* type, 
> which is some unnamed struct, as you wrote.
>

-- 
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/934eec83-597f-4861-b9bb-71e4846cbe2d%40googlegroups.com.

[go-nuts] Re: go/types: types.Named hides intermediate names

[Max]

It's part of the language specifications https://golang.org/ref/spec#Types. 
It says:
type (
  B1 string
  B2 B1
)

"The underlying type of [...] B1 and B2 is string"

In other words, when you write 
type X time.Time
there is absolutely *no direct* connection between the types X and 
time.Time:
the only connection is that they both have the same *underlying* type, 
which is some unnamed struct, as you wrote.

On Tuesday, November 19, 2019 at 7:10:44 PM UTC+1, Stephen Searles wrote:
>
> I'm not sure if this could be considered a bug or not, but it's 
> unfortunate behavior for certain patterns of type analysis. The problem is 
> with a type like:
>
> type X time.Time
>
> When you inspect type X, you find that it is analyzed as a types.Named. 
> Its immediate underlying type is a types.Struct. I have a few problems with 
> this:
>
>- This hides the fact that there is more information about type X 
>available (time.Time's documentation) 
>- This makes the location and identity of the actual struct definition 
>hard to find because the types.Struct is not an object that you can find 
>the source position of
>- The dependency relationship between these types is not obvious (as 
>in, changing/renaming time.Time will affect the program using X, but not 
>the other way around)
>
> Here's a small demo of the situation described here: 
> https://play.golang.org/p/oqYRDIO7kmf
>
> Please let me know if I'm something missing, but as it stands, I think the 
> only way around these issues would be to analyze the syntax of every 
> defined type to check if it's got an underlying name or not. Does this 
> sound like something that could be safely improved within go/types? 
>
> Thanks,
> Stephen
>

-- 
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/b5bf0606-cd00-4299-b52f-804b2993efcd%40googlegroups.com.

[go-nuts] Re: Any way to print a 'struct g' within delve/gdb

[Max]

I just tried with latest delve, and 'p runtime.m0.curg' is enough:

(dlv) p runtime.m0.curg
*runtime.g nil
(dlv) break main.main
(dlv) continue
[...]
(dlv) p runtime.m0.curg
*runtime.g {
stack: runtime.stack {lo: 824635269120, hi: 824635285504},
stackguard0: 82463527,
stackguard1: 18446744073709551615,
_panic: *runtime._panic nil,
_defer: *runtime._defer {
siz: 8,
started: false,
sp: 824635285400,
pc: 4406401,
fn: *(*runtime.funcval)(0xd49398),
_panic: *runtime._panic nil,
link: *runtime._defer nil,},
m: *runtime.m {
g0: *(*runtime.g)(0x1493020),
morebuf: (*runtime.gobuf)(0x1493b08),
divmod: 0,
procid: 8426,
gsignal: *(*runtime.g)(0xc0),
goSigStack: (*runtime.gsignalStack)(0x1493b58),
sigmask: runtime.sigset [0,0],
tls: [6]uintptr [0,0,0,0,0,0],
mstartfn: nil,
curg: *(*runtime.g)(0xc00180),
caughtsig: 0,
p: 824633933824,
nextp: 0,
oldp: 0,
id: 0,
mallocing: 0,
throwing: 0,
preemptoff: "",
locks: 0,
dying: 0,
profilehz: 0,
spinning: false,
blocked: false,
inwb: false,
newSigstack: true,
printlock: 0,
incgo: false,
freeWait: 0,
fastrand: [2]uint32 [1474176035,2600743942],
needextram: false,
traceback: 0,
ncgocall: 1,
ncgo: 0,
cgoCallersUse: 0,
cgoCallers: *runtime.cgoCallers 
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
park: (*runtime.note)(0x1493c48),
alllink: *runtime.m nil,
schedlink: 0,
mcache: *(*runtime.mcache)(0x7fc8210fe008),
lockedg: 0,
createstack: [32]uintptr 
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],
lockedExt: 0,
lockedInt: 0,
nextwaitm: 0,
waitunlockf: unsafe.Pointer(0x0),
waitlock: unsafe.Pointer(0x0),
waittraceev: 23,
waittraceskip: 3,
startingtrace: false,
syscalltick: 4,
thread: 0,
freelink: *runtime.m nil,
libcall: (*runtime.libcall)(0x1493db8),
libcallpc: 0,
libcallsp: 0,
libcallg: 0,
syscall: (*runtime.libcall)(0x1493e00),
vdsoSP: 0,
vdsoPC: 5077558,
mOS: runtime.mOS {},},
sched: runtime.gobuf {sp: 0, pc: 4586608, g: 824633721216, ctxt: 
unsafe.Pointer(0x0), ret: 0, lr: 0, bp: 824635273744},
syscallsp: 0,
syscallpc: 5004501,
stktopsp: 824635285472,
param: unsafe.Pointer(0x0),
atomicstatus: 2,
stackLock: 0,
goid: 1,
schedlink: 0,
waitsince: 0,
waitreason: waitReasonChanReceive (13),
preempt: false,
paniconfault: false,
preemptscan: false,
gcscandone: false,
gcscanvalid: false,
throwsplit: false,
raceignore: 0,
sysblocktraced: true,
sysexitticks: 0,
traceseq: 0,
tracelastp: 0,
lockedm: 0,
sig: 0,
writebuf: []uint8 len: 0, cap: 0, nil,
sigcode0: 0,
sigcode1: 0,
sigpc: 0,
gopc: 4586345,
ancestors: *[]runtime.ancestorInfo nil,
startpc: 4406160,
racectx: 0,
waiting: *runtime.sudog nil,
cgoCtxt: []uintptr len: 0, cap: 0, nil,
labels: unsafe.Pointer(0x0),
timer: *runtime.timer nil,
selectDone: 0,
gcAssistBytes: 0,}



On Tuesday, November 12, 2019 at 8:29:42 AM UTC+1, Xiangdong JI wrote:
>
> Hi Derek,
>
> Say I have the pointer value of a specific G struct, how to convert it to 
> 'struct g' (or any other form) in delve so that I can check 
> the details of its fields?
>
> For example (simply utilized runtime.m0.curg to get a pointer value here)
>
> (dlv) p 
> (**runtime.g)(0x56a140)
>
> Just tried a few commands to convert the value back to 'struct g' or a 
> pointer to 'struct g'
>
> (dlv) p (runtime.g*)(0x56b140)
> Command failed: 1:12: expected operand, found ')'
> (dlv) p ('runtime.g'*)(0x56b140)
> Command failed: 1:2: illegal rune literal
> (dlv) p ("runtime.g"*)(0x56b140)
> Command failed: 1:14: expected operand, found ')'
> (dlv) p ("runtime".g*)(0x56b140)
> Command failed: 1:14: expected operand, found ')'
>
> Thanks.
>
> On Tuesday, November 12, 2019 at 2:28:12 AM UTC+8, Derek Parker wrote:
>>
>> Can you reply with a gist showing the exact Delve commands you are 
>> attempting to use and what errors are being returned?
>>
>> There is some more information on the expression parser here 
>> . 
>> You can also open an issue on the Delve Github repo and we can help you out 
>> over there as well.
>>
>> On Sunday, November 10, 2019 at 11:58:24 PM UTC-8, Xiangdong JI wrote:
>>>
>>> Given a valid goroutine structure's pointer, say retrieving from the 
>>> register 'g', how can I convert it to 'struct g' in delve or gdb?
>>>
>>> gdb usually reports "A syntax 

[go-nuts] Re: Roadblock for user-implemented JIT compiler

[Max]

On Friday, November 1, 2019 at 8:58:13 AM UTC+1, Sokolov Yura wrote:
>
> Don't forget about calling to write barriers. 


Of course.

Second update: calling arbitrary Go functions from ARM64 JIT code works too 
:)

See https://github.com/cosmos72/gomacro/blob/master/jit/_hide_from_stack

-- 
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/a7488bd6-348f-4502-9dff-db26d3dab193%40googlegroups.com.

[go-nuts] Re: Gofmt needs to allow newline-operator

[Max]

Indeed.

It's not just a matter of gofmt: the "implicit semicolon" rule of Go syntax 
is triggered at the end of this line
```
if Variable1 == true
```
causing it to be parsed as
```
if Variable1 == true;
```
Any operator in the following line arrives too late to change that.

So to implement what you propose, Go syntax rules would need to be changed.

While they are not set in stone, the added convenience of your new syntax
is probably too small to justify a language change (just my opinion - feel 
free
to propose such a change to Go developers)


On Thursday, October 31, 2019 at 9:39:35 PM UTC+1, Ilia Choly wrote:

> Your code doesn't even compile.
>
> On Thursday, October 31, 2019 at 1:13:50 PM UTC-4, kevma...@gmail.com 
> wrote:
>>
>> I apologize for submitting yet another go format "issue". I'm more so 
>> gauging the community on this idea. Furthermore, I ask that you understand 
>> I'm not sure if this type of code format has a proper name to it, I'm just 
>> calling it "newline-operator-chain" (in contrast to 
>> "operator-newline-chain").
>>
>> ...For the record the first time I saw this type of formatting was when I 
>> was using SQL Server Management Studio 2012. It had formatted its `select` 
>> statements in a similar way. Though I normally hate Microsoft's ways of 
>> doing things newline-operator chains look much cleaner. Enough talking, 
>> it's best I just show what I mean:
>>
>>
>> operator-newline chain
>> if Variable1 == true && 
>> Variable2 == 5 &&
>> MakeSureICan() {
>> // ...
>> }
>>
>>
>>
>>
>> LotsOfArgs(myArg,
>> anotherArg,
>> bonusArg,
>> thisArgToo())
>>
>>
>> newline-operator chain
>> Much cleaner in my opinion.
>> if Variable1 == true 
>> && Variable2 == 5
>> && MakeSureICan() {
>> // ...
>> }
>>
>>
>>
>>
>> LotsOfArgs(myArg
>> , anotherArg
>> , bonusArg
>> , thisArgToo())
>>
>>
>> Why Go format needs this
>>
>> *Looks cleaner, looks simpler*
>> I believe that the newline-operator chain formatting looks niced due to 
>> the lining-up of the operators. This is nice to Go programmers like myself 
>> who are obsessed with readability. For instance, one could much understand 
>> the purpose of each argument in a faster manner when scanning through 
>> newline-operator chains as the operation is specified before the argument. 
>> Compared to operator-newline chains where the reader must look at 2 
>> separate lines to fully understand the role an argument plays in the chain.
>>
>> *Makes more mathematical sense*
>> And I think is more suitable for the underlining "mathematical" nature of 
>> operators in the first place. A good chunk of *any* programming is math, 
>> thus any language should share as many aspects with math as possible. 
>> Forcing operator-newline chain formatting disobeys this property.
>>
>> We'd see this in math:
>>2
>>  + 4
>>  + 9
>>  - 1
>> 
>>   14
>>
>>
>> not:
>>2 +
>>4 +
>>9 -
>>1
>> 
>>   14
>>
>>
>> The latter (operator-newline) looks confusing and harder to follow, the 
>> readability is lacking. Which is why I think we need to allow the former 
>> (newline-operator) in Gofmt. 
>>
>>
>> In my opinion, I think Gofmt needs to *disallow* operator-newline to 
>> achieve the highest grade of readability.
>>
>

-- 
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/3da3aaf1-de3b-422c-9dfc-7af47dd28855%40googlegroups.com.

[go-nuts] Re: Roadblock for user-implemented JIT compiler

[Max]

Update:


I found a solution using AMD64 assembly trickery to call arbitrary Go 
functions from JIT code, while the JIT code is running on the Go stack and 
accessing Go memory.


It is extremely hackish and guaranteed to break as soon as Go function call 
ABI changes.


I will try to implement the same trick in ARM64 assembler - there are 
differences, and I am not yet sure it will work.


cosmos72


On Wednesday, October 23, 2019 at 5:35:40 PM UTC+2, Max wrote:
>
> Thanks for the idea Rick,
>
> there is one detail I do not understand:
> JIT code does not have a stack map **at all**, not even an empty one, thus 
> (if I remember correctly) calling any Go function from it may trigger a GC 
> cycle, which will find on the Go stack the "unknown" return address to the 
> JIT function, and panic even though the JIT code itself does not use the Go 
> stack. How can I remove such "offending" return address from the Go stack?
>
> On Wednesday, October 23, 2019 at 5:22:35 PM UTC+2, Rick Hudson wrote:
>>
>> One approach is to maintain a shadow stack holding the pointers in a 
>> place the GC already knows about, like an array allocated in the heap. This 
>> can be done in Go, the language. Dereferences would use a level of 
>> indirection. Perhaps one would pass an index into the array instead of the 
>> pointer and somehow know the location of the shadow stack from a VM 
>> structures. This way the stack contains no pointers _into the heap_ so the 
>> _GC_ is happy. You might still have to deal with pointers to stack 
>> allocated objects since stacks can be moved and so forth but that is not 
>> the problem being discussed.
>>
>> Go the implementation, such as the Go 1.13, has a GC that does not move 
>> heap objects. This means that to keep a heap object live the GC only needs 
>> to know about a single pointer. That’s sort of handy since now you can push 
>> the pointer onto the shadow stack and also onto the call stack since as 
>> long as the shadow stack is visible the object will not be collected. I 
>> note that this involves a barrier on all pointer writes so it is more than 
>> just a change to the calling conventions. Reads on the other hand would be 
>> full speed and not require a level of indirection or barrier unless and 
>> until Go the implementation moved to a moving collector.
>>
>> I would explore this approach first since all of the pieces are under 
>> your control. Developing an ABI for stack maps would include other people 
>> with differing agendas and would likely slow you down. Likewise forking 
>> would come with the usual maintenance/merge headaches.
>>
>>
>>
>> On Wednesday, October 23, 2019 at 1:50:51 PM UTC+1, Max wrote:
>>>
>>> Hello gophers,
>>>
>>> My recent attempt at creating a JIT compiler in Go to speed up my 
>>> interpreter https://github.com/cosmos72/gomacro hit an early roadblock.
>>>
>>> In its current status, it can compile integer arithmetic and 
>>> struct/array/slice/pointer access for amd64 and arm64, but it cannot 
>>> allocate memory or call other functions, which severely limits its 
>>> usefulness (and is thus not yet used by gomacro).
>>>
>>> The reason is: there is a requirement that Go functions must have a 
>>> "stack frame descriptors registered with the runtime", in brief a "stack 
>>> map" that tells which bits on the stack are pointers and which ones are not.
>>> See https://github.com/golang/go/issues/20123 for details.
>>>
>>> But there is no API to associate a stack map to functions generated at 
>>> runtime and running on the Go stack - currently the only supported 
>>> mechanism to load Go code at runtime is to open a shared library file with 
>>> `plugin.Open()`
>>>
>>> Thus JIT-generated functions must avoid triggering the garbage 
>>> collector, as it would panic as described in the link above.
>>> In turn, this means they cannot:
>>> * allocate memory
>>> * call other functions
>>> * grow the stack
>>> or do anything else that may start the GC.
>>>
>>> Now, I understand *why* Go functions must currently have a stack map, 
>>> and I see at least two possible solutions:
>>>
>>> 1. implement an API to associate a stack map to functions generated at 
>>> runtime - possibly by forking the Go compiler and/or standard library
>>> 2. replace Go GC and allocator with an alternative that does not require 
>>> stack maps - for example Boehm GC https://www.hboehm.info/gc/
>>> Here

[go-nuts] Re: Roadblock for user-implemented JIT compiler

[Max]

Thanks for the idea Rick,

there is one detail I do not understand:
JIT code does not have a stack map **at all**, not even an empty one, thus 
(if I remember correctly) calling any Go function from it may trigger a GC 
cycle, which will find on the Go stack the "unknown" return address to the 
JIT function, and panic even though the JIT code itself does not use the Go 
stack. How can I remove such "offending" return address from the Go stack?

On Wednesday, October 23, 2019 at 5:22:35 PM UTC+2, Rick Hudson wrote:
>
> One approach is to maintain a shadow stack holding the pointers in a place 
> the GC already knows about, like an array allocated in the heap. This can 
> be done in Go, the language. Dereferences would use a level of indirection. 
> Perhaps one would pass an index into the array instead of the pointer and 
> somehow know the location of the shadow stack from a VM structures. This 
> way the stack contains no pointers _into the heap_ so the _GC_ is happy. 
> You might still have to deal with pointers to stack allocated objects since 
> stacks can be moved and so forth but that is not the problem being 
> discussed.
>
> Go the implementation, such as the Go 1.13, has a GC that does not move 
> heap objects. This means that to keep a heap object live the GC only needs 
> to know about a single pointer. That’s sort of handy since now you can push 
> the pointer onto the shadow stack and also onto the call stack since as 
> long as the shadow stack is visible the object will not be collected. I 
> note that this involves a barrier on all pointer writes so it is more than 
> just a change to the calling conventions. Reads on the other hand would be 
> full speed and not require a level of indirection or barrier unless and 
> until Go the implementation moved to a moving collector.
>
> I would explore this approach first since all of the pieces are under your 
> control. Developing an ABI for stack maps would include other people with 
> differing agendas and would likely slow you down. Likewise forking would 
> come with the usual maintenance/merge headaches.
>
>
>
> On Wednesday, October 23, 2019 at 1:50:51 PM UTC+1, Max wrote:
>>
>> Hello gophers,
>>
>> My recent attempt at creating a JIT compiler in Go to speed up my 
>> interpreter https://github.com/cosmos72/gomacro hit an early roadblock.
>>
>> In its current status, it can compile integer arithmetic and 
>> struct/array/slice/pointer access for amd64 and arm64, but it cannot 
>> allocate memory or call other functions, which severely limits its 
>> usefulness (and is thus not yet used by gomacro).
>>
>> The reason is: there is a requirement that Go functions must have a 
>> "stack frame descriptors registered with the runtime", in brief a "stack 
>> map" that tells which bits on the stack are pointers and which ones are not.
>> See https://github.com/golang/go/issues/20123 for details.
>>
>> But there is no API to associate a stack map to functions generated at 
>> runtime and running on the Go stack - currently the only supported 
>> mechanism to load Go code at runtime is to open a shared library file with 
>> `plugin.Open()`
>>
>> Thus JIT-generated functions must avoid triggering the garbage collector, 
>> as it would panic as described in the link above.
>> In turn, this means they cannot:
>> * allocate memory
>> * call other functions
>> * grow the stack
>> or do anything else that may start the GC.
>>
>> Now, I understand *why* Go functions must currently have a stack map, and 
>> I see at least two possible solutions:
>>
>> 1. implement an API to associate a stack map to functions generated at 
>> runtime - possibly by forking the Go compiler and/or standard library
>> 2. replace Go GC and allocator with an alternative that does not require 
>> stack maps - for example Boehm GC https://www.hboehm.info/gc/
>> Here too, forking the Go compiler and/or standard library if needed.
>>
>> My questions are:
>>
>> a. which one of the two solutions above is easier, and how long could it 
>> take to a full-time expert?
>> b. does anyone have an easier solution or workaround to achieve the same 
>> goal?
>>
>> Regards,
>> cosmos72
>>
>

-- 
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/af55e5f9-a4f0-4433-82fc-46dfb324ea59%40googlegroups.com.

[go-nuts] Roadblock for user-implemented JIT compiler

[Max]

Hello gophers,

My recent attempt at creating a JIT compiler in Go to speed up my 
interpreter https://github.com/cosmos72/gomacro hit an early roadblock.

In its current status, it can compile integer arithmetic and 
struct/array/slice/pointer access for amd64 and arm64, but it cannot 
allocate memory or call other functions, which severely limits its 
usefulness (and is thus not yet used by gomacro).

The reason is: there is a requirement that Go functions must have a "stack 
frame descriptors registered with the runtime", in brief a "stack map" that 
tells which bits on the stack are pointers and which ones are not.
See https://github.com/golang/go/issues/20123 for details.

But there is no API to associate a stack map to functions generated at 
runtime and running on the Go stack - currently the only supported 
mechanism to load Go code at runtime is to open a shared library file with 
`plugin.Open()`

Thus JIT-generated functions must avoid triggering the garbage collector, 
as it would panic as described in the link above.
In turn, this means they cannot:
* allocate memory
* call other functions
* grow the stack
or do anything else that may start the GC.

Now, I understand *why* Go functions must currently have a stack map, and I 
see at least two possible solutions:

1. implement an API to associate a stack map to functions generated at 
runtime - possibly by forking the Go compiler and/or standard library
2. replace Go GC and allocator with an alternative that does not require 
stack maps - for example Boehm GC https://www.hboehm.info/gc/
Here too, forking the Go compiler and/or standard library if needed.

My questions are:

a. which one of the two solutions above is easier, and how long could it 
take to a full-time expert?
b. does anyone have an easier solution or workaround to achieve the same 
goal?

Regards,
cosmos72

-- 
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/27a00830-e0aa-467f-919b-ace1a5e07e8e%40googlegroups.com.

[go-nuts] Re: go/types.Named from go/ast

[Max]

On Tuesday, October 22, 2019 at 7:26:04 AM UTC+2, Frew Schmidt wrote:
>
> Hello Gophers!
>
> I'm trying to migrate some code that uses `reflect.Type` at runtime to 
> `types.Type` from `go/ast` built ahead of time.  I got a pretty good way 
> (converted all the code and got it to successfully compile,) until I 
> realized that I hadn't been clearly thinking about the 
> `reflect.Type.Name()`/`reflect.Type.PkgPath()` 
> methods.  As far as I can tell, the closest similarity in `go/types` is 
> `*types.Named`.  I figured that the `ast` would give me values wrapped with 
> `*types.Named`, but it doesn't seem like it does.  At first I thought that 
> maybe I should be wrapping values with `types.NewNamed`, but I'd have to be 
> doing that recursively; it seems hard enough that I must be missing 
> something.
>
> Below is some example code I'm using to experiment with this:
> [...omitted...]
>

Hello Frew,

the `types.Type` API is quite complicated and significantly different from 
`reflect.Type` API, as you probably already realized:

`reflect.Type` is a single interface with lots of methods, including the 
`reflect.Type.Name()` you are interested in. Depending on the 
`reflect.Kind` stored in the `Type`, some methods can or cannot be called. 
In practice, it represents a union of all the possible kinds (basic type, 
pointer, slice, array, map chan, struct, function...)

`types.Type` follows the opposite approach: it is an interface with only 
two little-used methods, `String()` and `Underlying()`. In order to access 
additional methods, you must type-assert it to one of several concrete 
types: `*types.Basic`, `*types.Pointer`, `*types.Slice`, `*types.Array`, 
`*types.Map`, `*types.Chan`, `*types.Struct`, `*types.Func`  and, most 
importantly for your case, `*types.Named` which can wrap any of the others.

so your visitor function could be something like:
```Go
v = func(n ast.Node) ast.Visitor {
s, ok := n.(*ast.TypeSpec)
if !ok {
return v
}
e := s.Type
t := i.Types[e].Type
if n, ok := t.(*types.Named) {
  fmt.Printf("found named type: %s, its underlying type is %T\n", 
n.Obj().Name(), n.Underlying())
} else {
  fmt.Printf("found unnamed type %T: %v\n", t, t)
}

return v
}
```
Alas, it's still not enough.

You are examining `pkgs[0].TypesInfo` which contains the type of every 
expression, statement and declaration.
The `ast.TypeSpec` you examine are type declarations i.e. they create new 
types - including named types.
But your `i.Types[e].Type` retrieves the *underlying* type, which is 
(almost) always unnamed.

What you want is probably "the type information for the package's exported 
symbols" i.e.
the pkg.Config flag `packages.NeedTypes` which fills `pkgs[0].Types`.

a full example is
```Go
package main

import (
"fmt"
"go/types"
"os"

"golang.org/x/tools/go/packages"
)

type Foo struct {
A string
}

func main() {
cfg := {Mode: packages.NeedTypes | packages.NeedSyntax 
| packages.NeedTypesInfo}
pkgs, err := packages.Load(cfg, "pattern=./...")
if err != nil {
fmt.Fprintf(os.Stderr, "load: %v\n", err)
os.Exit(1)
}
if packages.PrintErrors(pkgs) > 0 {
os.Exit(1)
}
fmt.Println(pkgs)

pkg := pkgs[0].Types
scope := pkg.Scope()
for _, name := range scope.Names() {
obj := scope.Lookup(name)
t := obj.Type()
if n, ok := t.(*types.Named); ok {
fmt.Printf("exported symbol %s\thas named   type %s\t and 
underlying type %s\n",
obj.Name(), n.Obj().Name(), t.Underlying())
} else {
fmt.Printf("exported symbol %s\thas unnamed type %s\n", 
obj.Name(), t)
}
}
}
```

-- 
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/e43858ff-797b-4603-afaf-4ec3acbd8527%40googlegroups.com.

Re: [go-nuts] Re: Contracts Draft: why are method pointers allowed

[Max]

I think that a single syntax allowing both pointer receivers and value 
receivers - with no mechanism to distinguish them - creates unnecessary 
ambiguity, and in some cases it can concretely be a problem.

Consider the following example, adapted from 'math/big.Int`:
```
contract Comparable(T) {
  // return -1 if receiver is lesser than 'other'
  // return +1 if receiver is greater than 'other'
  // return 0 if they are equal
  T Cmp(other T) int
}
```
it seems perfectly reasonable yet, depending on the exact semantics of 
contracts, `math/big.Int` may have troubles satisfying it, because its 
method 'Cmp' has the signature
```
func (recv *big.Int) Cmp(other *big.Int) int
```
Thus it would require 'T' to be a pointer - namely '*big.Int' - to match.
It would mean that the receiver itself of the contract 'T Cmp(other T) int' 
is a pointer. Is it a case allowed by contracts?
And how does it interact with the rule that both pointer receivers and 
value receivers are allowed?


If you ignore for a moment the ability of contracts to specify a union of 
types,
I prefer my proposal https://github.com/cosmos72/gomacro#generics where 
contracts are just generic interfaces,
and they can *optionally* specify the receiver type - used in case you want 
to *remove* the ambiguity between pointer and value receiver types.
They clearly require the possibility to specify multiple contracts in a 
generic type or function signature, while the current proposal
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#methods
allows only a single contract in a in a generic type or function signature, 
thus requiring contracts to be able to specify the methods of several 
unrelated types.

-- 
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/cf04c27c-6ac0-4b64-96b4-f0e7a1a2a99d%40googlegroups.com.

[go-nuts] Re: readonly []byte required

[Max]

I think it could be a useful optimization.

There are at least in two different (and much more general) proposals that, 
if accepted, would include readonly slices as a special case.
The the compiler could recognize that a readonly slice created from a 
string can reuse string's underlying data:

* proposal: Go 2: read-only types https://github.com/golang/go/issues/22876
  proposes a new 'ro' keyword to mark readonly values

* proposal: Go 2: immutable type qualifier 
https://github.com/golang/go/issues/27975
  proposes to allow marking with 'const' values (including function/method 
parameters) and field declarations


On Friday, July 5, 2019 at 4:27:58 AM UTC+2, Ally Dale wrote:
>
> []byte is mutable in Go, but string is readonly, so []byte(string) in Go 
> is actually allocate, and this operation is costly.
> Sometimes, we need a readonly []byte parameter but we have string only, 
> and we have no choice but allocate to make a new []byte variable 
> from string.
> Eg: net.Send([]byte("ping")) is costly, but net.Send(readonly 
> []byte("ping")) can be cheaply.
>

-- 
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/9e489307-cab8-4875-a33b-aa5ba99ed330%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] reflect Call method on nested struct

[Max]

There is another improvement you can do: you are currently using

cfg := Config{Name: }
r := reflect.ValueOf(cfg)

which means that 'r' will contain a copy of 'cfg' and will not be settable.
If instead you use:

r := reflect.ValueOf().Elem()

then r will contain a *pointer* to the original 'cfg' and can modify it 
(the reflect.Value 'r' is settable).
In turn, this also allows to declare 'Config' as follows:
```
type Config struct {
Name String
}
```
i.e. removes the need to use a *pointer* to String.
You also need some minor adjustments to the rest of the code...

A complete example is:

https://play.golang.org/p/AxPE0K_ivxP

On Wednesday, May 29, 2019 at 11:56:42 AM UTC+2, Sotirios Mantziaris wrote:
>
> Ok, found it. I should have used the reflect.ValueOf...
>
> On Wednesday, May 29, 2019 at 12:53:13 PM UTC+3, Sotirios Mantziaris wrote:
>>
>> I did found out that the setter method has to accept a pointer to string.
>> I have a complete example now which unfortunately don't work correclty. 
>> The value should change but it is emptied out.
>>
>> https://play.golang.org/p/OPZKltApEhF
>>
>> What am i missing?
>>
>> On Wednesday, May 29, 2019 at 10:46:32 AM UTC+3, Jan Mercl wrote:
>>>
>>> On Wed, May 29, 2019 at 9:42 AM Sotirios Mantziaris 
>>>  wrote: 
>>>
>>> > I am getting the nested "Name" struct but there are no methods to 
>>> call. 
>>> > What am i doing wrong (besides using reflection :))? 
>>>
>>> The method has a pointer receiver: https://play.golang.org/p/qjhqSvhE9PL 
>>>
>>

-- 
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/b7ac54f5-515c-448d-84db-f58ee7e80697%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Interesting public commentary on Go...

[Max]

Although it's slightly off-topic, there are already some Go forks or 
variants that implement generics.

One is Fo https://github.com/albrow/fo - a source-to-source transpiler that 
converts "Go with generics" to plain Go
Another is my https://github.com/cosmos72/gomacro - a Go interpreter with 
generics (C++ style generics are complete; a second alternative 
implementation more closely following Go generics proposals is in progress).

I think there may be others I don't know about.

On Wednesday, May 29, 2019 at 4:12:27 AM UTC+2, Slawomir Pryczek wrote:
>
> Come on, open your minds a little. Once every 5 years it doesn't hurt to 
> learn some new, better ways of doing things. And if someone wants to write 
> java code untill he dies, then there's a great method of doing that called 
> "stick to java" ;)
>
> That same kind of thinking already marginalized nodejs. The code written 
> in it is horrible because almost everyone is trying to emulate c++ and java 
> instead of taking one week to learn the language a bit and JS is so 
> flexible you can actually do that to some extent. Not sure why some people 
> think that every language on the planet needs to be a bad clone of c++ or 
> java probably putting "java" in its name doesn't help. Thanks GOD it's 
> golang, not go++, we'd be doomed.
>
> Seriously. For me - against generics because of amount of complexity and 
> issues it'd introduce into the language. Would be cool to see a fork 
> implementing it because maybe it can be done "nicely", however i doubt 
> it... It brings to mind Rust's multithreading paradigms. That's actually 
> great stuff...  but totally unfit for integrating with golang (for this im 
> preety sure). Hopefully, if generics will be implemented it won't be 
> integrated too tightly so i won't have to get back to writing code which is 
> more jav'ish that it needs to be. Because, that's a crazy idea... if i 
> liked how java works more i'd just use java ;) And introducing operator 
> overloading into this beautiful design will be like putting readability 
> back into medieval ages...
>

-- 
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/d4a9f7d7-d54c-40fb-b798-aab95d113859%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Adding a timeout to a script interpreter (without leaking a goroutine)

[Max]

A bit less "funky" idea - I currently use it in my 
https://github.com/cosmos72/gomacro
to interrupt the interpreter if the user hits Ctrl+C.
Caveat: I don't know how difficult is to adapt it to GoAWK.

The idea is conceptually simple: loop unrolling. The details are slightly 
tricky:

unroll the interpreter main loop that executes statements by something like 
20 times,
and after the 20 iterations check *once* for externally-set flags: timeout, 
Ctrl+C, etc.
The tricky part is: you also need to handle the case where you are 
somewhere in the middle
of the 20 unrolled iterations but suddenly there are no more statements to 
execute.

The skeleton code might look similar to
https://github.com/cosmos72/gomacro/blob/master/fast/code.go#L169
or https://github.com/cosmos72/gomacro/blob/master/fast/code.go#L204

Regards,
Cosmos72

-- 
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/d7484265-0a61-4c48-9e4e-0d6aaa3d447b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Adding a timeout to a script interpreter (without leaking a goroutine)

[Max]

Using `context` is the recommended mechanism to pass timeouts and other 
information to functions,
so it's probably already the "best" way, at least from the design point of 
view.

I recommend benchmarking it before searching for other solutions:
if it turns out to cause excessive slowdown, there are some tricks you can 
use.

A quite hackish solution that just came to my mind is this:
in the GoAWK interpreter you will surely have some "interpreter context" 
struct, probably full of often-used pointers.
To set a timeout, you could spawn a goroutine that, after a specified time, 
sets one or more of these pointers to nil.
The interpreter would then panic due to a nil pointer dereference, and 
you'd need to recover() from that panic in the top-most interpreter 
function/method.
And of course you also need to save those pointers somewhere, in order to 
restore their values at the beginning of the next interpreter call.

As I said, quite hackish.

Regards,
Cosmos72

-- 
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/4c062256-8aa3-4036-9788-3965e342c31d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] the Dominance of English in Programming Languages

[Max]

I am Italian, and I learned to program quite early - before really knowing 
English.

In my experience, the fact that most programming languages use English 
keywords is not a big obstacle - for two reasons:
1) each programming language has very few reserved keywords - dozens at 
most, compared to thousands of words you need to know in a new foreign 
language.
2) a programming language is a **language** anyway, so the effort is mostly 
in learning the meaning of each keyword, its syntax, and how to use it.

Having said that, English speakers have great advantages when studying 
programs documentation, as most languages and libraries are **documented** 
and commented in English.
But in my opinion the fragmentation created by "everyone writes programs, 
comments and docs in its own language" would be **much** worse.

For reference, some years ago at work I had to integrate a program written 
in German - identifiers, function names, even comments were in German.
It was a nightmare, and it took months even with help from other (Italian) 
people that knew the program and the meaning of each identifier and 
function.

Regards,
cosmos72

-- 
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: Q on using reflect: how to distinguish methods from functions?

[Max]

Hello Jason,
do you have the time to explain this problem more in detail?

My Go interpreter gomacro (I think you already met it),
solves the problem of invoking `b.After(a)` as follows at "compile time", 
i.e. during typecheck and translation:

1. detects that `b` is a `time.Time`.
2. looks up the method "After" in the type `time.Time` (and `*time.Time`, 
in case the method expects a pointer receiver)
3. the returned reflect.Value is a `func (time.Time, time.Time) bool` 
because when you lookup methods from `reflect.Type`
the receiver is **not** bound already
4. it prepares an assignment `c := b.After` to be executed at runtime - 
this instead will return a closure `func (time.Time) bool` because the 
receiver is already bound to `b`
5. it prepares a call `c(a)` to be executed at rutime - this will call 
`b.After(a)`

alternatively, 4. and 5. could become:
4alt. it prepares a call `time.After(b, a)` to be executed at rutime by 
using the reflect.Value returned by looking up the method "After" in the 
type `time.Time`

In both cases, gomacro detects with a method lookup from `time.Time` that 
"After" is a method and behaves accordingly at "compile time",
without waiting for the reflect.Value of `b.After`, which is only available 
at runtime.

It's not clear to me why you had to resort to distinguish methods vs. 
functions *after* you obtained the reflect.Value `b.After` instead of 
distinguishing them *before*
i.e. during typecheck or a similar phase - can you explain?

Regards,

cosmos72



-- 
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: Homoiconic metaprogramming in Go

[Max]

As Ian Lance Taylor answered already, Go language and main Go compilers (go 
and gccgo) do not support this.

My unofficial Go interpreter https://github.com/cosmos72/gomacro instead 
does,
I even presented its AST manipulation and code generation facilities 
(heavily modeled after Common Lisp)
at golab.io this October.

If you know Common Lisp syntax for quoting and backquoting/quasiquoting,
the introduction of 
https://github.com/cosmos72/gomacro/blob/master/doc/quasiquote.md
shows how to write the same in gomacro.

Example:

gomacro> add := ~'{1+2}

gomacro> add
1 + 2   // *go/ast.BinaryExpr

gomacro> add.X
1   // go/ast.Expr

gomacro> add.Y
1   // go/ast.Expr

gomacro> add.Op
+   // go/token.Token

gomacro> :inspect add
add = 1 + 2 // *ast.BinaryExpr
0. X= {ValuePos:20 Kind:INT Value:1}// ast.Expr
1. OpPos= 21// token.Pos
2. Op   = + // token.Token
3. Y= {ValuePos:22 Kind:INT Value:2}// ast.Expr
// type ? for inspector help

inspect add> q
gomacro>


On Friday, December 14, 2018 at 6:25:30 AM UTC+1, Dmitry Ponyatov wrote:
>
> Is it possible to do metaprogramming in Go?
>
> What I want to have is a way to run arbitrary code in compile time, which 
> has full access to compiler data structures
> (parsed syntax trees, compiler stages callbacks, direct code generator 
> calls).
>
> As a variant, it can be some Lisp system runs between parser stage and the 
> rest of  Go compiler. 
>

-- 
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] How to get current goroutine id?

[Max]

I agree on the fact that passing a Context everywhere is impossible in some 
cases - just think about the many APIs (from standard library and 3rd 
parties) that do not accept a Context - and in some other cases very 
complicated, requiring extensive refactoring.

I also agree with the recommendation to *DO* pass a Context when feasible. 
It's just that sometimes it's not feasible, and infact in my case (a Go 
interpreter) I was forced to resort to goroutine-local storage as the only 
possible solution.

If you are interested, you can have a look at my fast (one line of 
assembly) implementation: https://github.com/cosmos72/gls

On Tuesday, October 30, 2018 at 5:34:06 AM UTC+1, robert engels wrote:
>
> I agree. I’ve read the arguments against thread-local (or goroutine local 
> storage), and the passing of Context everywhere instead. It doesn’t make 
> sense to me.
>
> Even a simple runtime.GetGoID() that returned a unique int would allow the 
> design of much simpler server software.
>
> But I don’t think it is going to change, so get to know ‘refactor method 
> signature in IntelliJ’ really well.
>
> On Oct 29, 2018, at 10:28 PM, Tang Shiwei  > wrote:
>
>
>
> Now i have the same problem as you, i need to record log id through a web 
> request, and pass the log id by httpContext, its look orderless for my 
> code, so sad!
>
>
> On Thursday, February 25, 2016 at 1:59:11 AM UTC+8, Damian Turczyński 
> wrote:
>>
>> Kevin
>>
>> I have in my opinion valid reason. I'm writing a web server in go. I want 
>> to have logs across all application to include requestID. The only way I 
>> can do that is to pass httpContext everywhere! Which is hilarious, and 
>> super unclean. In other languages/frameworks it is possible as you have 
>> something like HttpContext accessible globally, and yet of course you have 
>> to deal with spawning child threads with care and maybe even to pass 
>> httpContext there but it's much smaller hustle than passing httpContext in 
>> every single function I'll write in my application.
>>
>> On Sunday, October 14, 2012 at 1:36:25 PM UTC+1, Kevin Gillette wrote:
>>>
>>> That should be fine, but in this case, it'd be better to refer to it as 
>>> 'task specific' instead of 'goroutine local', since your struct 
>>> isn't/shouldn't be designed around the assumption that it's goroutine local.
>>>
>>> The big issue with stuff not being freed is when a map of goroutine id 
>>> to data is used (if the goroutine exits without deleting its data from the 
>>> map, a leak has occurred), not to mention that there are _extremely_ few, 
>>> if any (I'm strongly edging towards there being none) legitimate reasons to 
>>> store data based on goroutine Id -- that kind of thinking is generally a 
>>> carryover for languages that are much less effective at handling 
>>> concurrency.
>>>
>>> On Saturday, October 13, 2012 9:12:40 AM UTC-6, bryanturley wrote:


 On Sat, Oct 13, 2012 at 8:54 AM, bryanturley  
> wrote:
>
>> What I do when i need something like this is
>>
>> type LilSrv struct {
>>   // bleh
>>   // your goroutine local stuff here nicely predefined
>>   // some chans to talk to it
>> }
>>
>> func (ls *LilSrv) MLoop() {
>>   for {
>>   // bleh, stuff
>>   }
>> }
>>
>> ...  somewhere in your code
>>
>> ls = new(LilSrv) // or similar 
>> go ls.MLoop()  // normally i have this wrapped in something like 
>> "NewLilSrv() (ls *LilSrv)"
>>
>> now that ls is your goroutine local storage without using c code or 
>> any other way to low level for normal use code.
>>
>>
 Are you saying the ls in my example won't get GC'ed when it isn't in 
 use anymore?
 What I exampled here is done throughout the standard library...  for 
 instance inside 
 http://golang.org/src/pkg/net/http/server.go?s=30567:30613#L1015
 c, e := newConn()  few lines later
 go c.serve()  
 I think my phrasing just confused you.
 The entire idea of this was to make it not a global state, just a 
 struct that got allocated before the goroutine started that was explicit 
 to 
 that goroutine and others that need to talk to it.
 And if a new goroutine is started in ls.MLoop it doesn't necessarily 
 even matter if it can see that ls.

 The real problem was a single global name that lived in a new spot 
 automagically each thread, that is clearly not happening here.


> On Thursday, February 25, 2016 at 1:59:11 AM UTC+8, Damian Turczyński 
> wrote:
>>
>> Kevin
>>
>> I have in my opinion valid reason. I'm writing a web server in go. I want 
>> to have logs across all application to include requestID. The only way I 
>> can do that is to pass httpContext everywhere! Which is hilarious, and 
>> super unclean. In other languages/frameworks it is possible as you have 
>> something like HttpContext accessible globally, and yet of course you have 
>> to deal with 

[go-nuts] Re: C.malloc of Go type?

[Max]

On Saturday, May 19, 2018 at 10:42:12 PM UTC+2, Max wrote:
>
>
> func mallocList() *List {
> const n = unsafe.Sizeof(List{})
> p := C.malloc(C.ulong(n))
> C.memset(p, C.int(n), 0)
> return (*List)(p)
> }
>

I swapped the arguments to C.memset(). The correct version is:

func mallocList() *List {
const n = C.ulong(unsafe.Sizeof(List{}))
p := C.malloc(n)
C.memset(p, 0, n)
return (*List)(p)
}
 

-- 
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] C.malloc of Go type?

[Max]

After reading https://golang.org/cmd/cgo/#hdr-Passing_pointers and 
https://blog.golang.org/c-go-cgo,
I am trying to understand if there are valid ways to pass between Go and C 
complicated data structures
with (potentially) lots of pointers.

At the moment this is just a speculative question, but it could quickly 
become useful both for my Go interpreter gomacro
and for other similar tasks (I am thinking at least about 
https://github.com/gijit/gi) that need to pass arbitrary
data structures between compiled Go code and the interpreter itself (which 
may not be written in Go).

The question is: is it allowed to take the unsafe.Pointer returned by 
C.malloc() and convert it to a pointer to a Go struct type?

In practice: is the following code valid ?

Thanks,

Max

// 
-

package main

/*
#include 
*/
import "C"

import (
"fmt"
"unsafe"
)

type List struct {
Node int
Next *List
}

func mallocList() *List {
const n = unsafe.Sizeof(List{})
p := C.malloc(C.ulong(n))
C.memset(p, C.int(n), 0)
return (*List)(p)
}

func main() {
// if this code is valid, x can contain C pointers and can be passed 
freely to C code,
// thus exchanging complicated data structured between Go and C

x := mallocList()
x.Next = mallocList()

fmt.Printf("%#v\n", x)
fmt.Printf("%#v\n", x.Next)
}

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

[Max]

About the "other languages extensions":

it's obviously easier than modifying the official Go compiler, but it's 
usually still a major task,
especially if it involves modifying the "poor man's compiler" fast.Comp
which converts a parsed ast.Node into a tree of function closures for 
execution.

If you have a specific example in mind and you describe it, I can be more 
specific.

On Saturday, April 28, 2018 at 11:59:41 PM UTC+2, Maxim Khitrov wrote:
>
> Do you have examples of adding custom ":xyz" or other language extensions? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

[Max]

Done and documented :)

As I also wrote in README.md, see 
https://github.com/cosmos72/gomacro/blob/master/fast/cmd.go#L37
for the documentation and API to define new special commands.

The TL;DR summary is:

choose a name for the new command, write a function with signature
  func(interp *fast.Interp, arg string, opt fast.CmdOpt) (string, 
fast.CmdOpt)
that implements the desired functionality, write the help string, then call:

fast.Commands.Add(Cmd{Name: name, Func: function, Help: help})

On Saturday, April 28, 2018 at 11:59:41 PM UTC+2, Maxim Khitrov wrote:
>
> Do you have examples of adding custom ":xyz" or other language extensions? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

[Max]

Adding custom :foo commands is trivial, it's just a matter of exporting an api 
to do register them (the api exists already, but it's not exported and I would 
use the occasion to improve it). I should have time to do it tomorrow and 
document an example.

About the license: yes, I am still deciding. As I wrote, Mozilla Public License 
looks promising, but I don't know many projects using it (beyond firefox and 
thunderbird) and I don't know how it is perceived in a. Go community b. Open 
source community in general c. Commercial companies. If you can provide 
feedback on the topic, you're welcome :)

-- 
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] How to avoid using goroutine id for Go interpreter with functions, goroutines, and debugger?

[Max]

I have the feeling this is a very advanced and very specific question,
still I would appreciate indications on how to avoid the uncomfortable 
corner I find myself in,
namely that I found no alternative to goroutine id for my (quite 
complicated) use case.

Let me explain:

My Go interpreter gomacro (https://github.com/cosmos72/gomacro) is almost 
complete:
it supports interfaces, functions, methods, goroutines, type inference, 
untyped constants etc.

It allows to freely mix interpreted and compiled code,
which means for example that you can call Interp.Eval() on the string

"func fibonacci(n int) int { if n <= 2 { return 1 }; return fibonacci(n-1) 
+ fibonacci(n-2) }"

and the interpreter will create a function whose reflect.Type is EXACTLY 
func(int) int,
it can be passed to compiled Go code, and it will behave as expected (i.e. 
compute fibonacci numbers).

Such function INTENTIONALLY does not accept additional arguments,
as for example a caller-provided context.Context, goroutine id, or similar.
The reason is simple: to provide maximum compatibility with compiled code,
a func foo(int) int { ... } must have type "func (int) int" in all cases:
be it compiled code, or a function created at runtime by the interpreter,
or whatever its origin.

The problem is: where can I store debugger information, as for example 
whether single-stepping is enabled or not?

Such information is clearly specific per-goroutine: when you are debugging 
some interpreted code,
you want it to check whether single-stepping mode is enabled and, in case, 
inform the debugger
that it suspends itself in order to be debugged, waiting for debugger 
commands before continuing.

But you surely do NOT want ALL OTHER interpreted code running in other 
goroutines to start executing
in single-stepping mode too, inform the debugger that they suspend 
themselves too in order to be debugged,
waiting for debugger commands.
This would mean that debugging interpreted code in a goroutine would affect 
ALL goroutines
that happen to run some interpreted code. That's not something I consider 
useful, or even acceptable.

If the interpreter did not support goroutines, I could store such debugger 
information in a global variable,
but alas, because of goroutine support, global variables must be excluded.

If interpreted functions accepted an extra parameter context.Context, 
goroutine id or similar,
I could pass debugger information in it, but alas that's not the case - for 
a very strong reason explained above.

It seems to me the only possible (and painful) solution is to have 
thread-local data indexed by
a goroutine id, and store in such thread-local data all the per-goroutine 
debugger information,
as for example:
* a flag telling whether single-stepping is enabled or not.
* the call stack of interpreted functions, to implement a "backtrace" 
debugger command
etc.

Suggestions on how to avoid such thread-local data ?

Thanks,

Massimiliano Ghilardi



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

[Max]

That's basically what I have done, and it's both pretty declarative 
(although not fully) and statically typed.

If you are interested, take a look at 
https://github.com/cosmos72/gomacro/blob/master/example/make_fibonacci.gomacro
and the file it generates when executed by gomacro in preprocessor mode: 
https://github.com/cosmos72/gomacro/blob/master/example/make_fibonacci.gomacro_output

On Saturday, April 28, 2018 at 10:25:06 AM UTC+2, Louki Sumirniy wrote:
>
> I can think of many uses for macros, so it's a good thing though I will 
> never use a language that compiles to Go because I like static typing. It 
> would be a logical next step to implement by-default reflection and dynamic 
> typing. But I don't see the benefit. Go's whole schtick is about how it's 
> static typed, and uses an implicit build system based on the structure of a 
> repository filesystem. People choose it because of these two things. 
> Newbies stuck in mindsets taught by dynamic typing and OOP and FP languages 
> struggle with Go and don't realise that providing these features goes 
> counter to the whole point of the language.
>
> I think a good direction, however, would be a code generator, and a 
> declarative syntax for this, to speed up prototyping, and macros are an 
> important first step towards 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] gomacro v2.6 - interactive Go interpreter, now with debugger

[Max]

Hello Louky,

thanks for the question :)

Support for out-of-order code is one of the last missing features, and I am 
am pretty confident it can be added with reasonable effort,
given the large amount of static type analysis that gomacro already 
performs.
In my opinion, the hardest obstacle to full 100% language support is 
already solved: implementing the declaration of new interface types, and 
that's up and running :)

About the performance:
code running in the interpreter is currently between 10 and 100 times 
slower than compiled Go - a typical value that comes out in several 
benchmarks is 30 times slower.

But:
* imported packages are **compiled** and run at full speed
* code startup is instantaneous, even with the current pre-interpretation 
pass that converts source code first to ast.Node, then to a tree of 
closures for faster execution - such pass typically takes less than 1 
millisecond.

Also, the use cases for a Go interpreter are quite different from a Go 
compiler:
an interpreter is useful when you want to interactively manipulate data
(think about a huge dataset that takes a long time to load from disk: an 
edit-compile-run cycle will have to load it every time),
or explore complex data structures interactively,
or perform exploratory programming (gomacro lets you redefine constants, 
variables, types, functions and methods on-the-fly),
or add a scripting engine to an existing program, and the list could 
continue...
a Read-Eval-Print-Loop (REPL) is really a different beast from 
edit-compile-run cycle, no matter how fast the compiler is.

Probably, a very overlooked advantage of an interpreter is that it's MUCH 
easier to write language extensions inside it than inside a compiler.
Gomacro already offers four extensions compared to compiled Go, and in the 
announcement I forgot to mention (in my opinion) the most important one:

extremely easy code generation using macros. More than 75% of gomacro code 
is generated with this technique, and I will present the topic at Golab.io 
conference in Italy in October.
Before that date I should have some documentation available too - they 
reproduce Lisp macros almost literally, but I guess most Go programmers do 
not know Lisp.


On Friday, April 27, 2018 at 10:12:46 PM UTC+2, Louki Sumirniy wrote:
>
> How does it perform compared to pre-compilation? I would think it is such 
> a thin margin it's barely worth doing? Also, order-dependency is a pretty 
> big problem considering how little Go code will be written in this kind of 
> order, since it doesn't have to be. I would think therefore that to fix 
> this problem you will have to have a pre-interpretation pass on the parser 
> that populates the namespace and dependency-orders 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] [ANN] gomacro v2.6 - interactive Go interpreter, now with debugger

[Max]

website: https://github.com/cosmos72/gomacro
install: go get github.com/cosmos72/gomacro

At version 2.6, gomacro has almost complete Go language support, including
import of third-party libraries (easy on Linux, requires a recompiling on 
other platforms),
declaring new interface types and implementing them.

Extensions with respect to compiled Go:
* integrated debugger, see https://github.com/cosmos72/gomacro#debugger
* untyped constants can be manipulated directly at prompt, providing a 
handy arbitrary precision calculator. Example:
  ```
  const c = 1<<1000
  c + 1<<500 * 1<<200
  ```
* implicit conversion from untyped constants to *big.Int, *big.Rat and 
*big.Float. Example:
  ```
  import "math/big"
  var i *big.Int = 1<<1000
  var r *big.Rat = 1.01
  var f *big.Float = 1e123456
  ```

Currently missing features:
* out-of-order code is not supported: symbols must be declared before using 
them.
* some rarely used corner cases with interpreted interfaces are not 
implemented

For a graphical front-end, see https://github.com/gopherdata/gophernotes,
the Go kernel for Jupyter notebooks and nteract (uses a slightly older 
version of gomacro).

As usual, feedback is welcome :)

Max

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [ANN] Go Jupyter kernel and an interactive REPL

[Max]

Hello yunabe,

congratulations for your impressive work!
The Go REPL looks really complete and user-friendly :)

I am the author of https://github.com/cosmos72/gomacro;>gomacro - the interpreter 
used by gophernotes,
and I am very interested in understanding how lgo REPL is implemented:
I had a quick look at github.com/yunabe/lgo/cmd/runner/runner.go
and it seems to me that lgo compiles and loads a shared library (.so)
for each Go declaration, statement or expression to evaluate.

Is this correct?

Thanks,

Cosmos72



On Tuesday, January 16, 2018 at 2:53:39 PM UTC+1, Yu Watanabe wrote:
>
> Hi Gophers,
>
> I developed a new Go's Jupyter Notebook  kernel and 
> REPL environment.
> I would like to announce it to golang users and hear feedback about it.
>
> https://github.com/yunabe/lgo - Go (golang) Jupyter Notebook kernel and an 
> interactive REPL 
>
> Features:
> 1. You can write and execute Go code interactively on browsers and CUI 
> console.
> 2. Full Go language spec support.
> 3. Code completion and code inspection
> 4. Display images, HTML, JavaScript, SVG etc..
> 5. Code cancellation
>
> Thanks to mybinder.org, we can try example notebooks without installation 
> from this link:
> https://mybinder.org/v2/gh/yunabe/lgo-binder/master?filepath=basics.ipynb
>
> If you think it's interesting, please go through the instructions in 
> README.md and install it in your Go environment.
>
> Thanks,
> yunabe
>
> Screenshots:
>
>
>
> 
>
> ** code inspection (Shift-Tab) **
>
> 
>
> ** code completion (Tab) **
>
> 
>
>
>
>
>
>

-- 
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] syscall.SetNonblock stopped working in Go 1.9.3

[Max]

Thanks for the explanation and the solution :)

Where is this behaviour documented?

The current documentation https://golang.org/pkg/os does not indicate
blocking vs non blocking behaviour of *os.File and of functions that return
*os.File, as for example os.Pipe()

Also, os.File.Fd() having side effects seems very unexpected and surprising 
at least to me.

Best regards,

Max

As of 1.9 os.Pipe returns non-blocking descriptors by default.  In 
> order to be consistent with past releases, when you call the Fd 
> method, the descriptor is explicitly set back into blocking mode, 
> since that is how Fd behaved in the past.  In your code you are 
> calling 
> syscall.Read(int(pr.Fd()), make([]byte, 1, 1)) 
> so the effect of calling pr.Fd() is to undo the earlier call to 
> syscall.SetNonblock. 
>
> This is an unfortunate consequence of reasonable decisions. 
> Fortunately the fix for your code is simple: write `fd := pr.Fd()` and 
> then use that, rather than calling the Fd method several times.  Or, 
> perhaps, just trust that pipe's won't be in blocking mode and let the 
> Go runtime handle them efficiently, rather than trying to do your own 
> nonblocking I/O. 
>
> 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.

Re: [go-nuts] syscall.SetNonblock stopped working in Go 1.9.3

[Max]

I tried on Linux/amd64 (debian testing, kernel 4.14.0-2-amd64) and it's 
broken too:

* go 1.9.3 + syscall.SetNonblock : hangs in syscall.Read()
* go 1.9.3 + unix.SetNonblock: hangs in syscall.Read()
* go 1.9.2 + syscall.SetNonblock : hangs in syscall.Read()
* go 1.9.2 + unix.SetNonblock: hangs in syscall.Read()

the relevant strace(1) fragment is:

---
pipe2([3, 4], O_CLOEXEC)= 0
epoll_create1(EPOLL_CLOEXEC)= 5
epoll_ctl(5, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, 
{u32=2231488256, u64=140400417427200}}) = 0
fcntl(3, F_GETFL)   = 0 (flags O_RDONLY)
fcntl(3, F_SETFL, O_RDONLY|O_NONBLOCK)  = 0
epoll_ctl(5, EPOLL_CTL_ADD, 4, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, 
{u32=2231488064, u64=140400417427008}}) = 0
fcntl(4, F_GETFL)   = 0x1 (flags O_WRONLY)
fcntl(4, F_SETFL, O_WRONLY|O_NONBLOCK)  = 0
fcntl(3, F_GETFL)   = 0x800 (flags O_RDONLY|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDONLY) = 0
fcntl(3, F_GETFL)   = 0 (flags O_RDONLY)
fcntl(3, F_SETFL, O_RDONLY|O_NONBLOCK)  = 0
write(1, "Read START\n", 11Read START
)= 11
fcntl(3, F_GETFL)   = 0x800 (flags O_RDONLY|O_NONBLOCK)
fcntl(3, F_SETFL, O_RDONLY) = 0
read(3, 

---

I hope this helps.

David, did you already report the bug on 
https://github.com/golang/go/issues ?
I can add the details above on the bug report too.

Regards,

Max

On Thursday, January 25, 2018 at 11:03:47 AM UTC+1, Steven Hartland wrote:
>
> I checked this on FreeBSD and it still works, so seems like it could be a 
> macOS specific issue.
>
> You should raise a bug here:
> https://github.com/golang/go/issues
>
> It would be good to try and identify the go version which it first broke 
> in too, as that will be helpful in identifying the change which cause the 
> regression.
>
> Regards
> Steve
>
> On 25/01/2018 04:06, Dave Keck wrote:
>
> Hey all, this program exits (as expected) when run with macOS 10.12.6 + Go 
> 1.8.6, but it deadlocks when run with Go 1.9.3:
>
> https://play.golang.org/p/Dw_ND9gkgPm
>
> The same behavior is observed when using unix.SetNonblock instead of 
> syscall.SetNonblock.
>
> It appears that the SetNonblock() functions don't have an effect in Go 
> 1.9.3. Is this a known issue?
>
> Thanks!
> David
> -- 
> 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...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Mapping function name/address to rtype/functype

[max . shavrick]

Maybe I have some false assumptions here, but if I had a dynamically-linked 
go library that I stripped, how would I be able to use reflection at 
runtime when using things from this library.

(Does go support making dynamic libraries?)

Thank you
Max

On Thursday, October 26, 2017 at 5:52:49 PM UTC-4, Ian Lance Taylor wrote:
>
> On Thu, Oct 26, 2017 at 1:34 PM,  <max.sh...@gmail.com > 
> wrote: 
> > (Hoping this is the right place to ask this...) 
>
> Yes, this is at any rate one of the right places. 
>
>
> > I'm wondering if there's a way to map the function name/address to the 
> > function's rtype/functype on a stripped go binary (at least, for ELF)? I 
> > know the funcType is in .rodata, but I don't see any mapping from 
> .gopclntab 
> > -> .typelink, or .gopclntab -> functype. Can I assume they're put into 
> > rodata in order, or, even if there's no direct mapping, is there some 
> > implementation-defined layout I can utilize? 
>
> There is no such mapping.  You're right that the information is 
> generally there, but the mapping is not.  I don't think there is any 
> reliable workaround, and I'm sure there is no workaround that will 
> remain stable in future releases.  Sorry. 
>
> 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] Architectural question

[max]

Hi, i am challenged to develop an effective failover mechanism of 
aggregated notification of certain transactions.
I have transactions by merchant.

Every hour i need to send email (and some other) notifications, aggregated 
by the merchants to specific recipients.

Now i am doing it with "github.com/jasonlvhit/gocron" which runs hourly and 
selects all transactions where date added > date of last worker run.

Then i fire "github.com/pocke/goevent",  signed method prepares the email  
and sends it over.

What i doubt here is if the worker will fail at certain point of time, and 
notifications wont be ever sent for that transactions, so i need to create 
some workaround with logging of all transactions which were successfully 
sent (notified). it happens to be non efficient and not clear.

is there any pattern how to implement such kind of notifications with 
failover? 
Worth to add, that there are huge amount of transactions, so adding some 
column with a flag "notifiication_sent" wont work (because there are couple 
of different notifications and becasue modifying table with transactions is 
not a good idea). Same as storing the log is not good idea because it will 
be another table with even more records 
NumberOfTransaction*NumberOfNotificationTypes.

thank you for an advice.

-- 
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] [ANN] gomacro v2.0 - Go interpreter with REPL, Eval and code-generating macros

[Max]

website: https://github.com/cosmos72/gomacro
install: go get github.com/cosmos72/gomacro

Fairly complete and interactive Go interpreter, implemented in pure Go, 
supporting:

   - all Go basic types, expressions, operators and builtins
   - all Go statements except goto
   - all Go declarations: import, type, const, var, func, including Go 1.9 
   type aliases
   - code generation with Lisp-like macros, quote and quasiquote
   
Main missing feature: cannot yet declare or implement interfaces.

Version 2.0 is a full reimplementation with greatly improved performance.

Not yet tested on Go 1.9 Beta 1.

Feedback welcome :)

Max

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Runtime code generation?

[Max]

Hello,

as others pointed out, a possibility is to use an interpreter. Maybe it's 
not what the original author wanted - execution speed may be a problem - 
but definitely possible.

The interpreter https://github.com/cosmos72/gomacro is fairly complete 
(some features are still missing, for example declaring new interfaces) and 
could fullfill such role. Disclaimer: I am the author.

Also, the same interpreter exploits the generate-source-code + 
compile-and-load-plugin technique to implement "import" of non-standard 
packages,
so this other technique is definitely feasible too. But it will not scale 
much: each compiled plugin contains all its dependencies,
thus compiling and loading a new plugin for each small snippet of code 
generated at runtime will very quickly consume a lot of RAM.

Regards,

Max

On Thursday, May 11, 2017 at 12:19:51 AM UTC+2, Erwin Driessens wrote:
>
> You could let your application generate valid Go source, call the compiler 
> to build a plugin, and load that plugin. I haven't tried that yet, but i 
> think it should work. Downside is that you need to Go tools on the target 
> machine for it to work. I don't know how many times you have to generate 
> new functions, the plugin system can't unload a plugin, so things might not 
> go so smoothly when you need to do this a lot of times in a single run of 
> the program.
>   
>
> On Friday, August 30, 2013 at 10:21:18 PM UTC+2, jzs wrote:
>>
>> Hi gophers,
>>
>> I was studying runtime code generation and was wondering if there's a way 
>> to generate a function at runtime.
>>
>> Let's say we have a function: fun(a,b) {return a+b}
>>
>> This function is parsed to our program as a string, parsed and compiled 
>> to a function in go.
>>
>> In C# and java you can do this as you have access to the clr and jvm 
>> which can jit compile your function for you.
>>
>> Now go is a statically compiled language and as far as I can see the 
>> reflect package is not powerful enough for such operations.
>>
>> Are my assumptions correct that this is not currently possible? 
>> Could it be done through cgo?  (If yes a hint to c documentation would be 
>> nice :) )
>> Would it be possible in go in the future?
>>
>> Creative ideas are welcome but prefer portable solutions so no assembly 
>> generation through c or such :)
>>
>> For performance reasons it wouldn't be beneficial to have a. Net runtime 
>> running that you sent a million requests to.
>>
>> Kind regards,
>> Jzs.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] go/cmd erroneous compile error: initialization loop

[max . dergosits]

This gives me a compilation error:

https://play.golang.org/p/5nSLXw9n82

but this does not: 

https://play.golang.org/p/maaTNOVeqM

I  expected to see no error, and have a valid go program, since there are 
no real initialization dependencies.

This is the output I got:

> tmp/sandbox944533800/main.go:5: initialization loop:
> prog.go:5 x refers to
> prog.go:7 bar refers to
> prog.go:5 x

version, os, arch:

1.8
GOOS=nacl
GOARCH=amd64p32

-- 
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] Question about go test and -cpuprofile

[max . faceless . frei]

I thought that hitting CTRL+C(i.e. sending SIGINT) is a relatively common 
way
to abort tests that run for too long.

суббота, 4 марта 2017 г., 10:32:47 UTC+5 пользователь Ian Lance Taylor 
написал:
>
> On Fri, Mar 3, 2017 at 9:18 PM,   
> wrote: 
> >> I would not expect to get a CPU profile if you hit ^C. 
> > 
> > Just curious as of why? I mean we could use signal.Notify for that, no? 
>
> We could, but why should we?  We can't reasonably handle every 
> possible way that the program could crash early.  If it's important 
> for a particular program to record a CPU profile even if the user hits 
> ^C, then I think the user should arrange for that to work.  We 
> shouldn't build it into the test harness. 
>
> Ian 
>
>
> > пятница, 3 марта 2017 г., 23:04:30 UTC+5 пользователь Ian Lance Taylor 
> > написал: 
> >> 
> >> On Fri, Mar 3, 2017 at 9:41 AM,   wrote: 
> >> > Say you have a package with a test suite that completes in 30 seconds 
> on 
> >> > average. You run: 
> >> > 
> >> >> go test -cpuprofile cpu.pprof -timeout 10s 
> >> > 
> >> > 
> >> > Then whether you abort tests by hitting CTRL+C or they end with a 
> panic 
> >> > due 
> >> > to 
> >> > a low timeout value, in both cases, cpu.pprof will be empty. 
> >> > Is this intended behaviour or a bug? 
> >> 
> >> I would not expect to get a CPU profile if you hit ^C. 
> >> 
> >> If the test times out, I would expect to get a CPU profile.  If we 
> >> don't get one, I think that is a bug. 
> >> 
> >> 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Question about go test and -cpuprofile

[max . faceless . frei]

>
> I would not expect to get a CPU profile if you hit ^C. 
>
Just curious as of why? I mean we could use *signal.Notify* 
 for that, no?

пятница, 3 марта 2017 г., 23:04:30 UTC+5 пользователь Ian Lance Taylor 
написал:
>
> On Fri, Mar 3, 2017 at 9:41 AM,   
> wrote: 
> > Say you have a package with a test suite that completes in 30 seconds on 
> > average. You run: 
> > 
> >> go test -cpuprofile cpu.pprof -timeout 10s 
> > 
> > 
> > Then whether you abort tests by hitting CTRL+C or they end with a panic 
> due 
> > to 
> > a low timeout value, in both cases, cpu.pprof will be empty. 
> > Is this intended behaviour or a bug? 
>
> I would not expect to get a CPU profile if you hit ^C. 
>
> If the test times out, I would expect to get a CPU profile.  If we 
> don't get one, I think that is a bug. 
>
> 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] Question about go test and -cpuprofile

[max . faceless . frei]

Say you have a package with a test suite that completes in 30 seconds on
average. You run:

go test -cpuprofile cpu.pprof -timeout 10s
>

Then whether you abort tests by hitting CTRL+C or they end with a panic due 
to
a low timeout value, in both cases, *cpu.pprof* will be empty.
Is this intended behaviour or a bug?

-- 
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] bombardier - Fast cross-platform HTTP benchmarking tool written in Go

[max . faceless . frei]

https://github.com/codesenberg/bombardier

I just released a v1.0 
 of my 
benchmarking tool.
If you have been looking for a *wrk*/*weighttp *replacement for Windows
or want something more performant than, say, *ab*/*siege*/*hey*/*vegeta*, 
you
might want to check it out.

In short, this is a list of features that I find appealing in
comparison to other benchmarking tools:

   - both *timed* and *limited by number of requests* modes;
   - nice and informative *progress bar*;
   - much *lower memory consumption* in general(compared to *hey*, *vegeta*
   );
   - pretty *high performance*. On my machine up to *265k RPS*.


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