Sounds like a good plan.
On Sun, Nov 25, 2018 at 8:24 PM Russtopia 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
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
aut
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 sp
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 sti
ahem, yes, an idea at that. still you'll need
On Sun, Nov 25, 2018 at 4:36 PM Dan Kortschak
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 analys
+1000
The most valuable comment in this thread IMO. Thank you.
четверг, 2 февраля 2017 г., 13:41:25 UTC+3 пользователь Axel Wagner написал:
>
> I want to re-emphasize that all of these are micro-benchmarks. They say
> nothing useful at all, as proven by this thread; in some circumstances, the
>
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 --
Interesting, thank you. I hadn't seen that. As you also said (while I was
still composing this) I wasn't proposing that one be able to read the name,
just set it.
Oh drat, I suppose my idea of adding one indirect function call to launch
each goroutine still loses the closure-like ability to access
Please note, that the FAQ doesn't really apply to my proposal. If you can
set a name but not read it (without resorting to stack trace parsing or
CGO) then you can't use it to create implicit thread-local contexts.
On Sunday, November 25, 2018 at 4:17:28 PM UTC-8, Bruno Albuquerque wrote:
>
> Te
Hmm. Just after posting, of course, this occurred to me: goroutines are, I
guess, 'lambda functions', which are usually assumed to be anonymous. So
perhaps I'm asking for an abomination -- a 'named lambda function'. :)
For purposes of documentation vis-à-vis things like graphviz, I guess a
layer o
Terra os a FAQ Abbott this, if I understand what you want correctly:
https://golang.org/doc/faq#no_goroutine_id
On Sun, Nov 25, 2018, 4:04 PM Russtopia 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
> c
Sorry, auto correct. I meant to say there is a FAQ about this.
On Sun, Nov 25, 2018, 4:16 PM Bruno Albuquerque Terra os a FAQ Abbott this, if I understand what you want correctly:
> https://golang.org/doc/faq#no_goroutine_id
>
> On Sun, Nov 25, 2018, 4:04 PM Russtopia
>> That still doesn't addre
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
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
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 $1 or similar
by go-callvis. I could of course be wrong, but my thinking is that this is
not really a shortcoming of graphv
This code is ~20% slower (probably)
func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{})
error {
var err error
rv := reflect.ValueOf(arg)
var v uint64
if k := rv.Kind(); k >= reflect.Int && k < reflect.Uint {
v = uint64(rv.Int())
err = writer.write
This code fails my tests with "panic: interface conversion: interface {} is
int32, not int"
switch argKind {
case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.
Int64:
i := uint64(arg.(int))
err = writer.write(b.ioWriter, unsafe.Pointer(&i))
case ref
These are great tips! Thank you!
This is the context for the code above
https://github.com/larytet/binlog/blob/master/binlog.go#L548
The following switch has exactly the same performance
switch arg := arg.(type) {
case int:
i := uint64(arg)
err = writer.write(b.ioWriter,
On Sun, 25 Nov 2018 at 18:25, Ian Denhardt wrote:
> Quoting roger peppe (2018-11-25 12:01:08)
> >On Sun, 25 Nov 2018 at 16:54, 'Axel Wagner' via golang-nuts
> ><[1]golang-nuts@googlegroups.com> wrote:
> >
> >I'd suggest simply
> >func (b *Binlog) writeArgumentToOutput(writer write
Quoting roger peppe (2018-11-25 12:01:08)
>On Sun, 25 Nov 2018 at 16:54, 'Axel Wagner' via golang-nuts
><[1]golang-nuts@googlegroups.com> wrote:
>
>I'd suggest simply
>func (b *Binlog) writeArgumentToOutput(writer writer, arg uint64) error
>{ /* do the writing */ }
>and doin
As someone who learns by reviewing lots of existing projects, and standard
libraries, and I review a lot of them, and so no I wouldn’t be an expert or
author of these apis, IMO it is much harder to understand without the type
information.
I’ve seen similar results when you ask a person the rev
Quoting robert engels (2018-11-25 01:39:30)
> You kind of made my point, when you state “it’s either a slice or a
> map”… Well, what if the resource needed to be ordered, which is why the
> previous method has List in its name, but the method was actually
> returning a map.
If the authors of meta.
On Sun, 25 Nov 2018 at 16:54, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> I'd suggest simply
> func (b *Binlog) writeArgumentToOutput(writer writer, arg uint64) error {
> /* do the writing */ }
> and doing the actual conversions at the call-site. It's type-safe,
> shorte
You don't need to use reflect here. You may well find that something like
this is faster:
func (b *Binlog) writeArgumentToOutput(writer writer, arg
interface{}) error {
var i uint64
switch arg := arg.(type) {
case uintptr:
I'd suggest simply
func (b *Binlog) writeArgumentToOutput(writer writer, arg uint64) error {
/* do the writing */ }
and doing the actual conversions at the call-site. It's type-safe, shorter,
faster and more idiomatic - with the tiny downside of a `uint64()` here and
there.
Alternatively, use refl
>
> No offense intended, but that code is wrong on so many levels...
I strongly believe you that you are not trying to offend anyone, but this
question is interesting for me too, and I'd like more details. Could you
please explain, from worst to "less worst", what's wrong with this code?
Reflecti
No offense intended, but that code is wrong on so many levels...
On Sun, Nov 25, 2018, 17:10 wrote:
> The code below consumes ~40% of the total execution time. According to
> the profiler i := uint64(arg.(uint32)) is a major contributor
>
> // Cast the integer argument to uint64 and call a "writ
The code below consumes ~40% of the total execution time. According to the
profiler i := uint64(arg.(uint32)) is a major contributor
// Cast the integer argument to uint64 and call a "writer"
// The "writer" knows how many bytes to add to the binary stream
// Type casts from interface{} to intege
Instead of writing your own logic to resolve missing imports, could you run
the goimports tool? It will automatically select imports from the standard
library and GOPATH.
S
On Sat, Nov 24, 2018 at 5:06 PM Ben Hoyt wrote:
> I just finished a little tool called "gosnip" that allows you to run
> l
Hi gophers!
As every year we're planning a Go Devroom at FOSDEM 2019, taking place in
Brussels next February.
If you'd like to join us as a speaker please follow the instructions here:
https://link.medium.com/6d9C6gNk8R
Huge thanks to Maartje Eyskens for co-organizing this year's Devroom again!
On the server side you don't know the scheme used. It isn't part of the
request as such. It has to be determined based on the properties of the
port that got the request (if you are listening with TLS on a port, the
request you got is definitely some flavour of https).
If you have a reverse proxy
Technically, the Scheme is optional, but if your url has it, it should be
parsed into that field.
> On Nov 25, 2018, at 1:19 AM, Anik Hasibul wrote:
>
> Thank you so much. I thought I did something wrong. But Now I am pretty sure
> that it's a bug.
>
> Issue opened on GitHub!
>
> Here it is:
32 matches
Mail list logo
