Re: [go-nuts] Go Tool to convert svg to png/jpg

[robert engels]

That rasterx is pretty sweet. Should be pretty easy to create an SVG to PNG 
module using that.

> On Feb 1, 2020, at 12:20 AM, Randall O'Reilly  wrote:
> 
> Here’s some partial SVG renderers in Go:
> 
> * https://github.com/srwiley/oksvg
> * https://github.com/goki/gi (uses srwiley’s rasterx rasteriser, has separate 
> SVG parsing / painting impl).
> 
> Cheers,
> - Randy
> 
>> On Jan 31, 2020, at 6:54 PM, Michael Jones  wrote:
>> 
>> Just to be clear: PNG is a description of pixel values comprising an image 
>> (RGBa, RGBa, RGBa, ...), SVG is a program for creating an image (set color 
>> to blue, draw a circle, change to red, draw a line, ...). Going from SVG 
>> (scalable vector graphics) to pixels is to render an image by executing the 
>> simple program of graphical operation codes. (As said above)
>> 
>> Solutions depending on situation: most every browser has code to rasterize 
>> SVG. Can you invoke one to produce your image? There are numerous free tools 
>> to do the same--can you bundle one of those and invoke it as an external 
>> program? Cairo can do it. (these are in addition to what you really seem to 
>> want, which is a fully Go SVG -> PNG renderer.)
>> 
>> Good luck in your project,
>> michael
>> 
>> On Fri, Jan 31, 2020 at 6:03 PM robert engels  wrote:
>> There is no cross-platform graphics library included in Go.
>> 
>> Most likely you’ll need a C binding to Qt or similar to perform the 
>> rasterization.
>> 
>> You might be able to put one together using something like 
>> https://github.com/hajimehoshi/ebiten
>> 
>> 
>>> On Jan 31, 2020, at 7:31 PM, maithri.fri...@gmail.com wrote:
>>> 
>>> I'm looking for one too but can't find anything online either..
>>> 
>>> On Monday, March 9, 2015 at 11:35:51 PM UTC-7, will wrote:
>>> Hi Gophers,
>>> 
>>> Is there a Golang based tool (or library) tool to convert svg to png or jpg?
>>> 
>>> regards,
>>> 
>>> Will
>>> 
>>> -- 
>>> 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/d03ad514-1e56-42a3-b7c6-798346a76ca1%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/BF136C90-3061-4E01-890B-A6FB38E94E07%40ix.netcom.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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CALoEmQw_8%3D3AkkrmZNG9Xrzq37TaauFF77wJUGjkp-Mx3%3DrUPQ%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/286D10E9-29D9-409F-916D-729EE4490164%40ix.netcom.com.

Re: [go-nuts] Go Tool to convert svg to png/jpg

[Randall O'Reilly]

Here’s some partial SVG renderers in Go:

* https://github.com/srwiley/oksvg
* https://github.com/goki/gi (uses srwiley’s rasterx rasteriser, has separate 
SVG parsing / painting impl).

Cheers,
- Randy

> On Jan 31, 2020, at 6:54 PM, Michael Jones  wrote:
> 
> Just to be clear: PNG is a description of pixel values comprising an image 
> (RGBa, RGBa, RGBa, ...), SVG is a program for creating an image (set color to 
> blue, draw a circle, change to red, draw a line, ...). Going from SVG 
> (scalable vector graphics) to pixels is to render an image by executing the 
> simple program of graphical operation codes. (As said above)
> 
> Solutions depending on situation: most every browser has code to rasterize 
> SVG. Can you invoke one to produce your image? There are numerous free tools 
> to do the same--can you bundle one of those and invoke it as an external 
> program? Cairo can do it. (these are in addition to what you really seem to 
> want, which is a fully Go SVG -> PNG renderer.)
> 
> Good luck in your project,
> michael
> 
> On Fri, Jan 31, 2020 at 6:03 PM robert engels  wrote:
> There is no cross-platform graphics library included in Go.
> 
> Most likely you’ll need a C binding to Qt or similar to perform the 
> rasterization.
> 
> You might be able to put one together using something like 
> https://github.com/hajimehoshi/ebiten
> 
> 
>> On Jan 31, 2020, at 7:31 PM, maithri.fri...@gmail.com wrote:
>> 
>> I'm looking for one too but can't find anything online either..
>> 
>> On Monday, March 9, 2015 at 11:35:51 PM UTC-7, will wrote:
>> Hi Gophers,
>> 
>> Is there a Golang based tool (or library) tool to convert svg to png or jpg?
>> 
>> regards,
>> 
>> Will
>> 
>> -- 
>> 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/d03ad514-1e56-42a3-b7c6-798346a76ca1%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/BF136C90-3061-4E01-890B-A6FB38E94E07%40ix.netcom.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CALoEmQw_8%3D3AkkrmZNG9Xrzq37TaauFF77wJUGjkp-Mx3%3DrUPQ%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5B2E195B-65B6-4D3A-B1C6-6208AB116645%40gmail.com.

Re: [go-nuts] Go Tool to convert svg to png/jpg

[Michael Jones]

Just to be clear: PNG is a description of pixel values comprising an image
(RGBa, RGBa, RGBa, ...), SVG is a program for creating an image (set color
to blue, draw a circle, change to red, draw a line, ...). Going from SVG
(scalable vector graphics) to pixels is to render an image by executing the
simple program of graphical operation codes. (As said above)

Solutions depending on situation: most every browser has code to rasterize
SVG. Can you invoke one to produce your image? There are numerous free
tools to do the same--can you bundle one of those and invoke it as an
external program? Cairo can do it. (these are in addition to what you
really seem to want, which is a fully Go SVG -> PNG renderer.)

Good luck in your project,
michael

On Fri, Jan 31, 2020 at 6:03 PM robert engels  wrote:

> There is no cross-platform graphics library included in Go.
>
> Most likely you’ll need a C binding to Qt or similar to perform the
> rasterization.
>
> You might be able to put one together using something like
> https://github.com/hajimehoshi/ebiten
>
>
> On Jan 31, 2020, at 7:31 PM, maithri.fri...@gmail.com wrote:
>
> I'm looking for one too but can't find anything online either..
>
> On Monday, March 9, 2015 at 11:35:51 PM UTC-7, will wrote:
>>
>> Hi Gophers,
>>
>> Is there a Golang based tool (or library) tool to convert svg to png or
>> jpg?
>>
>> regards,
>>
>> Will
>>
>
> --
> 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/d03ad514-1e56-42a3-b7c6-798346a76ca1%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/BF136C90-3061-4E01-890B-A6FB38E94E07%40ix.netcom.com
> 
> .
>


-- 

*Michael T. jonesmichael.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQw_8%3D3AkkrmZNG9Xrzq37TaauFF77wJUGjkp-Mx3%3DrUPQ%40mail.gmail.com.

Re: [go-nuts] Go Tool to convert svg to png/jpg

[robert engels]

There is no cross-platform graphics library included in Go.

Most likely you’ll need a C binding to Qt or similar to perform the 
rasterization.

You might be able to put one together using something like 
https://github.com/hajimehoshi/ebiten


> On Jan 31, 2020, at 7:31 PM, maithri.fri...@gmail.com wrote:
> 
> I'm looking for one too but can't find anything online either..
> 
> On Monday, March 9, 2015 at 11:35:51 PM UTC-7, will wrote:
> Hi Gophers,
> 
> Is there a Golang based tool (or library) tool to convert svg to png or jpg?
> 
> regards,
> 
> Will
> 
> -- 
> 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/d03ad514-1e56-42a3-b7c6-798346a76ca1%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/BF136C90-3061-4E01-890B-A6FB38E94E07%40ix.netcom.com.

[go-nuts] Re: Go Tool to convert svg to png/jpg

[maithri . friend]

I'm looking for one too but can't find anything online either..

On Monday, March 9, 2015 at 11:35:51 PM UTC-7, will wrote:
>
> Hi Gophers,
>
> Is there a Golang based tool (or library) tool to convert svg to png or 
> jpg?
>
> regards,
>
> Will
>

-- 
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/d03ad514-1e56-42a3-b7c6-798346a76ca1%40googlegroups.com.

Re: [go-nuts] [Proposal] Change how gofmt formats struct fields

[David Riley]

On Jan 30, 2020, at 8:46 AM, Manlio Perillo  wrote:
> 
> Yes.
> 
> In fact I wrote that alignment should be done by the editor, not gofmt.

In this scenario, the editor needs to understand Go formatting and apply 
special formatting to tabs within struct fields? I strongly discourage this.

It will also make structs look TERRIBLE when viewed as plain text (witness the 
large corpus of C code which is only legible when viewed at a specific tab 
width because their authors used this approach).

Go's current hard-tab predilection works currently because tabs are always 
starting at a constant left offset (0) from the start of line; this is not the 
case in struct fields, variable declarations, etc.


Please don't do this.  Or make it an opt-in.  This is not a good change to 
force on users by default.


- Dave

-- 
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/3D13001F-03D8-474B-9418-EBC84547EDE9%40gmail.com.

Re: [go-nuts] go test -c in go 1.13 does not include -test.timeout flag in binary?

[Ian Lance Taylor]

On Fri, Jan 31, 2020 at 10:33 AM Craig Rodrigues  wrote:
>
>
> On Friday, January 31, 2020 at 7:23:32 AM UTC-8, Ian Lance Taylor wrote:
>>
>>
>> Calling flag.Parse in an init function never worked reliably, unless
>> you took special care.  Flags are themselves often defined in init
>> functions, so calling flag.Parse in an init function will see the
>> flags that were defined before the point of the call but not the flags
>> defined after the point of the call.  I guess it was working for you,
>> but small changes in your code could have caused it to stop working.
>> We didn't document that calling flags.Parse in an init function didn't
>> work reliably because we didn't realize that anybody would ever do it.
>> The documentation always just said "After all flags are defined, call
>> flag.Parse", and "Must be called after all flags are defined and
>> before flags are accessed by the program" without spelling out that if
>> you call it in an init function you won't necessarily be calling it
>> after all flags are defined.
>>
>> The change to the testing package changed exactly when the testing
>> flags are defined with respect to init functions, and it caused many
>> cases of calling flag.Parse from an init function to break.  But those
>> cases were already fragile and could have been broken in other ways
>> also.
>>
>> If you don't call flag.Parse from an init function you will be
>> following the documentation, and that will continue to work.
>>
>> Sorry for the trouble.
>>
>
>
>
> Thanks for the response.  I have a few questions.
>
> 1.  In https://golang.org/pkg/flag/#Parse , would it be appropriate to add a 
> warning to not call this function from inside init()?
>  This was not obvious to me from reading the docs.

Documentation should normally be precise and not overly long.  I
personally don't feel that an explicit comment about calling
flag.Parse from an init function carries its weight.  The
documentation is already clear that you must only call Parse after
defining all flags, and as noted previously you have limited control
over initialization order.  I think that more useful would be to
implement https://golang.org/issue/33190 (contributions welcome).


> 2.   To fix my problem, I removed flag.Parse() completely.  Is that the 
> appropriate fix?  Where would it be appropriate for me
>   to call flag.Parse()?  Or should I never bother calling it (inside test 
> files)?

It's not necessary to call flag.Parse in a test.  The test harness
will call it for you.  It's OK to call flag.Parse from a TestMain
function, and in fact that is required if TestMain is going to change
its behavior based on a flag (this is documented at
https://golang.org/pkg/testing/#hdr-Main).  Broadly speaking, the only
other place that Go code should call flag.Parse is in the main
function, though of course there can be specific reasons to call it
from other places.


> 3.   Is calling flag.Parse() from inside https://golang.org/pkg/testing/#Init 
> supposed to work?  I tried that and it also did not work.

That is a function in the standard library, so I'm not sure what you
are asking.  Are you changing the standard library?  There shouldn't
be a need to do that in order to parse flags.

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/CAOyqgcWvo_tnv3e5Rq_nX8Njsn36hyjD_eY3SNOU7uV9qugW%3DQ%40mail.gmail.com.

Re: [go-nuts] [Proposal] Change how gofmt formats struct fields

[Brian Candler]

I use "diff -ubB foo bar" to compare files where I don't care about 
whitespace differences (-b within line, -B for blank lines).

I believe "git diff" supports -b too.

-- 
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/3e45a345-bc08-4602-985a-9bff609f%40googlegroups.com.

Re: [go-nuts] Re: go1.12.16 not tagged on release-branch.go1.12?

[peterGo]

Sue,

I saw a person reporting a bug, mistake, or inconsistency, which I 
confirmed. Filing a ticket on the Go issue tracker asks for a recipe for 
reproducing the error.

The Go Project 
https://golang.org/project/

Reporting issues
https://github.com/golang/go/issues

If you spot bugs, mistakes, or inconsistencies in the Go project's code or 
documentation, please let us know by filing a ticket on our issue tracker. 

filing a ticket: https://github.com/golang/go/issues/new

Peter

On Wednesday, January 29, 2020 at 9:25:49 AM UTC-5, Sue Spence wrote:
>
> I saw a person asking a question, not submitting a bug. There was a 
> certain something about your response, that fronted as helpful but didn't 
> really come across that way. 
>
>
> On Wednesday, 29 January 2020 13:55:48 UTC, peterGo wrote:
>>
>> Steve,
>>
>> "Your example reproduces the error. "
>>
>> Yes, I posted the error in reproducible form. The first step in fixing a 
>> bug. The Go team can confirm the bug and verify that their fix works. No 
>> guesswork required.
>>
>> Peter
>>
>> On Wednesday, January 29, 2020 at 8:41:48 AM UTC-5, Steve Mynott wrote:
>>>
>>> Your example reproduces the error. 
>>>
>>> I'd expect ./go version to return 
>>>
>>> "go version go1.12.16 linux/amd64" since that's the latest version 
>>>
>>>
>>>
>>>
>>> On 29/01/2020, peterGo  wrote: 
>>> > Steve, 
>>> > 
>>> > "I don't see" 
>>> > 
>>> > Please provide reproducible errors. For example, 
>>> > 
>>> > [security] Go 1.13.7 and Go 1.12.16 are released 
>>> > https://groups.google.com/forum/#!topic/golang-nuts/4uVpv5Zfxvo 
>>> > 
>>> > ~$ git clone https://github.com/golang/go --depth 1 -b 
>>> > release-branch.go1.12 go1.12 
>>> > Cloning into 'go1.12'... 
>>> > remote: Enumerating objects: 9305, done. 
>>> > remote: Counting objects: 100% (9305/9305), done. 
>>> > remote: Compressing objects: 100% (7682/7682), done. 
>>> > remote: Total 9305 (delta 1465), reused 4643 (delta 1134), pack-reused 
>>> 0 
>>> > Receiving objects: 100% (9305/9305), 21.22 MiB | 11.94 MiB/s, done. 
>>> > Resolving deltas: 100% (1465/1465), done. 
>>> > ~$ cd go1.12/src 
>>> > ~/go1.12/src$ ./make.bash 
>>> > Building Go cmd/dist using /home/peter/go1.4. 
>>> > Building Go toolchain1 using /home/peter/go1.4. 
>>> > Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1. 
>>> > Building Go toolchain2 using go_bootstrap and Go toolchain1. 
>>> > Building Go toolchain3 using go_bootstrap and Go toolchain2. 
>>> > Building packages and commands for linux/amd64. 
>>> > --- 
>>> > Installed Go for linux/amd64 in /home/peter/go1.12 
>>> > Installed commands in /home/peter/go1.12/bin 
>>> > ~/go1.12/src$ cd ../bin 
>>> > ~/go1.12/bin$ ./go version 
>>> > go version go1.12.15 linux/amd64 
>>> > ~/go1.12/bin$ 
>>> > 
>>> > Peter 
>>> > 
>>> > On Wednesday, January 29, 2020 at 6:30:23 AM UTC-5, Steve Mynott 
>>> wrote: 
>>> >> 
>>> >> I don't see go1.12.16 tagged on release-branch.go1.12? 
>>> >> 
>>> >> Is this expected? 
>>> >> 
>>> >> -- 
>>> >> Steve Mynott > 
>>> >> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 
>>> >> 
>>> > 
>>> > -- 
>>> > 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 golan...@googlegroups.com. 
>>> > To view this discussion on the web visit 
>>> > 
>>> https://groups.google.com/d/msgid/golang-nuts/3522d571-43da-48c3-8158-286ce7c4b092%40googlegroups.com.
>>>  
>>>
>>> > 
>>>
>>>
>>> -- 
>>> Steve Mynott  
>>> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 
>>>
>>

-- 
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/79d5ec78-f0d8-4c5f-84ff-3b48d7949c2e%40googlegroups.com.

Re: [go-nuts] go test -c in go 1.13 does not include -test.timeout flag in binary?

[Craig Rodrigues]

On Friday, January 31, 2020 at 7:23:32 AM UTC-8, Ian Lance Taylor wrote:
>
>
> Calling flag.Parse in an init function never worked reliably, unless 
> you took special care.  Flags are themselves often defined in init 
> functions, so calling flag.Parse in an init function will see the 
> flags that were defined before the point of the call but not the flags 
> defined after the point of the call.  I guess it was working for you, 
> but small changes in your code could have caused it to stop working. 
> We didn't document that calling flags.Parse in an init function didn't 
> work reliably because we didn't realize that anybody would ever do it. 
> The documentation always just said "After all flags are defined, call 
> flag.Parse", and "Must be called after all flags are defined and 
> before flags are accessed by the program" without spelling out that if 
> you call it in an init function you won't necessarily be calling it 
> after all flags are defined. 
>
> The change to the testing package changed exactly when the testing 
> flags are defined with respect to init functions, and it caused many 
> cases of calling flag.Parse from an init function to break.  But those 
> cases were already fragile and could have been broken in other ways 
> also. 
>
> If you don't call flag.Parse from an init function you will be 
> following the documentation, and that will continue to work. 
>
> Sorry for the trouble. 
>
>


Thanks for the response.  I have a few questions.

1.  In https://golang.org/pkg/flag/#Parse , would it be appropriate to add 
a warning to not call this function from inside init()?
 This was not obvious to me from reading the docs.

2.   To fix my problem, I removed flag.Parse() completely.  Is that the 
appropriate fix?  Where would it be appropriate for me
  to call flag.Parse()?  Or should I never bother calling it (inside 
test files)?

3.   Is calling flag.Parse() from inside 
https://golang.org/pkg/testing/#Init supposed to work?  I tried that and it 
also did not work.

Thanks again.
--
Craig

-- 
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/6300b452-f67a-4a17-9c7d-fa2f9feb82ee%40googlegroups.com.

[go-nuts] [ANN] SFTPGo Cloud Storage support

[Nicola Murino]

Hi all,

SFTPGo gained support for serving some Cloud Storage backends over 
SFTP/SCP, currently we support:

- S3 Compatible Object Storage
- Google Cloud Storage

Each SFTP user can be mapped to a whole bucket or to a bucket virtual 
folder.
Mapping a virtual folder is very similar to a chroot directory for the 
local filesystem: you can expose different virtual folders of the same 
bucket to different SFTP users. Each SFTP user can only access to the 
assigned virtual folder and to its contents.

If you are interested to this feature please test the latest SFTPGo Git 
revision and report any issues or suggestions here:

https://github.com/drakkan/sftpgo/issues

Yours sincerely,
Nicola

-- 
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/bf6b61d4-95b5-4a1f-ad5e-e1a4bd104aa9%40googlegroups.com.

Re: [go-nuts] annoing: runtime error: cgo argument has Go pointer to Go pointer

[Andreas Otto]

thanks to the Info, don't have profiled this overhead… It was just an 
assumtion.

Am Donnerstag, 30. Januar 2020 18:12:50 UTC+1 schrieb Jake Montgomery:
>
>
>
> On Thursday, January 30, 2020 at 2:31:59 AM UTC-5, Andreas Otto wrote:
>>
>>
>>
>> Am Mittwoch, 29. Januar 2020 23:19:34 UTC+1 schrieb Bruno Albuquerque:
>>>
>>> One way to work this around is to use 
>>> https://github.com/mattn/go-pointer.
>>>
>>>
>>> thanks, but also use this kind of "*HASH based and export the hash 
>> handle*" solution.
>> But I call this a "slow" solution, because of the *hash* and *locks* 
>> overhead.
>>
>
> You may call it "slow", but have you actually profiled it in your real 
> world application and found the map lookup to be an actual bottleneck? 
> Unless you are doing something very extreme I would expect the overhead of 
> the Go/C transitions to vastly outweigh a map lookup. Of course, if that is 
> the case there are  clever things you could do to reduce the lookup 
> overhead, but they would depend on the exact details of the extreme thing 
> you are doing that makes it a problem in the first place. 
>

-- 
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/c5655eac-295f-49c4-bbe5-f44fbc975200%40googlegroups.com.

[go-nuts] Re: annoing: runtime error: cgo argument has Go pointer to Go pointer

[Andreas Otto]

I do nothing on *C* with this pointer… I just give the Pointer as Argument 
to an *GO* callback.

Am Donnerstag, 30. Januar 2020 14:25:48 UTC+1 schrieb Tamás Gulácsi:
>
>
>
> How do you handle the interface types on the C side? If you call back to 
> Go exported functions,
> then you shouldn't travel the Go values - push them in a map, and travel 
> the handle (uint64).
>
>
>

-- 
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/350d2a81-fc9e-4c06-9986-a082707fdda4%40googlegroups.com.

Re: [go-nuts] go test -c in go 1.13 does not include -test.timeout flag in binary?

[Ian Lance Taylor]

On Fri, Jan 31, 2020 at 12:19 AM Craig Rodrigues  wrote:
>
> On Thursday, January 30, 2020 at 11:03:04 PM UTC-8, Craig Rodrigues wrote:
>>
>>
>>
>> On Thursday, January 30, 2020 at 10:06:36 PM UTC-8, Ian Lance Taylor wrote:
>>>
>>> On Thu, Jan 30, 2020 at 9:43 PM Craig Rodrigues  wrote:
>>> > I see here that this might be related: 
>>> > https://golang.org/doc/go1.13#testing
>>> >
>>> >   Testing flags are now registered in the new Init function,
>>> >   which is invoked by the generated main function for the test.
>>> >   As a result, testing flags are now only registered when running
>>> >   a test binary, and packages that call flag.Parse during package
>>> >   initialization may cause tests to fail.
>>> >
>>> > But I'm not sure how to move forward to get back the behavior from go 
>>> > 1.12.
>>>
>>> That could well be the problem.  If so, the solution is to not call
>>> flag.Parse from an init function.
>>
>>
>>
>> Ah OK!
>>
>> So my_test.go , and every test file in my codebase has:
>>
>> func init() {
>> ParseFlags()
>> }
>>
>> which calls flag.Parse for a bunch of framework-specific test flags.
>>
>> How should I restructure this so that I get the "-test.XXX" flags generated 
>> in the binary,
>> like I did with go 1.12?
>
>
>
> This change in go test seems due to this:
>
>  https://github.com/golang/go/issues/21051
>  https://go-review.googlesource.com/c/go/+/173722/
>
>
> so for my function:
>
> func init() {
> ParseFlags()
> }
>
> I went in the ParseFlags() function and removed a call to flag.Parse() as
> suggested by Ian (thanks for that suggestion!).
>
> That seemed to fix things for me.
>
> Will this be guaranteed to work in future go versions, or could this behavior 
> change if something
> else changes in the internals of go test?

This will work in future Go versions.

Calling flag.Parse in an init function never worked reliably, unless
you took special care.  Flags are themselves often defined in init
functions, so calling flag.Parse in an init function will see the
flags that were defined before the point of the call but not the flags
defined after the point of the call.  I guess it was working for you,
but small changes in your code could have caused it to stop working.
We didn't document that calling flags.Parse in an init function didn't
work reliably because we didn't realize that anybody would ever do it.
The documentation always just said "After all flags are defined, call
flag.Parse", and "Must be called after all flags are defined and
before flags are accessed by the program" without spelling out that if
you call it in an init function you won't necessarily be calling it
after all flags are defined.

The change to the testing package changed exactly when the testing
flags are defined with respect to init functions, and it caused many
cases of calling flag.Parse from an init function to break.  But those
cases were already fragile and could have been broken in other ways
also.

If you don't call flag.Parse from an init function you will be
following the documentation, and that will continue to work.

Sorry for the trouble.

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/CAOyqgcXPkwXFXfdbkKvGeeiOWSWCet4jYjCR02ofq2mo3KKuFw%40mail.gmail.com.

Re: [go-nuts] map memory usage

[Ian Lance Taylor]

On Fri, Jan 31, 2020 at 2:48 AM  wrote:
>
> Is there a better way to estimate the memory usage of a map, other than the 
> following:
> https://play.golang.org/p/MLSd84CJB3R

The memory usage of a map is going to depend on the history of how the
map is used.

That said, a map is an array of buckets.  Each bucket holds 8 keys and
8 values.  The buckets will normally be more than half full on
average, though that will depend on the exact history of additions and
deletions.  You can use that information to roughly estimate the
memory usage of a map given the key size, the value size, and the
number of entries.

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/CAOyqgcV-hQBjWBW%2BdE4taFqYEe9X8tMeqP69nZd-8L6f0%2BJrXw%40mail.gmail.com.

[go-nuts] go mod vendor command leads to LF will be replaced by CRLF warning

[sitbackandwait]

Hi,

I am migrating a project to go modules. I have already moved everything to 
the vendor folder and checked in the files.
After running go mod vendor on the clean working git tree, one of the files 
from a dependency, runbench.cmd, appears to
be changed according to git. I am getting the following warning:

warning: LF will be replaced by CRLF in 
vendor/github.com/klauspost/compress/snappy/runbench.cmd.
The file will have its original line endings in your working directory.

In the repos gitattributes file *.cmd files configured to keep their 
original line endings, CRLF:
*.cmdtext eol=crlf

It seems like go mod command does not take newlines into account when 
downloading packages.

Do you have any suggestion on how to fix this problem besides checking out 
the file again or adding a special
rule to gitattributes for this file?

I am using go 1.13.7 on linux/amd64.

Thank you in advance!

BR,
n

-- 
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/3317ff08-82db-4c8f-9780-9d0ab20f1dbe%40googlegroups.com.

[go-nuts] map memory usage

[pierre . curto]

Hello,

Is there a better way to estimate the memory usage of a map, other than the 
following:
https://play.golang.org/p/MLSd84CJB3R

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/d4a7a9fc-f303-4fbc-9b80-d58486e9a78d%40googlegroups.com.

Re: [go-nuts] go test -c in go 1.13 does not include -test.timeout flag in binary?

[Craig Rodrigues]

On Thursday, January 30, 2020 at 11:03:04 PM UTC-8, Craig Rodrigues wrote:
>
>
>
> On Thursday, January 30, 2020 at 10:06:36 PM UTC-8, Ian Lance Taylor wrote:
>>
>> On Thu, Jan 30, 2020 at 9:43 PM Craig Rodrigues  
>> wrote: 
>> > I see here that this might be related: 
>> https://golang.org/doc/go1.13#testing 
>> > 
>> >   Testing flags are now registered in the new Init function, 
>> >   which is invoked by the generated main function for the test. 
>> >   As a result, testing flags are now only registered when 
>> running 
>> >   a test binary, and packages that call flag.Parse during 
>> package 
>> >   initialization may cause tests to fail. 
>> > 
>> > But I'm not sure how to move forward to get back the behavior from go 
>> 1.12. 
>>
>> That could well be the problem.  If so, the solution is to not call 
>> flag.Parse from an init function. 
>>
>
>
> Ah OK!
>
> So my_test.go , and every test file in my codebase has:
>
> func init() {
> ParseFlags()
> }
>
> which calls flag.Parse for a bunch of framework-specific test flags.
>
> How should I restructure this so that I get the "-test.XXX" flags 
> generated in the binary,
> like I did with go 1.12?
>


This change in *go test* seems due to this:

 https://github.com/golang/go/issues/21051
 https://go-review.googlesource.com/c/go/+/173722/


so for my function:

func init() {
ParseFlags()
}

I went in the ParseFlags() function and removed a call to flag.Parse() as
suggested by Ian (thanks for that suggestion!).

That seemed to fix things for me.

Will this be guaranteed to work in future go versions, or could this 
behavior change if something
else changes in the internals of go test?

--
Craig

-- 
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/bf1c9a89-036d-4aa4-b9a0-9ef60e15dd90%40googlegroups.com.