Sooner the better, it's crept into downstream packages. E.g. docker
installed via brew is toast as it was built in 1.14.
On Wednesday, March 4, 2020 at 1:16:13 PM UTC-8, Jon Conradt wrote:
>
> You can follow the progress toward 1.14.1 via
> https://github.com/golang/go/milestone/137
>
> Looking
Looks like this was already resolved for 1.14.1
<https://github.com/golang/go/issues/37459>.
On Wednesday, February 26, 2020 at 11:00:24 AM UTC-8, James Pettyjohn wrote:
>
> A little further digging shows that VZEROUPPER is part of the AVX
> instruction set, not supported on any
it's better
than cutting off support for these machines which can run High Sierra. Once
support for High Sierra is dropped then it should not matter as it takes a
2013 or later model to run anything after High Sierra.
- James
On Wednesday, February 26, 2020 at 10:29:33 AM UTC-8, James Pettyjohn
I am trying to run go1.14 on macOS 10.13.2 with on a late 2009 iMac with an
i7 but always get the same crash:
SIGILL: illegal instruction
PC=0x1066040 m=0 sigcode=1
goroutine 1 [running, locked to thread]:
runtime.asyncPreempt()
/usr/local/go/src/runtime/preempt_amd64.s:8
Hi,
While not the most likely of scenarios, I'm having to write a lot of
integration around existing command line tools and want a better way then
passing strings/constants around.
While there are ample choices to go from command line arguments to structs
etc, I'm not finding anything besides
nd get JSON output.
>
> go help mod edit
>
> will given you the types you can then use to unmarshal the JSON.
>
> Failing that, the code that Dan referenced has been factored out into:
>
> https://godoc.org/github.com/rogpeppe/go-internal/modfile
>
> On Tu
t; For more detail on either of the above see:
>>
>> go help list
>>
>> >
>> > Best,
>> > James
>> >
>> > On Monday, September 2, 2019 at 10:58:53 PM UTC-7, Kurtis Rader wrote:
>> >>
>> >> On Mon, S
, total hack, but works).
Best,
James
On Monday, September 2, 2019 at 10:58:53 PM UTC-7, Kurtis Rader wrote:
>
> On Mon, Sep 2, 2019 at 10:44 PM James Pettyjohn > wrote:
>
>> This might be a bad idea but I'm trying to parse the go.mod file for data
>> as part of my build proc
Thanks. I saw the same being done by vgo - might be viable.
On Monday, September 2, 2019 at 10:52:45 PM UTC-7, kortschak wrote:
>
> Not really exposed, but there is code you could copy.
>
> https://golang.org/pkg/cmd/go/internal/modfile/#Parse
>
> On Mon, 2019-09-02 at
Hi,
This might be a bad idea but I'm trying to parse the go.mod file for data
as part of my build process - if at all possible I'd like to avoid
duplicating the data that is already there in another file.
Is there an exposed package that can be used for this?
- J
--
You received this
I've had multiple occasions where I've needed to train someone to be a
programmer from scratch in a Go environment.
Trouble I've found is while the go texts are simple and straightforward,
relatively speaking, they often written by someone who sought a better life
in go, fleeing Java/C/C++.
dependency
(making it then consistent with collate).
Best,
James
On Wednesday, April 26, 2017 at 5:06:57 PM UTC-7, Ian Lance Taylor wrote:
>
> [ + mpvl ]
>
> On Wed, Apr 26, 2017 at 4:39 PM, James Pettyjohn <japet...@gmail.com
> > wrote:
> > I just updated my depe
t).
> >
> > Example:
> > https://play.golang.org/p/wqb9lVIPLa
> > (repeat several times and change the random seed to randomize the
> > behavior a bit)
> >
> > Of course, optimizing the data structure doesn't hurt. And to answer
> > your question, ye
I have an application which has all of it's text, multiple languages,
stored in XML on disk that is merged into templates on the fly. About
100MB. Templates use dozens of strings for each render.
Currently this is loaded in full into memory in a bunch of tier hash maps.
They are lazy loaded
Hi Vlad,
I am using go install and the pkg directory is being mapped into the
container.
docker run -ti --rm \
-v "$PWD":/usr/src/pjt \ # Mount the entire project to this directory
-w /usr/src/pjt \ # use the project dir as the cwd
-e "GOPATH=/usr/src/pjt" \ # set the GOPATH the base of the
Hey Vlad,
Here's the docker command:
docker run -ti --rm \
-v "$PWD":/usr/src/pjt \
-w /usr/src/pjt \
-e "GOPATH=/usr/src/pjt" -e "STATICBUILD=1" \
-e "PREBUILD_DEPS=$PREBUILD_DEPS" \
gobuilder:1.8-alpine \
./build.sh
Regarding my docker:
docker-machine version 0.10.0, build 76ed2a6
I have a statically built go binary with cgo deps (wellington/go-libsass)
which I'm trying to speed up the rebuild time for.
This is run within a docker image because so the statically compiled binary
will run as it's own base image on docker.
The docker image the build is run within is:
FROM
yet know you want :-)
>
> On Monday, June 5, 2017 at 3:28:33 AM UTC-7, James Pettyjohn wrote:
>>
>> I'm loading a set of structs in memory and will be frequently using them
>> throughout the lifetime of the application and doing frequent 'queries'
>> against the set to ge
I'm looking at using the stock HTTP reverse proxy, briefly looking at the
implementation it seems to be ready to withstand a production workload.
Any cautions or caveats in going this route?
- J
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
I tried this once and I don't know that I effectively decoupled the direct
cgo dependency. Any pointers on effectively doing this?
On Saturday, March 11, 2017 at 11:22:03 PM UTC-8, Tamás Gulácsi wrote:
>
> Factor out the cgo related part into a wrapper package (subdir), that will
> help with
M
>
>
> On Saturday, March 11, 2017 at 9:00:43 PM UTC-8, James Pettyjohn wrote:
>>
>> I'm looking at the pros and cons of how to architect a web project.
>>
>> 1) One is a single go project for a site. No service dependencies for the
>> backend at all. Cer
I'm looking at the pros and cons of how to architect a web project.
1) One is a single go project for a site. No service dependencies for the
backend at all. Certain aspects of this means a cgo dependency which is not
ideal as it complicates containerization and slows build time. One plus to
I switched to go 1.8 today and found that some of my XML parsing was
failing where it was passing in 1.6/1.7.
After a bit of searching I found that there was a bug that was *fixed* in
1.8 and my faulty data was previously being ignored. Specifically empty
attributes which mapped to non-nilable
this is not an option at this time.
Best,
James
On Saturday, December 24, 2016 at 5:36:48 PM UTC-8, Justin Israel wrote:
>
>
>
> On Sun, Dec 25, 2016 at 9:22 AM James Pettyjohn <japet...@gmail.com
> > wrote:
>
>> I've been looking at a number of articles on statically linking
I've been looking at a number of articles on statically linking go files by
disabling CGO, sounds great except I've got a libsass dependency until the
native libsass is ready.
Can this be in a straightforward manner with go 1.6/1.7 on linux (centos)?
--
You received this message because you
No, it's some hundreds of strings across that whole package, none longer
than 100 characters. No giant static XML strings or the like.
Thinking it might be telling to see dependency information I ran into
(your) articles on golang dependency tools
I tried using 1.7rc6, no issues in compilation but finishes only about half
a second under 1.6.2.
On Thursday, August 11, 2016 at 8:19:12 PM UTC-7, James Pettyjohn wrote:
>
> I noticed that in the release notes, I'll try out the RC and see what it
> gives me.
>
> On Thursday,
Maybe I wasn't clear, I am not sure what else to look at in this scenario.
Whatever details you have in mind, i.e. which ones are relevant, is what
I'm missing.
On Thursday, August 11, 2016 at 8:16:38 PM UTC-7, Dave Cheney wrote:
>
> Can you please post some details.
--
You received this
I noticed that in the release notes, I'll try out the RC and see what it
gives me.
On Thursday, August 11, 2016 at 8:09:55 PM UTC-7, Michael Hudson-Doyle
wrote:
>
> On 12 August 2016 at 15:01, James Pettyjohn <japet...@gmail.com
> > wrote:
> > I have a project which has b
I have a project which has become fairly large, I simple check of *.go, no
_test files (including all modules), it's up to 1300 files.
The main module though is 60 files, about 1MB of go source. It is taking to
about 20 seconds to compile for a single change in the main module using go
1.6.2
30 matches
Mail list logo
