Sounds like a good plan.
On Sun, Nov 25, 2018 at 8:24 PM Russtopia <rma...@gmail.com> wrote:
> Sure. I just found it a very interesting 'corner' of the language I have
> run up against.
> However, I do have what I think is an ingenious solution which
> unfortunately cannot fit in the margin of this email :). It's actually
> working rather well for my purposes, and I've proposed it already to the
> author of go-callvis. We'll see where it goes.
>
> I think given the Go philosophy of keeping the language itself simple, a
> convention for annotating goroutines (and defer blocks which also show up
> in graphvis in the same manner) via comments might be best. A
> post-processing tool to catch these comments and fix up the graphviz .dot
> output is already showing promise in achieving what I am after.
>
> -Russ
>
> On Sun, 25 Nov 2018 at 20:13, Michael Jones <michael.jo...@gmail.com>
> wrote:
>
>> just saying the we could make it so. the full name (for a func local var)
>> would be funcName_varName_instanceNumber in some formatting.
>>
>> i think you're up against a "go attitude" decision here but it could help
>> support the tooling spirit...would be nice to see the list if these at exit
>> to quickly spot leaking
>>
>> On Sun, Nov 25, 2018 at 8:05 PM Russtopia <rma...@gmail.com> wrote:
>>
>>> Perhaps I misunderstand what you suggest, but I tried
>>>
>>> func A() {
>>> ...
>>> descriptivelyNamedGoroutine := func() {
>>> ...
>>> }
>>> ...
>>> descriptivelyNamedGoroutine()
>>> ...
>>>
>>> Alas, the 'dot' tool used by go-callvis doesn't seem to obtain any
>>> additional info from this. The resulting diagram still just labels the
>>> goroutine A$1.
>>> Perhaps a limitation of go-callvis itself; I've mailed the author with
>>> this issue to see what he/she thinks about it.
>>>
>>>
>>> On Sun, 25 Nov 2018 at 16:36, Dan Kortschak <
>>> dan.kortsc...@adelaide.edu.au> wrote:
>>>
>>>> A way around that might be to use the name of the variable that holds
>>>> the anonymous function, defaulting to func#n when it's a func literal.
>>>> This should be able to be gleaned from the analysis.
>>>>
>>>> On Sun, 2018-11-25 at 16:04 -0800, Russtopia wrote:
>>>> > That still doesn't address what I'm getting at -- it doesn't give a
>>>> > semantically meaningful name to the goroutines, in stack traces,
>>>> > source
>>>> > code, or in code visualization tools such as graphviz diagrams.
>>>> >
>>>> > What does that goroutine actually *do*? Is it a worker for some
>>>> > specific
>>>> > purpose, does it read from stdin and forward to a pty/socket, does it
>>>> > wait
>>>> > for data on some channel, does it sleep until a particular event
>>>> > occurs and
>>>> > then reboot the box ... ? 'EnclosingFunc$1', 'EnclosingFunc$2' aren't
>>>> > very
>>>> > useful names for documentation and the current Go syntax allows no
>>>> > specification of this by naming the goroutine itself, short of moving
>>>> > it
>>>> > completely out of the scope of the enclosing named function, and
>>>> > losing the
>>>> > benefits of a closure.
>>>> >
>>>> > I guess what I'm getting at is that goroutines can't be named for
>>>> > what they
>>>> > *mean* or *do*. Comments can of course explain this within the source
>>>> > code,
>>>> > but I think there would be a concrete benefit to defining a
>>>> > convention for
>>>> > comment-tagging goroutines, in provide this foothold for external
>>>> > documentation tools; or, perhaps even better, a way to actually name
>>>> > goroutines like how GCC allows named, nested functions. This could
>>>> > even
>>>> > improve the readability of stack traces could it not?
>>>> >
>>>> > I've already devised a 'comment above each goroutine' hack, plus a
>>>> > post-processing tool (basically a sed script) to massage the output
>>>> > of the
>>>> > graphviz 'dot' data, where I place info above each goroutine so it
>>>> > can be
>>>> > renamed in the output diagram. That addresses the naming issue within
>>>> > graphviz diagrams for me, for now.
>>>> >
>>>> >
>>>> > On Sun, 25 Nov 2018 at 15:28, Dan Kortschak <dan.kortschak@adelaide.e
>>>> > du.au>
>>>> > wrote:
>>>> >
>>>> > >
>>>> > > That package doesn't introspect on running code, so a goroutine
>>>> > > name is
>>>> > > not necessary. go-callvis could label the anonymous functions by
>>>> > > their
>>>> > > filepath:line number or something else.
>>>> > >
>>>> > > On Sun, 2018-11-25 at 15:12 -0800, Russtopia wrote:
>>>> > > >
>>>> > > > I recently tried out a go tool for outputting code structure
>>>> > > > visualization
>>>> > > > using graphviz -- https://github.com/TrueFurby/go-callvis
>>>> > > >
>>>> > > > I found that goroutines are just labelled <enclosing function>$1
>>>> > > > or
>>>> > > > similar
>>>> > > > by go-callvis. I could of course be wrong, but my thinking is
>>>> > > > that
>>>> > > > this is
>>>> > > > not really a shortcoming of graphviz, but rather a lack of
>>>> > > > support
>>>> > > > for
>>>> > > > naming goroutines within the language itself as goroutines are
>>>> > > > also
>>>> > > > 'unnamed' in this sense within stack traces. It would aid in
>>>> > > > understanding
>>>> > > > the purpose of goroutines within a structure diagram if
>>>> > > > goroutines
>>>> > > > could be
>>>> > > > named somehow.
>>>> > > >
>>>> > > > I was hoping there was a way within Go to give goroutines
>>>> > > > meaningful
>>>> > > > names
>>>> > > > in such a way that graphviz-like tools could pick up on it and
>>>> > > > make
>>>> > > > meaningful annotations.
>>>> > > >
>>>> > > > The runtime would, I suppose, also have to suffix a goroutine ID
>>>> > > > to a
>>>> > > > goroutine's name, since calling a function that contained
>>>> > > > goroutines
>>>> > > > repeatedly would result in multiple instances of each goroutine.
>>>> > > >
>>>> > > >
>>>> > > > On Fri, 23 Nov 2018 at 22:36, <alex.besogo...@gmail.com> wrote:
>>>> > > >
>>>> > > > >
>>>> > > > >
>>>> > > > > Debugging. For example, if I have a deadlocked request I might
>>>> > > > > want
>>>> > > > > to
>>>> > > > > attach with a debugger and find where exactly it's stuck.
>>>> > > > >
>>>> > > > > Right now this is complicated, you have to examine stacks of
>>>> > > > > all
>>>> > > > > goroutines to find the correct one.
>>>> > > > >
>>>> > > > > On Friday, November 23, 2018 at 9:24:42 PM UTC-8, Andrei Avram
>>>> > > > > wrote:
>>>> > > > > >
>>>> > > > > >
>>>> > > > > >
>>>> > > > > > What's the need for this?
>>>> > > > > --
>>>> > > > > 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.
>>>> > > > >
>>>> --
>>>> CRICOS provider code 00123M
>>>>
>>>> --
>>> 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.
>>>
>>
>>
>> --
>>
>> *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
>>
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>*
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
