Re: [go-nuts] Beginner question about interface

[k1attila1]

I want to search in all library (which have source code)
Maybe i don't understand the concept of Golang (I have delphi,c++,c  
background)


for exmaple : 
I see this. This function need an interface type : r

func NewScanner(r io .Reader 
) *Scanner 



But which type satisfy this r parameter ?
(Of course if i use google i find a sample for all my problem, but i don't 
want to be a Googler, i want to be a programmer in Go.)


c++ :

*int* *FileRead*(*int* *Handle*,  char* *Buffer*, LongWord *Count*);


It is easy because every parameter has a concrete type, but in golang a lot of 
type can satisfy an interface type.



The lack of interface keyword bother me. (or i don't understand the concept 
of go)
I think it is not as easy programming language as others say.

Thank you Attila




2018. április 28., szombat 8:08:23 UTC+2 időpontban Jan Mercl a következőt 
írta:
>
> The answer depends on the scope you want to search. Which scope you want 
> to search?
>
> Also, please share what purpose does that information serve. I cannot 
> imagine a one.
>
> On Sat, Apr 28, 2018, 07:06 > wrote:
>
>> Hi
>>
>> How can i get a list of types which implement a particular interface ? ( 
>> for exmaple io.Reader)
>>
>> Thank you in advance 
>> Attila
>>
>> -- 
>> 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.
>>
> -- 
>
> -j
>

-- 
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] Beginner question about interface

[Jan Mercl]

The answer depends on the scope you want to search. Which scope you want to
search?

Also, please share what purpose does that information serve. I cannot
imagine a one.

On Sat, Apr 28, 2018, 07:06  wrote:

> Hi
>
> How can i get a list of types which implement a particular interface ? (
> for exmaple io.Reader)
>
> Thank you in advance
> Attila
>
> --
> 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.
>
-- 

-j

-- 
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] Beginner question about interface

[k1attila1]

Hi

How can i get a list of types which implement a particular interface ? ( 
for exmaple io.Reader)

Thank you in advance 
Attila

-- 
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] Calling sync.WaitGroup.Add() while a sync.WaitGroup.Wait() is waiting

[Jon Bodner]

Thanks, everyone, for your answers! I think I understand what 
sync.WaitGroup is doing now.

Jon

On Friday, April 27, 2018 at 7:29:50 AM UTC-4, rog wrote:
>
> On 26 April 2018 at 16:29, Jon Bodner > 
> wrote: 
> > Hello, 
> > 
> > We were having a discussion at work about passing around references to 
> > sync.WaitGroup. I said it was a bad idea, because if a goroutine 
> launched a 
> > goroutine of its own and called sync.WaitGroup.Add() after a goroutine 
> > called sync.WaitGroup.Wait(), but before the count dropped to 0, your 
> code 
> > would panic. The comments seem to support this: 
> > 
> > "If a WaitGroup is reused to wait for several independent sets of 
> events, 
> > new Add calls must happen after all previous Wait calls have returned." 
> > 
> > And the WaitGroup source code for Add has lines like this: 
> > 
> > if w != 0 && delta > 0 && v == int32(delta) { 
> > panic("sync: WaitGroup misuse: Add called concurrently with Wait") 
> > } 
> > 
> > But a co-worker wrote this code, and it runs without a panic: 
> > https://play.golang.org/p/NjqK_YoqHeH 
>
> FWIW This code is fine, and was part of the original design goal of 
> WaitGroup. When the count is known to be non-zero (for example because 
> the current goroutine has previously done an Add) it's OK to call Add 
> to add more. 
>
> The key in the above quote is "If a WaitGroup is reused to wait for 
> several independent sets of events". If you're reusing a WaitGroup, 
> this makes sense, but in the example above, the WaitGroup is not 
> reused so all is good. 
>
> As for the panic, others have already explained how that might happen. 
>

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

Re: [go-nuts] [ANN] oksvg and rasterx; SVG 2.0 path compliant renderer and rasterizer

[Steven Wiley]

Hey everyone,

I looked into using just the rasterizer package from the 
"golang.org/x/image/vector" package and tested it vs the rasterizer derived 
from the freetype package. I will call these the GV and FT rasterizers. One 
thing with the GV is that it only does non-zero-winding-rule, while the FT 
does that and even-odd-winding-rule. For stroking and most things you need 
the non-zero-winding, but just an FYI, the SVG spec asks for both.

What I did like about the GV is the flattener for Bezier curves vs the FT 
version, which is not recursive and hence cleaner, and more stateless to 
implement. I also like GV interface to the last step which is rasterizing a 
representation of flat lines with some version of  anti-aliasing. GV uses 
the Draw method with a source and a target image, and the path works as an 
alpha mask. FT on the other hand uses a Painter, which seems a little more 
mysterious to me.

So, what I did was abstract the last anti-aliasing step into an interface 
called Scanner. The ScannerGV struct satisfies Scanner by wrapping the Draw 
func from the vector package, and is included in  rasterx. ScannerFT, which 
is derived from the anti-aliasing code in the freetype package, is in a 
different repository, "github.com/srwiley/scanFT". In order to use 
ScannerFT, you need to include that into your project separately.

The Bezier curve flattener now in the rasterx/fill.go file is a modified 
version of the vector package flattener (more on that below). So, at this 
point the only part of rasterx that depends on any freetype code is 
isolated in the scanFT repository. Which brings me to a bit of a pet peeve 
of mine. Flattening Bezier curves had nothing to do with rasterizing and 
anti-aliasing, but they always seem to be thrown together in the same file. 
It is instructive to have a logical separation, which is one reason why I 
like abstracting the Scanner from everything else.

As far as performance, it was not clear cut which was better. GV seems to 
have the edge with more complex and small resolution images, and FT has the 
edge with higher resolution/lower complexity images.

Below are the results of some benchmarks performed on a sample shape (the 
letter Q ). The first test is the time it takes to scan the image after all 
the curves have been flattened. The second test is the time it takes to 
flatten, and scan a simple filled image. The last test is the time it takes 
to flatten a stroked and dashed outline of the shape and scan it. Results 
for three different image sizes are shown.

128x128 Image
TestRep   Time
BenchmarkScanGV-16  5000  287180 ns/op
BenchmarkFillGV-16  5000  339831 ns/op
BenchmarkDashGV-16  2000  968265 ns/op

BenchmarkScanFT-16 2   88118 ns/op
BenchmarkFillFT-16  5000  214370 ns/op
BenchmarkDashFT-16  1000 2063797 ns/op

256x256 Image
TestRep   Time
BenchmarkScanGV-16  2000 1188452 ns/op
BenchmarkFillGV-16  1000 1277268 ns/op
BenchmarkDashGV-16  500  2238169 ns/op

BenchmarkScanFT-16  5000  290685 ns/op
BenchmarkFillFT-16  3000  446329 ns/op
BenchmarkDashFT-16   500 2923512 ns/op

512x512 Image
TestRep   Time
BenchmarkScanGV-16   500 3341038 ns/op
BenchmarkFillGV-16   500 4032213 ns/op
BenchmarkDashGV-16   200 6003355 ns/op

BenchmarkScanFT-16  5000  292884 ns/op
BenchmarkFillFT-16  3000  449582 ns/op
BenchmarkDashFT-16   500 2800493 ns/op

Here are some additional benchmarks using oksvg with either 8 large icons 
(landscape) and a set of 44 simpler small icons (sports):

oksvg with FT scanner

BenchmarkLandscapeIcons-16   12,100,513,290 ns/op
BenchmarkSportsIcons-16200   6,017,063 ns/op

BenchmarkLandscapeIcons-16   12,167,196,383 ns/op
BenchmarkSportsIcons-16200   6,020,537 ns/op

oksvg with GV scanner

BenchmarkLandscapeIcons-16   12,097,975,097 ns/op
BenchmarkSportsIcons-16100  18,507,261 ns/op

BenchmarkLandscapeIcons-16   12,002,543,751 ns/op
BenchmarkSportsIcons-16100  13,407,936 ns/op

So, you can either use the GV scanner or the FT scanner, depending on how 
big vs how complex your icons are, if you need even-odd winding rule, and 
whether or not you care about freetype vs go-friendly licenses. Right now 
the rasterx and oksvg package have no license, but I will put in place a 
go-friendly version soon.

Finally, a little bit more on the Bezier curve flattener from the vector 
package. I had to modify that for my purposes, but I also did a little 
optimization. Instead of doing a series of linear interpolations (Lerps), I 
used the expanded form (see https://pomax.github.io/bezierinfo/#matrix). 
This usually gives

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

Re: [go-nuts] float accuracy when calculating Fibonacci numbers

[Michael Jones]

Yuval,

There are fundamental issues here.

1. That equation (de Moivre, Binet) is from the algebra of ideal numbers.
Numbers of infinite precision. Not the realm of computer arithmetic. It
works fine with double precision (go: float64, c/c++: double) up to F(75)
but must fail for F(76) due to the limited precision of 64-bit floating
point and has nothing to do with language.

F(76) = 3416454622906707 but the best we can do in 64 bits is
3416454622906706 even with a Pow() function good to +/-1 least significant
bit.

2. Another difference between algebra and computer arithmetic
(well...actually about the floor function) is that one of your two power
terms is not needed. Psi < 1 so Psi^N is pretty small, so small, that it
never changes the value of the rounded result. So you can just evaluate:

return round(math.Pow(math.Phi, float_n) / sqrt_5)

3. Using a map in your test is not wrong, but it means that the tests will
be executed in a random order, which makes the printed errors a little less
clear.

celeste:fib mtj$ go test -v
=== RUN   Test_fibonacci
--- FAIL: Test_fibonacci (0.00s)
fib_test.go:104: 82 : Expected 61305790721611591 got 61305790721611584
fib_test.go:104: 84 : Expected 160500643816367088 got 160500643816367040
fib_test.go:104: 81 : Expected 37889062373143906 got 37889062373143896
fib_test.go:104: 87 : Expected 679891637638612258 got 679891637638612096
fib_test.go:104: 88 : Expected 1100087778366101931 got 1100087778366101632
fib_test.go:104: 83 : Expected 99194853094755497 got 99194853094755488
fib_test.go:104: 77 : Expected 5527939700884757 got 5527939700884756
fib_test.go:104: 86 : Expected 420196140727489673 got 420196140727489600
fib_test.go:104: 90 : Expected 2880067194370816120 got 2880067194370815488
fib_test.go:104: 91 : Expected 4660046610375530309 got 4660046610375529472
fib_test.go:104: 92 : Expected 7540113804746346429 got 754011380474638
fib_test.go:104: 76 : Expected 3416454622906707 got 3416454622906706
fib_test.go:104: 85 : Expected 259695496911122585 got 259695496911122528
fib_test.go:104: 89 : Expected 1779979416004714189 got 1779979416004713728
fib_test.go:104: 79 : Expected 14472334024676221 got 14472334024676218
fib_test.go:104: 80 : Expected 23416728348467685 got 23416728348467676
FAIL
exit status 1
FAIL fib 0.003s

updated fib.go: https://play.golang.org/p/N-8lmjrMYAq
update fib_test.go: https://play.golang.org/p/FPuN58m1VVs

4. Plenty of ways to do this computation in Go using 64-bit integers, or
big floats, or big ints.

5. Plenty of algorithms, some quite fascinating!
https://ir.library.oregonstate.edu/downloads/t435gg51w


On Thu, Apr 26, 2018 at 10:22 AM, Ian Lance Taylor  wrote:

> On Thu, Apr 26, 2018 at 1:17 AM, Yuval Lifshitz  wrote:
> >
> > I ran into the following issue when started playing with go. Had the
> > following small program to calculate Fibonacci numbers using the closed
> > form:
> >
> > package "fib"
> >
> > import "math"
> >
> > var sqrt_5 = math.Sqrt(5.0)
> > var psi = -1.0/math.Phi
> >
> > // had to add this to solve accuracy issue
> > func round(x float64) uint64 {
> > return uint64(math.Floor(x + 0.5))
> > }
> >
> > // find the nth fibonacci number based on Binet's formula
> > // see here:
> > https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
> > func fibonacci(n uint) uint64 {
> > float_n := float64(n)
> > return round((math.Pow(math.Phi, float_n) - math.Pow(psi,
> > float_n))/sqrt_5)
> > }
> >
> >
> > When I first tried without doing the "rounding" I did not get whole
> numbers
> > as the output (similar program in C++ gave whole numbers without
> rounding).
> > Following test is failing without the call to "round()":
> >
> > package "fib"
> >
> > import "testing"
> >
> > var results = map[uint]uint64 {
> > 0: 0,
> > 2: 1,
> > 10: 55,
> > 14: 377,
> > 20: 6765,
> > 29: 514229,
> > 33: 3524578,
> > 59: 956722026041,
> > }
> >
> > func Test_fibonacci(t *testing.T) {
> > for arg, expected := range results {
> > actual := fibonacci(arg)
> > if actual != expected {
> > t.Error("Expected", expected, "got", actual)
> > }
> > }
> > }
> >
> >
> >
> > Are there known accuracy issues with floating points in go?
>
> No.
>
> I suggest that you show us your C code.  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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Michael T. Jones
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.

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

[Louki Sumirniy]

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.

On Friday, 27 April 2018 20:33:41 UTC+3, Max wrote:
>
>
> 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] [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] Compiling Godoc

[Malhar Vora]

Hello,

I have done some change in example_test file of some standard library 
package. I want to test my changes. Any guidance for how to do it ?

Another question is there are some examples which are Runnable and others 
are not. How is it decided that some example shown in Godoc is Runnable or 
not ?

-- 
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: Using variadic function / context in an interface?

[Manlio Perillo]

Il giorno giovedì 26 aprile 2018 18:55:07 UTC+2, Nimrod Shneor ha scritto:
>
> Hey everyone,
> I've encountered a design issue - 
> I have an the following interface -
>
> type Runner interface {
>   Run(x X,y Y)
> }
>
> I want to add to it an Init(...) method which will initialize the internal 
> fields of the Runner before performing `Run`..
> My issue is that different structs implementing the `Runner` interface 
> require different fields in order to initialize, How should I solve this?
>
>
You don't need an Init method.  Just make sure that the instance 
implementing the Runner interface is initialized before calling the Run 
method.

As an example:

package runner


type Runner interface {
  Run(x X, y Y)
}


type myrunner struct {
// ...
}

func (r *runner) Run(x X,y Y) {
// ...
}

func New(...) Runner {
r = new(runner)
// initialize the runner

return r
}

Note that the runner type is not exported, so that the user can not 
accidentally call the Run method before the instance is initialized.
Also note that New returns Runner and not *myrunner.

Here is a working example:
https://play.golang.org/p/gqUiYkpq66D


Manlio

-- 
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: On Accepting Interfaces and Structs

[Kaveh Shahbazian]

Assume the state is the config struct and each implementation is reading it 
from s different file type (yaml, toml, hlc, json, etc).

On Friday, April 27, 2018 at 4:45:33 AM UTC+4:30, Jake Montgomery wrote:
>
> The example gives me a better understanding of what you are doing, though 
> still not much understanding as to *why *you are doing it this way. 
> Usually, if I feel that code has a "smell" in Go, there is a way to rethink 
> the basic design resulting more "natural" code. But without a full 
> understanding of the real situation, it is impossible to say if that 
> applies here. But lets assume for now that you must have multiple packages 
> that all contain functions that return a common struct.
>  
>
>> But I do not like:
>>
>>
>>1. Having a package just to hold a single type,
>>
>> Personally, I don't see anything inherently wrong with this. If you *must 
> *multiple packages that all need the type, then it should be in a package 
> separate from those. In many cases there would be functions that could also 
> go in package `state`, but if not, then that's ok too.
>
> 2. The consumer package is accepting a concrete type and depends on it - 
>> seems this one can not be avoided since there is nothing like structural 
>> typing for structs in Go.
>>
>
> Your example does feel a bit awkward, but, again, I don't have enough 
> information on what is really being achieved to suggest a completely 
> different model.  
>
> But I will take a shot in the dark. Think interfaces? Perhaps the 
> state.State type returned by Clone() could be an interface? This does not 
> solve the problem of having to define the interface in a separate package, 
> and I would only use an interface if there was a compelling reason to do 
> so. 
>
> Taking a further leap,why "Clone()" at all? What do you do with state.State 
> in package consumer? Does it have to be a struct for some reason? If you 
> could define a set of functionality that a consumer needs from state.State, 
> you could then have Concrete1, Concrete2, and Concrete3 all implement 
> that functionality. Then consumer can just use them directly as 
> interfaces ... or perhaps that is using them indirectly. Anyway, I hope 
> that is somewhat comprehensible. 
>
> Good Luck
>  - Jake
>
> On Tuesday, April 24, 2018 at 1:49:45 AM UTC-4, Kaveh Shahbazian wrote:
>>
>> @Jake @Bryan Thanks!
>>
>> Current solution I use:
>>
>> A package that holds the shared data type State:
>>
>> package state
>>
>> type State struct {
>> Latitude  float64
>> Longitude float64
>> Mark  string
>> Name  string
>> // ...
>> }
>>
>> Three packages with different implementations and algorithms:
>>
>> package concrete1
>>
>> import (
>> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
>> )
>>
>> type Concrete1 struct{}
>>
>> func (c *Concrete1) Clone() (*state.State, error) { panic("N/A") }
>>
>> And:
>>
>> package concrete2
>>
>> import (
>> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
>> )
>>
>> type Concrete2 struct{}
>>
>> func (c *Concrete2) Clone() (*state.State, error) { panic("N/A") }
>>
>> And:
>>
>> package concrete3
>>
>> import (
>> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
>> )
>>
>> type Concrete3 struct{}
>>
>> func (c *Concrete3) Clone() (*state.State, error) { panic("N/A") }
>>
>> And the consumer package, which will be given a concrete implementation 
>> based on some logic (this is where "Accepting interfaces" is happening):
>>
>> package consumer
>>
>> import (
>> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
>> )
>>
>> func Use(cln cloner) {}
>>
>> type cloner interface {
>> Clone() (*state.State, error)
>> }
>>
>> The part in question is the *state.State data type. This is the best I 
>> could come up with.
>>
>> But I do not like:
>>
>>
>>1. Having a package just to hold a single type,
>>2. The consumer package is accepting a concrete type and depends on 
>>it - seems this one can not be avoided since there is nothing like 
>>structural typing for structs in Go.
>>
>>
>> There might be a better way to do 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.

Re: [go-nuts] Using variadic function / context in an interface?

[nimrodshn]

Hey rog,
Thanks for the reply!
What happens now  - I have an Init method for each struct implementing 
Runner, the Init method is not in the interface and I have to do type 
assertion every time I call to Init - That is for each class implementing 
the Runner interface.
It's a bit ugly in my POV But  I can live with it..


On Friday, April 27, 2018 at 4:28:10 PM UTC+3, rog wrote:
>
> On 26 April 2018 at 06:13,  > wrote: 
> > Hey everyone, 
> > I've encountered a design issue - 
> > I have an the following interface - 
> > 
> > type Runner interface { 
> >   Run(x X,y Y) 
> > } 
> > 
> > I want to add to it an Init(...) method which will initialize the 
> internal 
> > fields of the Runner before performing `Run`.. 
> > My issue is that different structs implementing the `Runner` interface 
> > require different fields in order to initialize, How should I solve 
> this? 
>
> The conventional solution to this would be to avoid putting Init in 
> the Runner interface; instead you could have different factory 
> functions that each return a new appropriately initialised Runner 
> instance. 
>
> If you really need Init in there, one solution I've used in the past 
> is to have a uniform interface that involves initialization from 
> arbitrary data (in out case we used YAML, so each implementation knew 
> how to initialise itself from a YAML object). It all depends on the 
> constraints of your problem. 
>

-- 
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: Using variadic function / context in an interface?

[nimrodshn]

I mean, it doesn't have to be I just find that it is more cleaner...
What happens now  - Init is not in the interface and I have to do type 
assertion every time I call to Init - That is for each class implementing 
the Runner interface.
It's a bit ugly in my POV But  I can live with it..

On Thursday, April 26, 2018 at 8:16:30 PM UTC+3, simon place wrote:
>
> does the init NEED to be in the interface?
>
> On Thursday, 26 April 2018 17:55:07 UTC+1, Nimrod Shneor wrote:
>>
>> Hey everyone,
>> I've encountered a design issue - 
>> I have an the following interface -
>>
>> type Runner interface {
>>   Run(x X,y Y)
>> }
>>
>> I want to add to it an Init(...) method which will initialize the 
>> internal fields of the Runner before performing `Run`..
>> My issue is that different structs implementing the `Runner` interface 
>> require different fields in order to initialize, How should I solve this?
>>
>> Thanks a lot!
>> Nimrod.
>>
>

-- 
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] Using variadic function / context in an interface?

[roger peppe]

On 26 April 2018 at 06:13,   wrote:
> Hey everyone,
> I've encountered a design issue -
> I have an the following interface -
>
> type Runner interface {
>   Run(x X,y Y)
> }
>
> I want to add to it an Init(...) method which will initialize the internal
> fields of the Runner before performing `Run`..
> My issue is that different structs implementing the `Runner` interface
> require different fields in order to initialize, How should I solve this?

The conventional solution to this would be to avoid putting Init in
the Runner interface; instead you could have different factory
functions that each return a new appropriately initialised Runner
instance.

If you really need Init in there, one solution I've used in the past
is to have a uniform interface that involves initialization from
arbitrary data (in out case we used YAML, so each implementation knew
how to initialise itself from a YAML object). It all depends on the
constraints of your problem.

-- 
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: Using variadic function / context in an interface?

[matthewjuran]

Each call to Run could check if the struct has been initialized and 
initialize it if not. An approach is a function field could be swapped out 
after initialization.

Matt

On Thursday, April 26, 2018 at 11:55:07 AM UTC-5, Nimrod Shneor wrote:
>
> Hey everyone,
> I've encountered a design issue - 
> I have an the following interface -
>
> type Runner interface {
>   Run(x X,y Y)
> }
>
> I want to add to it an Init(...) method which will initialize the internal 
> fields of the Runner before performing `Run`..
> My issue is that different structs implementing the `Runner` interface 
> require different fields in order to initialize, How should I solve this?
>
> Thanks a lot!
> Nimrod.
>

-- 
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: Reverse Proxy is not Serving for another port.

[hari prasad]

I have a reverse proxy in golang which Listens on two different ports and
redirect to respective servers. the server is hosted in aws.
One is by default listening on 80  and another one is listening on port: 90

port :80 proxy   -> Redirects to   -> 9000
port :90 proxy -> Redirects to --> 9095

I can see both listening ports using command, sudo ss -lptn 'sport = :80'
and sudo ss -lptn 'sport = :90' respectively.

I tried like
 subdomin.domine.com  -> as by default is redirect to port 80
   - I can view logs in my proxy program.
   - it is working fine.

but I tried like
 subdomin.domine.com:90 -> request doesn't reach my server.
- I can view any logs in my program.
- It doesn't serve any error messages too.

please find my code sample below.

go func() {
   mux80 := http.NewServeMux()
   mux80.HandleFunc("/", onRequest80)
   log.Print("Listening on: 80")

   server80 := http.Server{
  Addr: ":80",
  ReadTimeout:  90 * time.Second,
  WriteTimeout: 90 * time.Second,
  Handler:  mux80,
   }

   err := server80.ListenAndServe()
   if err != nil {
  log.Printf("Error in running http proxy server: %s", err.Error())
   }
}()

log.Print("Listerning on: 90")
mux90 := http.NewServeMux()
mux90.HandleFunc("/", onRequest90)
server90 := http.Server{
   Addr: ":90",
   ReadTimeout:  90 * time.Second,
   WriteTimeout: 90 * time.Second,
   Handler:  mux90,
}

err := server90.ListenAndServe()
if err != nil {
   log.Printf("Error in running http proxy server: %s", err.Error())
}


Please share your feedback.

cheers,
Hariprasad.


>

-- 
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] Calling sync.WaitGroup.Add() while a sync.WaitGroup.Wait() is waiting

[roger peppe]

On 26 April 2018 at 16:29, Jon Bodner  wrote:
> Hello,
>
> We were having a discussion at work about passing around references to
> sync.WaitGroup. I said it was a bad idea, because if a goroutine launched a
> goroutine of its own and called sync.WaitGroup.Add() after a goroutine
> called sync.WaitGroup.Wait(), but before the count dropped to 0, your code
> would panic. The comments seem to support this:
>
> "If a WaitGroup is reused to wait for several independent sets of events,
> new Add calls must happen after all previous Wait calls have returned."
>
> And the WaitGroup source code for Add has lines like this:
>
> if w != 0 && delta > 0 && v == int32(delta) {
> panic("sync: WaitGroup misuse: Add called concurrently with Wait")
> }
>
> But a co-worker wrote this code, and it runs without a panic:
> https://play.golang.org/p/NjqK_YoqHeH

FWIW This code is fine, and was part of the original design goal of
WaitGroup. When the count is known to be non-zero (for example because
the current goroutine has previously done an Add) it's OK to call Add
to add more.

The key in the above quote is "If a WaitGroup is reused to wait for
several independent sets of events". If you're reusing a WaitGroup,
this makes sense, but in the example above, the WaitGroup is not
reused so all is good.

As for the panic, others have already explained how that might happen.

-- 
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 does time reported by go test relate to the wall clock time?

[Dave Cheney]

Try upgrading to go 1.10. You’ll get build and test caching for free and you’ll 
see a small variance between the timings you reported. 

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