from:"Joseph Lorenzini"

Re: [go-nuts] What happened to sep in errorrs.join

2023-08-08 Thread Joseph Lorenzini

Thanks that was very helpful. As for your point about slog, yes a custom
handler could but I am using the library json handler.

I suppose the proper way to frame my problem is that I am using the slog
library handler and I do not want new lines in the message or keys.

Would the go team would be open to providing knobs to control how the
handler does formatting? I assumed if I tried opening a proposal like that
I’d be told to write a custom handler. :)

On Mon, Aug 7, 2023 at 3:56 PM Ian Lance Taylor  wrote:

> On Mon, Aug 7, 2023 at 4:32 AM jal...@gmail.com  wrote:
> >
> > In the errors.join proposal, the proposed api had the user specify how
> they wanted the errors to be formatted together. But the actual
> implementation omitted and only used new line.
> >
> > This is quite unfortunate if you are using slog and want to log that
> error and very much need a log statement to not span multiple lines. It
> also makes it much harder to read.
> >
> > Does anyone recall why sep was dropped?
>
> See the discussion at https://go.dev/issue/53435, especially
> https://github.com/golang/go/issues/53435#issuecomment-1190654775 and
> https://github.com/golang/go/issues/53435#issuecomment-1190845424.
>
> As far as the slog package it seems to me that a handler can enforce
> that individual messages are on a single line.  There may be a better
> way to address that problem, but I don't think that errors.Join is the
> right place for a fix.  Any random package can generate multiline
> error messages with errors.New("a\nb"), and I've seen plenty that do.
> So enforcing single-line messages on errors.Join won't fix the problem
> in general.
>
> 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/CAMvD0VK7JkStS-wuFmkmBROh0f5WbcNuAD-sHDynS0Oq8CS%2B1Q%40mail.gmail.com.

[go-nuts] A Big Thank You to the Contributors of pkg.go.dev

2020-11-10 Thread Joseph Lorenzini

Hi all,

I was looking up some documentation for a go package and I was
redirected to pkg.go.dev. Unlike godoc, it doesn't have an index which
is my go-to for exploring the API surface of a package. I wondered if
others had the same problem. Came across
https://github.com/golang/go/issues/41587 which led me to
https://beta.pkg.go.dev. Lo and behold the index is back!

This is fantastic and I can't say enough good things about the
redesigned site. It's fast, easy to search, and the UX makes it just
as easy to explore the API of a package as godoc did.

Like any community around open source software, most of the
conversations are about problems users are having and shortcomings in
that software. Sometimes though I think it's a good thing to let
people know that they did a good job and the work is appreciated.
Might even help with open source contributor burn out.

Thanks,
Joe

-- 
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/CAMvD0VJP52L3QHMTLhYMHEAH_f-QMvOS0SsZL%2BD9%2BQUNtqMnqg%40mail.gmail.com.

[go-nuts] Lenient Parsing of Date Time Strings

2020-02-03 Thread Joseph Lorenzini


Hi all,

In the java standard library, there is a lenient mode, where heuristics are 
used to take a potentially invalid string and convert it to a valid date 
time.

https://docs.oracle.com/javase/8/docs/api/java/text/DateFormat.html#setLenient-boolean-

For example, a date like this 1983-02-00T00:00:00Z may turn into something 
like this 1983-01-31T00:00:00Z. Now obviously the standard time library 
doesn't support this and its perfectly understandable why. My question is 
whether there's a third party library that does something like this?

Thanks,
Joe 

-- 
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/1a86ce52-92f0-486a-86bd-c1995c2f1579%40googlegroups.com.

[go-nuts] Future of Error Formatting in the Standard Library

2020-01-05 Thread Joseph Lorenzini


Hi all,


In the Go 2: Errors Proposal (issue 29934), a decision was made to defer 
error formatting changes and come up with a revised proposal for 1.14. I 
believe 1.14 is close to being release but I have not seen a proposal. I 
was curious if something is still in the works for this or whether this has 
been put on hold indefinitely. 

Asking because, it seems like something similar to what xerrors does with 
annotating and printing stack frames would be really useful in the standard 
lib for making go code in general easier to debug. 

https://github.com/golang/go/issues/29934#issuecomment-489682919

Thank,
Joe 

-- 
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/edb990ae-c2b8-4a3e-8893-c19e91d0fb91%40googlegroups.com.

[go-nuts] tracking down broken module dependency golint

2019-06-03 Thread Joseph Lorenzini

Hi all,

I've been happily using go modules for several months. A couple days ago, I
decided to update my dependencies with go get -u. This failed with:

go: github.com/golang/lint@v0.0.0-20190409202823-959b441ac422: parsing
go.mod: unexpected module path "golang.org/x/lint"

Which led me to: https://github.com/golang/go/issues/30831

So then I added a replace directive but that failed too because of
https://github.com/golang/go/issues/26904

Which means as long as I depend on the golint package, then go get -u will
not work. And then it occurred to me: how and why is this package being
pulled in? If i can remove my module's transitive dependency on golint,
then go get -u will start working. So I first ran go mod tidy. Then I used
go mod why however that was no help because whenever i executed go mod why
on the module, this is the output returned:

(main module does not need module github.com/golang/lint)

I also verified that github.com/golang/lint is not in my go.mod after
running go mod tidy. My understanding of tidy is that it pulls in direct
and transitive module dependencies ergo if go get -u is trying to upgrade
my deps according to go.mod, then it should be in my go.mod. So I am
stumped why go get -u is trying to upgrade golint, when according to go mod
tidy, my go.mod file, and go mod why, I don't have a dependency on it.

Any advice would be appreciated.

Thanks,
Joe

--
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/0cb6129b-32aa-4be5-aa33-ab266ab2317c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] favorite retry libraries

2019-04-22 Thread Joseph Lorenzini

Hi all,

I am looking for a simple retry library that supports exponential backoffs 
and cancellation via context. I have found several but nothing is standing 
out for me. I was curious to see what experience people have had with the 
various retry libraries out there and what you'd recommend and why.

Thanks,
Joe 

-- 
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] go mod verify fails for github.com/docker/docker and github.com/hashicorp/go-rootcerts

2019-02-18 Thread Joseph Lorenzini

Hi all,

I've been using go modules since 1.10. I am now on 1.11.5. Go mod verify is 
now failing since I went to go 1.11. Negative is old, plus is new.

-github.com/docker/docker v0.7.3-0.20180827131323-0c5f8d2b9b23 
h1:Zl/9mUfPbYbnv895OXx9WfxPjwqSZHohuZzVcjJ5QPQ=
+github.com/docker/docker v0.7.3-0.20180827131323-0c5f8d2b9b23 
h1:mJtkfC9RUrUWHMk0cFDNhVoc9U3k2FRAzEZ+5pqSIHo=
-github.com/hashicorp/go-rootcerts v0.0.0-20160503143440-6bb64b370b90 
h1:9HVkPxOpo+yO93Ah4yrO67d/qh0fbLLWbKqhYjyHq9A=
+github.com/hashicorp/go-rootcerts v0.0.0-20160503143440-6bb64b370b90 
h1:VBj0QYQ0u2MCJzBfeYXGexnAl17GsH1yidnoxCqqD9E=

I can "fix" this by simply removing the offending entries and allowing go 
mod tidy to repopulate them. However, that defeats the purpose of the 
go.sum, which is to say if a go mod verify has failed, then this should 
mean that the source code I thought I had no longer exists.  What I am 
trying to figure out is if the way go calculates the hashes has changed and 
there was or is a bug in that *or *the source code for these two packages 
at the given git commit ID no longer matches the source code checked out on 
disk. The later is more concerning to me.

Thanks,
Joe 

-- 
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: performance of go mod verify

2019-01-28 Thread Joseph Lorenzini

Hi pudds,

I’ve run go mod verify multiple times on my laptop for the same module. The
elapsed time for the command to run is always 25 seconds or thereabouts. So
I figured that whatever caching might be there, I would be getting it.

I can try this with go mod vendor and see if that helps but I’d be
surprised if it did. Why would the vendor directory instead of mod cache
make a difference ?

Joe

On Mon, Jan 28, 2019 at 2:09 PM  wrote:

> Hi Joe,
>
> Sorry, I realized I pasted in the wrong quote from the documentation.
>
> I meant to include this quote instead (from
> https://golang.org/cmd/go/#hdr-Module_downloading_and_verification):
>
> "The go command maintains, in the main module's root directory alongside
> go.mod, a file named go.sum containing the expected cryptographic checksums
> of the content of specific module versions. Each time a dependency is used,
> its checksum is added to go.sum if missing or else required to match the
> existing entry in go.sum.
>
> The go command maintains a cache of downloaded packages and computes and
> records the cryptographic checksum of each package at download time. In
> normal operation, the go command checks these pre-computed checksums
> against the main module's go.sum file, instead of recomputing them on each
> command invocation. The 'go mod verify' command checks that the cached
> copies of module downloads still match both their recorded checksums and
> the entries in go.sum."
>
> Regards,
> thepudds
>
> On Monday, January 28, 2019 at 2:53:17 PM UTC-5, thepud...@gmail.com
> wrote:
>>
>> Hi Joe,
>>
>> As far as I know, I think it is computing the SHA256 of the dependencies:
>>
>>
>> https://github.com/golang/go/blob/release-branch.go1.11/src/cmd/go/internal/dirhash/hash.go#L25
>>
>> Personally, I wouldn't expect that to get pathologically worse with more
>> dependencies.
>>
>> Also, just as you can often sequence 'go mod download' so that you can
>> often take advantage of cached dependencies in CI, there is some chance you
>> could do something similar with 'go mod verify' to avoid that cost every
>> time?
>>
>> In terms of how it all works, there is a bit more in the documentation
>> here:
>>
>> https://golang.org/cmd/go/#hdr-Modules_and_vendoring
>>
>> "By default, the go command satisfies dependencies by downloading modules
>> from their sources and using those downloaded copies (after verification,
>> as described in the previous section). To allow interoperation with older
>> versions of Go, or to ensure that all files used for a build are stored
>> together in a single file tree, 'go mod vendor' creates a directory named
>> vendor in the root directory of the main module and stores there all the
>> packages from dependency modules that are needed to support builds and
>> tests of packages in the main module."
>>
>> Regards,
>> thepudds
>>
>> On Monday, January 28, 2019 at 1:14:53 PM UTC-5, Joseph Lorenzini wrote:
>>>
>>> All:
>>>
>>> I'd like to run go mod verify as part of the CI/CD. If the verify fails,
>>> the build fails. However, the amount of time it takes to run for a small
>>> project is making me question whether that's viable. I don't actually know
>>> of any documentation that explains how slow or fast one should expect a go
>>> mod verify to take to run nor how much time it will increase as you add
>>> packages (e.g as you add packages is the increase linear or is it more
>>> complicated than that?).
>>>
>>> I have a project with a go.mod with 113 require statements. Here's the
>>> file.
>>>
>>> https://gist.github.com/jaloren/564d55145699c2a933798aec334d7ee9
>>>
>>> I am go 1.11.1 on Mac OS. I've already run go build and primed the local
>>> cache. When I run go mod verify, it completes in 25 seconds. I have no way
>>> to know if that's slow or fast since I don't understand what the the
>>> internals are doing. All I found on modules FAQs is this:
>>>
>>> "In addition, go mod verify checks that the on-disk cached copies of
>>> module downloads still match the entries in go.sum."
>>>
>>> But I'd like to find out is if this is going to get pathologically worse
>>> as packages are added. A minute or two is an easy sell. Past 5 minutes
>>> becomes a much harder one.
>>>
>>> Joe
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/EAiHWkxTc-o/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

[go-nuts] performance of go mod verify

2019-01-28 Thread Joseph Lorenzini

All: 

I'd like to run go mod verify as part of the CI/CD. If the verify fails, 
the build fails. However, the amount of time it takes to run for a small 
project is making me question whether that's viable. I don't actually know 
of any documentation that explains how slow or fast one should expect a go 
mod verify to take to run nor how much time it will increase as you add 
packages (e.g as you add packages is the increase linear or is it more 
complicated than that?).

I have a project with a go.mod with 113 require statements. Here's the file.

https://gist.github.com/jaloren/564d55145699c2a933798aec334d7ee9

I am go 1.11.1 on Mac OS. I've already run go build and primed the local 
cache. When I run go mod verify, it completes in 25 seconds. I have no way 
to know if that's slow or fast since I don't understand what the the 
internals are doing. All I found on modules FAQs is this:

"In addition, go mod verify checks that the on-disk cached copies of module 
downloads still match the entries in go.sum."

But I'd like to find out is if this is going to get pathologically worse as 
packages are added. A minute or two is an easy sell. Past 5 minutes becomes 
a much harder one.

Joe  

-- 
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 performance degrades in go module

2018-11-07 Thread Joseph Lorenzini



Hi all,

If have a go.mod, goimports takes 30 seconds to run. If I remove the 
go.mod, then goimports takes half a second to run. Is this expected? Is 
goimports trying to do something with the packages found in go.mod? Is 
there a way to configure goimports so it ignores go.mod?

Thanks,
Joe 

-- 
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] handling unexpected module path

2018-10-24 Thread Joseph Lorenzini


Hi all,

I have a deeply nested dependency somewhere that depends on go-resty. When 
I do a go list in my module, I see this error.

go: github.com/go-resty/resty@v1.10.0: parsing go.mod: unexpected module 
path "gopkg.in/resty.v1"
go: error loading module requirements

I checked out goresty and it does have a go.mod:

https://github.com/go-resty/resty/blob/v1.10.0/go.mod

The module name is gopkg.in/resty.v1

So what I am guessing is that some packages have imported 
github.com/go-resty/resty while others have imported gopkg.in/resty.v1. If 
every package imported gopkg.in/resty.v1 then i suspect this would just 
work since that's module name. I actually am not sure where in the 
dependency tree this is occurring. It could be I am using package A which 
depends on package B which requires package C and Package C is the one 
importing github.com/go-resty/resty. 

I tried a replace directive and that did not work.

replace (
github.com/go-resty/resty => gopkg.in/resty.v1 v1.10.0
)

Is there a recommended way to handle this? 

Thanks,
Joe 



-- 
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] Can go-dockerclient be built with go modules?

2018-08-16 Thread Joseph Lorenzini

Hi Peter,

Thanks that was very helpful. That issue describes my problem exactly.
Frankly, IMHO, the issue isn’t so much modules being buggy as docker being
a project with poorly managed versioning. It’s some of the worst I have
ever see.

For example, I don’t understand why they haven’t added a git tag for
v17.0.5. It makes me wonder whether anyone has asked the docker project if
they are willing to do semver and add a go.mod.

Joe

On Thu, Aug 16, 2018 at 4:55 AM Peter Waller  wrote:

> Another issue worth consulting, https://github.com/golang/go/issues/26208,
> which isn't yet marked as resolved.
>

-- 
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] Can go-dockerclient be built with go modules?

2018-08-11 Thread Joseph Lorenzini


All:

Using vgo, I haven't been able to build a go package with this library. 
Using go 1.10, I can successfully build this library.

https://github.com/fsouza/go-dockerclient

When I attempt to vgo build, I get this error

/Volumes/Repositories/go/pkg/mod/github.com/fsouza/go-dockerclient@v1.2.2/internal/archive/archive.go:21:2:
 
case-insensitive import collision: "github.com/sirupsen/logrus" and 
"github.com/Sirupsen/logrus"


According to logrus project (github.com/sirupsen/logrus), the lowercase 
variant should always be used. So I added, this replace to go.mod.

vgo mod edit 
-replace=github.com/Sirupsen/logrus=github.com/sirupsen/logrus@v1.0.6


But then vgo build fails, with this error:

go: github.com/sirupsen/logrus@v1.0.6 used for two different module 
paths (github.com/Sirupsen/logrus and github.com/sirupsen/logrus)

Aside from opening an issue with the library author or forking the library, 
Is there a standard way to handle this kind of problem so that a program 
will build again?

Thanks,
Joe 

-- 
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] what was learned from the dep experiment

2018-02-21 Thread Joseph Lorenzini

All:

So I read Russ Cox post and specifically noted this:

"But once we understand the design space better and can narrow it down to 
the few key features that must be supported, it will help the Go ecosystem 
to remove the other features, to reduce expressiveness, to adopt enforced 
conventions that make Go code bases more uniform and easier to understand 
and make tooling easier to build."


And here's Sam Boyer : 

"It [vgo] was created largely in isolation from the community’s work on 
dep, to the point where not only is there no shared code and at best 
moderate conceptual overlap, but a considerable amount of the insight and 
experience gleaned from dep as the “official experiment” is just discarded."


I don't have an attachment to vgo or dep one way or another. Package 
management is complicated. I don't believe there's a "right" answer so much 
as balancing tradeoffs. Someone is going to be upset that you don't support 
their specific workflow. But there's been very little explanation to the 
community about why the things dep did at a high level were thrown out. 

I am curious to know what those are. 

Thanks,
Joe

-- 
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] intelliji can't access go 1.10 std lib on Mac OS

2018-02-20 Thread Joseph Lorenzini

All:

I may just need to open a bug with intelliji but I find the behavior so 
peculiar that I thought i'd ask if anyone who codes go in intelliji may 
know what's going on.

I uninstalled go 1.9.3 and installed go 1.10. After I do that, intelliji 
can no longer find any packages in the std lib and autocomplete no longer 
works. third party packages its fine with. I reinstalled 1.9.3 and then 
intelliji can find the std lib again. Since I haven't upgraded intelliji, I 
am guessing something changed in 1.10 that's breaking intelliji's ability 
to access the std lib but I am at a loss as to how that could be.

I did verify that go 1.10 install is working (e.g go version go build go 
install all work etc)

Joe 

-- 
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] printing a struct fields that implements an error interface

2018-02-17 Thread Joseph Lorenzini

Hi all:

Per documentation:

"If an operand implements the error interface, the Error method will be 
invoked to convert the object to a string, which will then be formatted as 
required by the verb (if any)"

And this is so even if the struct implements the stringer interface. So if 
I print the struct, I get the error value. Is there anyway to force 
fmt.Print to output the struct fields, even when it implements the error 
interface? 

Thanks,
Joe 

-- 
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] building a linux binary with -race on a mac

2017-02-15 Thread Joseph Lorenzini

All:

I am writing and building my code on a mac. The code is a linux binary
though so its obviously a cross compilation. This works fine:

GOOS=linux GOARCH=amd64  go build .

This does not:

GOOS=linux GOARCH=amd64  go build -race .
go build: -race requires cgo; enable cgo by setting CGO_ENABLED=1

Nor does this:

 GOOS=linux GOARCH=amd64  CGO_ENABLED=1 go build -race .
# runtime/cgo
ld: unknown option: --build-id=none
clang: error: linker command failed with exit code 1 (use -v to see
invocation)



Go env below:

GOARCH="amd64"

GOBIN="/Users/jlorenzini/go/bin"

GOEXE=""

GOHOSTARCH="amd64"

GOHOSTOS="darwin"

GOOS="darwin"

GOPATH="/Users/jlorenzini/go"

GORACE=""

GOROOT="/usr/local/go"

GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"

CC="clang"

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments
-fmessage-length=0
-fdebug-prefix-map=/var/folders/8w/7ndx_j6s36x9hm9dns67j21s3hynqn/T/go-build987997970=/tmp/go-build
-gno-record-gcc-switches -fno-common"

CXX="clang++"

CGO_ENABLED="1"

-- 
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] when you want to template a struct with private fields....

2016-12-31 Thread Joseph Lorenzini

Hi all,

So I know why this can't work. :) My question is the following: if you have 
a type that you want to be private (e.g struct), how would you template 
that data? Use a different data structure? Use reflection?

Joe 

-- 
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: text/template and preserving new lines from a struct field

2016-09-17 Thread Joseph Lorenzini

Actually, the issue is not the template but my logger. The logger is 
writing to os.Stderr for some reason that's not preserving new lines but if 
i do fmt.Println then the new lines are preserved.  Pretty sure i've made a 
simple error here and need to investigate more.


Joe 

On Saturday, September 17, 2016 at 7:44:55 AM UTC-5, Joseph Lorenzini wrote:
>
> Hi all,
>
> Say I have the following struct:
>
> type Info struct {
>Summary string
>Descstring
> }
>
> And this is the template string
>
> tmplStr  = `Summary={{.Summary}}, Desc={{.Desc}}`
>
> If the value of Desc has newlines, it looks like the template engine 
> strips those out and replaces them with spaces. Is there any way to force 
> the template engine to preserve the new lines?
>
> Thanks,
> Joe
>
>

-- 
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] text/template and preserving new lines from a struct field