Have you adjusted th number of file descriptors available to your program, and
the server you are connecting to?
Have you used another program to verify that your target can handle the number
of connections you are making?
--
You received this message because you are subscribed to the Google
go test -work should do it.
On Saturday, 18 June 2016 12:02:03 UTC+10, Hiroaki Nakamura wrote:
>
> Hi,
>
> Here are commands I used to set up gopkg.in/vmihailenco/msgpack.v2
>
> go get -u gopkg.in/vmihailenco/msgpack.v2
> cd $GOPATH/src/gopkg.in/vmihailenco/msgpack.v2
> go get -u
Without seeing the code (hint, hint) I'm guessing that your benchmark got
optimised away.
Here are some links with suggestions on how to make your benchmark reliable.
http://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go#compiler-optimisation
Nope, vendoring remains unsuitable for library authors.
On Sunday, 19 June 2016 15:14:57 UTC+10, Tyler Compton wrote:
>
> A user brought up a problem with the current vendoring setup regarding
> exposing types of a vendored dependency. There was a lot of great
> discussion and it seemed like
If you mean forking their dependencies and rewiring their import paths, that is
a possibility. But it leaves consumers of those packages in the same position
as the thread the OP referenced because the same code is now known by two
distinct import paths breaking type equality.
--
You
Permitting symlinks inside GOPATH would introduce all the problems of one
source package having multiple locations that currently plague users of the
vendor/ feature.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
To serialise the keys and values of a map and code would have to iterate
over it
for k,v := range m {
// serialise k and v
}
But map iteration does not have a guaranteed ordering. This is why the
result is not stable.
On Tuesday, 21 June 2016 15:44:05 UTC+10, Harry wrote:
>
> Hello guys,
Your application has probably run out of file descriptors.
On linux you can get a sense of the number of active file descriptors your
program is using by looking in the /proc/$PID/fd directory. Where $PID is
the process id of your program.
/proc/$PID/limits will tell you the current limits
What are the exact commands you used?
It is easy to misuse proof, here is a slide with some of the gotchas.
http://talks.godoc.org/github.com/davecheney/presentations/writing-high-performance-go.slide#11
--
You received this message because you are subscribed to the Google Groups
io.Copy doesn't know anything about files, it works with any type that
implements io.Reader and io.Writer.
--
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
Hello,
You're pretty late to the discussion. Here's some background reading.
https://getgb.io/rationale/
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
Yes, exactly.
--
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
f behaviour for go get when a vendor
> directory is detected and solve some of the issues related to type equality
> (by having a single pkg path for a vendored package) ?
>
>
>
> On Friday, July 29, 2016 at 12:14:02 AM UTC+2, Dave Cheney wrote:
>>
>> Yes, exactly.
How many case blocks are you considering? There is some setup cost that is
linear with the number of selectable channels, but as a select stmt usually
blocks the setup cost is not usually considered the limiting factor.
--
You received this message because you are subscribed to the Google
How about a tag? which developers should be doing as part of any mature release
process.
--
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
If saving one byte per entry is important for your application, the latter is
your choice. The former has nicer properties that you can use the single value
form of map access,
if m[key] {
// found
}
I'd say the former is the right choice for 97.25% of general use cases.
--
You received
That documention is incorrect. The language spec assigns no meaning to the
import path.
The complier assigns the meaning that a compiled package must exists in a
subdirectory with a name that matches the import part, plus .a, in a path
provided by the -I flag.
The go tool goes further to
*s++ is a statement, not an expression. You cannot write
x := *s++
so you also cannot write
return *s++
On Saturday, 30 July 2016 12:32:03 UTC+10, CH S Phani wrote:
>
> Hello All,
>
> The below statement does not compile in Go language. The compilation error
> is "syntax error: unexpected ++
Can you please post some details.
--
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
Because we cannot change symbols covered by the Go 1 contract.
On Thursday, 4 August 2016 14:20:18 UTC+10, T L wrote:
>
> http://dave.cheney.net/2016/04/07/constant-errors
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from
I think it would be cheaper to call time.Sleep than spinning on runtime.Gosched.
--
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
I believe rsc once quipped "If it doesn't have to be correct, I can make [this
code] very fast".
I don't think you can make performance comparisons between two pieces of code
if one is incorrect.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
If you're going to sleep, does it matter if time.Sleep has a cost?
--
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
You mentioned timing your build with -x, can you please provide those details.
--
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
Please file a bug.
--
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
The autogenerated miranda method only happens if you are calling through an
interface method that is provided by an embedded type. If you're doing
something like
func log(...) {
pc := runtime.Callers(1) // get the caller of log
}
It shouldn't be a problem.
On Monday, 15 August 2016
out
> -L $WORK -L /Users/jp/git/project/pkg/darwin_amd64 -extld=clang
> -buildmode=exe -buildid=66dc2ac41b6b8158286be8a6b59f302b6ff26b19 -X
> main.CacheId=8d815e7 $WORK/site_www2.a
> mkdir -p /Users/jp/git/project/bin/
> mv $WORK/site_www2/_obj/exe/a.out /Users/jp/git/projec
Receiving from a closed channel immediately returns the channel types zero
value.
--
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
Keep an eye on the ℅ steal column in vmstat to make sure you're getting all the
CPU you are paying for.
--
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
-gcflags are passed to go tool compile, -ldflags are passed to go tool link.
--
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
Why not put non go code in another directory tree? That seems much simpler.
--
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
If you want to make a connection to a server take speaks TLS, you can
use https://godoc.org/crypto/tls#Dial
If you want to make a connection to a web server that uses HTTPS, the
net/http package does this automatically for you.
If you can share some more details about what you are trying to
Why do you want to avoid a mutex?
--
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
Lol, Doug Cheney.
--
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
A better solution would be to compose a new Writer wrapping the existing one
with a mutex.
--
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
1.7 will be released in August. You can try Go 1.7 today in beta form and I
just say the first release candidate has been tagged and will be out in the
next 24 hours.
On Friday, 8 July 2016 13:30:00 UTC+10, jonathan...@gmail.com wrote:
>
> Anyone have an idea when 1.7 will be out?
>
> On
You could simplify your program by removing the go statement. There is no
concurrency if one goroutine hands one piece work off to another then sleeps
for the result; it's simpler to just do the work yourself.
--
You received this message because you are subscribed to the Google Groups
Please check your errors.
On Saturday, 6 August 2016 08:38:54 UTC+10, Jon Strauss wrote:
>
> Hello,
> I have the following code:
>
> package main
>
> import "fmt"
> import "encoding/hex"
> import "os"
>
> func main() {
>var bytes []byte
>var channel chan []byte
>
>file,_
Add your change to this file
https://github.com/golang/go/blob/master/api/except.txt
On Saturday, 6 August 2016 02:37:33 UTC+10, stable.p...@gmail.com wrote:
>
> Hello,
>
> I have made some changes to a part of the go standard library. I am
> testing these to see if they help me do what I need
Your program exits because the channel is buffered, so the main goroutine
exits immediately once it has sent the value to the channel. Once the main
goroutine returns, the program will exit.
On Saturday, 6 August 2016 08:38:54 UTC+10, Jon Strauss wrote:
>
> Hello,
> I have the following code:
>
Hello,
I wish to nominate myself to be part of the working group. I have written
up my position statement here:
https://gist.github.com/davecheney/48c07d20f8cf38cce61c940d7bd55644
I am seeking a second for my nomination.
Thank you
Dave
On Friday, 29 July 2016 17:46:01 UTC+10, Peter Bourgon
Because an interface is a run time data structure, it cannot contain
constants because they don't exist at run time.
On Saturday, 6 August 2016 19:14:26 UTC+10, T L wrote:
>
>
>
> On Saturday, August 6, 2016 at 3:58:52 PM UTC+8, Dave Cheney wrote:
>>
>> It is not possib
It is not possible. Constants only exist at compile time.
--
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
Interfaces don't describe data, they describe behaviour. If you don't want
the behaviour to be changeable, use a concrete type.
On Saturday, 6 August 2016 19:30:22 UTC+10, T L wrote:
>
>
>
> On Saturday, August 6, 2016 at 5:19:08 PM UTC+8, Dave Cheney wrote:
>>
>> Becau
This is not a Go 1.7 regression, so not a blocker on the 1.7 final release
next week.
On Tuesday, 9 August 2016 18:45:02 UTC+10, ksug wrote:
>
> Thanks Dave. Could you clarify what you mean by "This is not a 1.7
> blocker"?
>
--
You received this message because you are subscribed to the
Looks like a bug in godoc.org (and maybe godoc). This is not a 1.7 blocker,
in code the constant is untyped.
On Tuesday, 9 August 2016 16:41:19 UTC+10, ksug wrote:
>
> Hi all,
>
> Package github.com/hashicorp/raft contains the following block of code:
>
>
> =
> const (
>
You cannot, the address of sa escapes to the heap because it is returned to
the caller. The solution may be to refactor the method to take a
*syscall.SockaddrInet4 that was allocated in the caller, but that is not
something that can be done as a consumer of the net package.
On Tuesday, 2
TL;DR a shallow copy is easy, but it's almost never what you want.
https://play.golang.org/p/wpWN3Znop8
Needing to copy an arbitrary value is usually an anti pattern as values can
contain references to other values, which contain references to other
values, which contain references to other
You need to use the values to ensure that compiler does not remove the code.
Even if the compiler does not do this, your Intel CPU will, if effectively runs
an ssa implementation in hardware and will spot the dead stores and skip the
load.
--
You received this message because you are
Those arguments must live beyond the scope of the enclosing function.
--
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.
The hash is always the same because you ask for the hash value before writing
any data through it with io.Copy.
--
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
to the end user of the vendoring pkg.
>
I think any solution that meant code behaved differently depending on where
it was on disk during compilation should be looked at with deep suspicion.
>
> On Sunday, June 19, 2016 at 10:52:34 PM UTC+2, Dave Cheney wrote:
>>
>> If
Where does the 301 point?
--
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
Stripping go binaries is not tested and known to produce broken binaries. I
recommend not doing this until strip/upx/whatever are tested as part of the
unit tests which are run before each commit lands.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
Until it's part of the ./all.bash test suite, it'll continue to break because
it has never been proven to work.
> On 17 Aug 2016, at 05:13, Michael Hudson-Doyle <michael.hud...@canonical.com>
> wrote:
>
>> On 17 August 2016 at 08:31, Dave Cheney <d...@cheney.net
Superb advice, seconded.
--
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
I think both are symptomatic of following a Javaesq style of one type per file.
--
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
If you read the git history of the installation page you'll see we've
pushed the GOROOT instruction lower and lower in the page. However the
advice to set GOROOT has permeated to the Go zeitgeist and continues to be
promulgated in tutorials and blog posts.
On Saturday, 4 February 2017 00:26:46
CYuvbGA
>
> GCtrace:
> http://pastebin.com/M7VpehUE
>
> Please find the attached heap profile svg as well.
>
> The process RSS ~ 36G
>
> --
> Thanks,
> Sarath
>
> On Thursday, February 2, 2017 at 1:36:25 AM UTC+5:30, Dave Cheney wrote:
>>
>> Can you please
0.44ns/op is about 2.2.ghz, the compiler has optimised away your
microbenchmark.
--
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
Yes
--
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.
> Since there is nothing that changes in the processes over time, the fact
that it kicks in after a few minutes makes me think it may be a garbage
collection issue.
Running with GODEBUG=gctrace=1 will confirm / deny this hypothesis.
On Tuesday, 7 February 2017 16:06:09 UTC+11, Jason E. Aten
I think there are more data races in your product
http://paste.ubuntu.com/23946008/
On Tuesday, 7 February 2017 16:42:28 UTC+11, Jason E. Aten wrote:
>
> the race is fixed in the latest push;
> a572f570c52f70c9518bc1b3e3319ff9e2424885; it was an artifact of adding
> logging levels, and would
None whatsoever I'm afraid
On Tuesday, 7 February 2017 16:53:45 UTC+11, Jason E. Aten wrote:
>
>
> On Monday, February 6, 2017 at 11:49:42 PM UTC-6, Dave Cheney wrote:
>
>> The give away is the frequency of the gc lines. gc 15 (the 15th gc event)
>> happened at 1314 se
> did manage to catch the processing running away again, this time at
300%, and I got some output with gctrace=1 as you suggested. I'm not sure
how to read the lines though; could you advise Dave?
The give away is the frequency of the gc lines. gc 15 (the 15th gc event)
happened at 1314
I'd say store that context in your transaction value, not the other way around.
--
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
On Sunday, 5 February 2017 15:39:55 UTC+11, so.q...@gmail.com wrote:
> I generally favor "external test packages", that is having "_test" as a
> suffix to my test package names.
> For example, "package foo" (foo.go) would have a test file (foo_test.go)
> named "package foo_test"
>
>
> I do so
I guess it depends on how long your transaction lasts for; it doesn't sound
like it lives for that long. IMO the advice about storing contexts in other
objects is more about "don't put this into a long lived object", like your
server's main loop or something.
On Wednesday, 8 February 2017
^C will exit the program before the defer in your main can run.
I recommend using my profiling package, github.com/pkg/profile
https://dave.cheney.net/2014/10/22/simple-profiling-package-moved-updated
On Wednesday, 8 February 2017 08:55:33 UTC+11, Jason E. Aten wrote:
>
> How does one reliably
net/http/pprof is your best option
If you can't make that fly, then you can use my profile package; just keep
a reference to the value returned from profile.Start() and call its Stop
method to write out the profile
On Wednesday, 8 February 2017 09:03:30 UTC+11, Jason E. Aten wrote:
>
>
You mentioned that this was reproducible with 1.7.x. it might be worth sticking
to that version to avoid having to concurrently debug this external code issue.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and
If your code has a dependency on github.com/pkg/log then place the contents of
that repository into
$PROJECT/vendor/src/github.com/pkg/log
Where $PROJECT is the root of your gb project.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
. Since I will be using the packages to build an app, I need to
> make sure the builds are reproducible. ☺
>
> I had a very helpful email exchange with Dave Cheney, and he suggested gb
> + semver. With the current lack of convergence on go package
> versioning/dependency manage
Can you please run your program with GODEBUG=1 and paste the output.
btw, which version of Go and which OS?
On Thursday, 2 February 2017 02:26:45 UTC+11, Sarath Lakshman wrote:
>
> I have tried waiting long enough for the process to release memory back to
> OS as well as debug.FreeOSMemory().
>
Start with the basics like go vet which will spot a lock being copied by value.
Then check for each place you call Lock, there is a defer statement on th next
line.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group
On Sunday, 29 January 2017 01:42:08 UTC+11, T L wrote:
>
>
>
> On Saturday, January 28, 2017 at 10:33:08 PM UTC+8, Dave Cheney wrote:
>>
>>
>>
>> On Sunday, 29 January 2017 01:25:20 UTC+11, T L wrote:
>>>
>>>
>>>
>>
On Sunday, 29 January 2017 01:25:20 UTC+11, T L wrote:
>
>
>
> On Saturday, January 28, 2017 at 9:33:51 PM UTC+8, C Banning wrote:
>>
>> From the doc: "The finalizer for obj is scheduled to run at some
>> arbitrary time after obj becomes unreachable. There is no guarantee that
>> finalizers
If you find a piece of code that uses a finaliser for the correct operation of
that program, that code is broken.
--
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
Do you have GOROOT set? This error can occur when GOROOT is set incorrectly.
On Sunday, 29 January 2017 03:06:18 UTC+11, gocss wrote:
>
> building in xubuntu 16.04 LTS
>
> # API check
> stat /csspc/etc/go/src/cmd/api/run.go: no such file or directory
> 2017/01/28 10:51:46 Failed: exit status
I think you're talking about a different example to TL.
--
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
It was just a turn of phrase, it's not a real rule.
--
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,
I see it that the g(f()) special case is just that,a special case, added to
make common use case less tedious. It's not an invitation to extend its rubbery
semantics to all classes of function call.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
I think you misunderstand. The exception is this form
func f() (int, boo)
func g1(int, bool)
g1(f())
Not this form
func g2(int, int, bool)
g2(1, f())
The exception is the former form which is a special case for convenience.
This special case creates confusion when people try the second
Pro tip: optimise for correctness before performance.
--
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
The confusion comes, like most cases in go, where a little syntactic sugar has
been added to make the common case more appealing, but has the side effect of
making the less common case more jarring.
g1(f())
Is th exception to the rule. By _not_ requiring the caller to capture each
value
You must not set GOROOT when building from source. It is not necessary and will
lead to confusing error messages if you at GOROOT
--
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,
Can you share some more details
1. which version of Go
2. which operating system
3. where are you sending from / to, is it over localhost, does the other
side care about acknowledging receipt
4. can you show your code
5. have you profiled your code? What resource is limiting the throughput of
Can you share that code, it looks like you haven't checked the error from the
previous call.
--
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
Within the testing package you choice is t.Skip and some set of package level
variables.
Maybe the more involved testing frameworks like convoy or gocheck offer more
final version of t.Fatal.
However, from the situation you've presented it feels to me that your solving
the wrong problem. If
It looks like one test in the os/exec package failed during the tests which
are run during ./all.bash
--- FAIL: TestStdinCloseRace (0.04s)
exec_test.go:267: Kill: os: process already finished
FAIL
FAILos/exec 0.371s
At this point Go is fully built, so you may wish to ignore this
Those instructions are wrong, I've written to the author and asked them to
remove the incorrect information.
Please follow the installation instructions on the golang.org website, they
are well tested and known to work well. https://golang.org/doc/install
On Tuesday, 14 February 2017 09:07:54
It's neither, its undefined.
--
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
I consider the testing package ideal for unit tests, acceptable for functional
tests and out of its depth for integration testing. You can do it, but you end
up writing a lot of scaffolding, see the cmd/go tests.
--
You received this message because you are subscribed to the Google Groups
I raised https://github.com/golang/go/issues/19050 to track 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
There is an active discussion thread over on the development list ->
https://groups.google.com/forum/#!topic/golang-dev/F3l9Iz1JX4g
--
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
Or use https://godoc.org/io/ioutil#ReadFile
By really you don't need to buffer all the data in memory, io.Copy will do
that for you
in, err := os.Open(input)
check(err)
defer in.Close()
out, err := os.Create(output)
gz := gzip.New.Writer(out)
_, err = io.Copy(gz, in)
check(err)
err = gz.Close()
It looks like you've install gccgo, not go (sometimes called golang-go by
operating system vendors).
If you uninstall gccgo and install Go from the
website, https://golang.org/dl/, it should work fine.
On Thursday, 19 January 2017 22:03:10 UTC+11, Alessandro Re wrote:
>
> Hello,
> few months
The problem is expanding shell meta characters like *, ? and ~ is a
property of the _shell_, as Dan mentioned above. You are executing a
command directly so the shell is not involved and cannot expand *.json into
a list of files ending with .json.
A cheap solution to this might be something
While I appreciate you writing this in Go, wouldn't this scripting be better
done in shell?
What's likely happening is the SSH server on your device only supports older
insecure algorithms, which ironically are more common amongst security hardware.
--
You received this message because you
That looks like the case.
Do you include a large amount of static data in the site_www2 package?
--
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
1 - 100 of 647 matches
Mail list logo
