[go-nuts] Re: Released sting 1.0.0
Hi Egon
Thank you very much for your feedback. You confirmed my assumption about di
libraries in go and your links fortified this impression. Probably I have
to rethink some old C# habits and map them to a more go idiomatic style.
> It's difficult to evaluate the API because the examples aren't real-world.
>
Fair point, I'll check if I can use some real code from my other projects
for the examples.
> I would consider something like this instead of fluent interface:
>
> container := sting.NewContainer(
> UsefulStruct{"Very useful"},
> sting.NamedTransient("alsoUseful", &UsefulStruct{"More useful"}),
> )
>
>
Hmm... I like your idea, I take a note for the next version, but for the
current version I'll keep the public API. I don't want a bigger API so your
idea would replace the current builder.Register and builder.RegisteredNamed
functions.
Cheers,
Sandro
--
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] git submodule vs normal go vendoring
> > If the upstream goes away, you can just re-publish the repo (which you'll > have cloned locally) and adjust the remote URL in .gitmodules. New people > cloning will get the clone from the new source. > Not to counter anything you've said, but dep also allows adjusting the URL. Gopkg.toml: [[constraint]] name = "github.com/some/project" source = "github.com/forkof/project" Cheers, Paul -- 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] git submodule vs normal go vendoring
In theory, the git submodule builds are *more* reproducible, because all your build servers etc have clones of those sub-repos cached under their .git, even though they are not under your control. If the upstream goes away, you can just re-publish the repo (which you'll have cloned locally) and adjust the remote URL in .gitmodules. New people cloning will get the clone from the new source. That said, submodules have very poor support by many commercial and popular git tools, especially GUI and IDE-based tools. They don't always behave as you'd expect when switching branches and this can be confusing to the uninitiated. So you might run into practical problems using them. Sam On Sun, Oct 1, 2017 at 12:14 AM, Peter Mogensen wrote: > > > On 2017-10-01 06:38, JM wrote: > > can anyone tell me the pros/cons of using git submodule update instead > > of godep govendor etc... ? > > > > git submodule update --init --recursive > > Your build depend on that command succeeding. > If sub-repos are not under your control that can be a serious problem > for reproducible build - or builds at all. > > /Peter > > -- > 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. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: How to read multi-page TIFF image?
Nigel, I added the sRGB, cHRM, and gAMA chunks, extended the Encoder
structure, and use it like this in my own code:
case ".jpg":
err = jpeg.Encode(file, p, &jpeg.Options{
Quality: 95,
})
if err != nil {
log.Fatal(err)
}
case ".png":
// err = png.Encode(file, p) // colorspace and gamma unspecified
err = (&png.Encoder{IsSRGB: true, RenderingIntent:
png.Perceptual}).Encode(file, p)
if err != nil {
log.Fatal(err)
}
case ".tiff":
// err = tiff.Encode(file, p, nil) // uncompressed
err = tiff.Encode(file, p, &tiff.Options{
Compression: tiff.Deflate,
Predictor: true,
})
if err != nil {
log.Fatal(err)
}
I updated https://github.com/golang/go/issues/20613 about the details.
On Thu, Sep 28, 2017 at 7:38 AM, Michael Jones
wrote:
> thanks, i'll make notes there
>
> On Wed, Sep 27, 2017 at 11:01 PM, Nigel Tao wrote:
>
>> On Thu, Sep 28, 2017 at 10:28 AM, Michael Jones
>> wrote:
>> > Not quite related, but if changes are going to happen, I want to add
>> (or see
>> > someone add) colorspace tags to the PNG code and the TIFF code.
>>
>> It's not exactly what you're asking for, but there are already issues
>> https://github.com/golang/go/issues/11420 "x/image/draw: color
>> space-correct interpolation" and
>> https://github.com/golang/go/issues/20613 "image/png: don't ignore PNG
>> gAMA chunk". There might be other issues filed, I didn't do an
>> exhaustive search.
>>
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>
--
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.
Re: [go-nuts] Re: Distinct types
On Tue, Oct 3, 2017 at 2:39 PM, xingtao zhao wrote: > var i uint32 = 7 > > > Isn't uint32 an unnamed type? No. It is a named type. It's name is "uint32". Compare to "[]byte", which is an unnamed type literal. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Distinct types
On Monday, October 2, 2017 at 11:10:58 PM UTC-7, Christian Surlykke wrote: > > Den mandag den 2. oktober 2017 kl. 21.33.04 UTC+2 skrev Dave Cheney: >> >> Back before aliases defined types used to be called named types, which >> permitted the existence of unnamed types. >> >> map[string]string >> >> is an unnamed type >> >> type Dictionary map[string]string >> >> is a named type, its name is Dictionary >> >> And the rules of assignment permitted assignment from or to an unnamed >> type. >> >> > Aha, I see. Thanks for clarifying. > > br. Chr. > > >> On Tuesday, 3 October 2017 06:26:44 UTC+11, Christian Surlykke wrote: >>> >>> Forgive me if this has been asked before. I've not been able to find a >>> diskussion about it. >>> >>> A snippet like this >>> >>> type AppleCount uint32 >>> >>> var i uint32 = 7 >>> >>> Isn't uint32 an unnamed type? > var ac AppleCount = i >>> >>> why did this fail? > >>> will fail to compile with an error like: >>> >>> cannot use i (type uint32) as type AppleCount in assignment >>> >>> >>> OTOH code like this: >>> >>> type Dictionary map[string]string >>> var m map[string]string = make(map[string]string) >>> var d Dictionary = m >>> >>> >>> compiles just fine. >>> >>> There is this about type definitions in The Go Programming Language >>> Specification: >>> >>> *A type definition creates a new, distinct type with the same underlying >>> type and operations as the given type, and binds an identifier to it.* >>> >>> TypeDef = identifier Type . >>> >>> *The new type is called a defined type. It is different from any other >>> type, including the type it is created from.* >>> >>> >>> which I would take to mean that the second snippet should be invalid. >>> >>> Is this a bug or 'working as intended'? If it's working as intended, can >>> anyone explain the reasoning behind this? >>> >>> br. Christian Surlykke >>> >> -- 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: Released sting 1.0.0
Hi,
I'm going to post few earlier DI discussions and other posts:
*
https://web.archive.org/web/20140521180901/http://codegangsta.io:80/blog/2014/05/19/my-thoughts-on-martini/
*
https://forum.golangbridge.org/t/goldi-lazy-dependency-injection-framework-for-go/1280
* https://www.tonymarston.net/php-mysql/dependency-injection-is-evil.html
And... ignoring my opinions on DI...
Code-wise it looks pretty good and nice to read.
It's difficult to evaluate the API because the examples aren't real-world.
I would consider something like this instead of fluent interface:
container := sting.NewContainer(
UsefulStruct{"Very useful"},
sting.NamedTransient("alsoUseful", &UsefulStruct{"More useful"}),
)
But, I don't know how usable it would be in your use cases.
+ Egon
On Monday, 2 October 2017 11:44:10 UTC+3, snmed wrote:
>
> Hi all
>
> I released my first open source go project:
> https://bitbucket.org/snmed/sting
>
> It's a simple DI library and is used for my own projects. I'm not sure how
> idomatic go it is, but I primarily started it to learn the go reflection
> package and capabilities.
> I'm sure there is still a lot to improve and the best way to find weak
> spots, is to use or/and have some additional eyes on it.
>
> Any suggestions, constructive criticism and feedback is warmly welcome.
>
> Regards
>
>
>
--
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] Memory issues when spawning 1 million go routines that communicate on a channel
Or you could do it this way... https://play.golang.org/p/rU2ONi51ec On Mon, Oct 2, 2017 at 7:26 PM, Unni Krishnan wrote: > I tried FreeOSMemory, didn't make any difference. > > On Mon, 2 Oct 2017, 5:26 a.m. Ian Lance Taylor, wrote: > >> On Sat, Sep 30, 2017 at 9:29 AM, wrote: >> > >> > From what I understand reading and a few comments from the gopher slack, >> > this is because go is not releasing memory back to OS but holds it for >> a >> > longer in case it needs this, if that makes sense? It would be really >> > helpful, if someone could help me understand this. >> >> Yes, that is what the Go runtime does. It requests the memory it >> needs from the operating system. Every five minutes or so it returns >> unused memory back to the operating system. You can make this happen >> sooner by calling https://golang.org/pkg/runtime/debug/#FreeOSMemory . >> >> Note that on modern operating systems unused memory is quite cheap. >> >> 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: goimports build problems "undefined: doTrace"
Ah, thanks I was using build in an attempt to reduce the scope of the problem (under the assumption that one of the things that install did under the hood was call build). (Also it's habit to test things locally before installing them and overwriting the tool I am depending on with a broken version I now can't get rid of!) Cool that works now, many thanks. *runs some tests* Interesting I was under the misapprehension that install wouldn't work if there were multiple files with a main function in a single package - that install could only cope with a single thing at once. Why do I ever assume that go would do anything other than the sensible & clever thing? Thanks! Chris On Tuesday, 3 October 2017 10:07:58 UTC+1, Dave Cheney wrote: > > go build works with packages, not files. In this instance you want (from > that directory) > > go build ./goimports > > May I humbly suggest go install -v, rather than go build. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go get -f still checking VCS
On 3 Oct 2017, at 10:17, alexandre.ferri...@gmail.com wrote: > > Thanks. However, "go get -t" still complains about "missing Git command". > Indeed, on that machine I intentionally don't use any VCS (just a source > tarball). So I just need the Go compiler to compile and quit trying to brew > coffee I didn't request. "go get" is the command for downloading packages (and then installing them). If you don't want it to attempt to download packages you want to use "go install", "go test", "go build" or some other subcommand. //jb -- 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] goimports build problems "undefined: doTrace"
go build works with packages, not files. In this instance you want (from that directory) go build ./goimports May I humbly suggest go install -v, rather than go build. -- 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] goimports build problems "undefined: doTrace"
Hi, I've recently re-built goimports on one of my machines and I'm having a weird error: $:~/home/git/src/golang.org/x/tools/cmd $ git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean $:~/home/git/src/golang.org/x/tools/cmd $ go build goimports/goimports.go # command-line-arguments goimports/goimports.go:238:8: undefined: doTrace $:~/home/git/src/golang.org/x/tools/cmd $ go version go version go1.9 linux/arm Any ideas much appreciated, I'm clearly missing something stupid, everything else builds fine, so I can't believe it's a build environment problem, but then I can't believe goimports would be broken and no-one else notice. Regards Chris -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go get -f still checking VCS
On Monday, October 2, 2017 at 1:26:31 PM UTC+2, Jakob Borg wrote: > > The documentation for the -f flags says: > > > The -f flag, valid only when -u is set, forces get -u not to verify that > > each package has been checked out from the source control repository > > implied by its import path. This can be useful if the source is a local > fork > > of the original. > > However, you're not getting an error indicating a mismatch between source > control repository and import path. You're getting an error indicating that > go-get doesn't understand what VCS is in use (or maybe that it doesn't > work, as in git or hg not being installed). The -u flag requests go-get to > update the package to the latest version from source control, so it can't > continue at that point. > > Thanks. However, "go get -t" still complains about "missing Git command". Indeed, on that machine I intentionally don't use any VCS (just a source tarball). So I just need the Go compiler to compile and quit trying to brew coffee I didn't request. -Alex -- 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.
