I recommend always using the command
go install -v
This does two things
go install will store compiled packages in $GOPATH/pkg for reuse by subsequent
compilation.
-v will print the name of every package as it is compiled. If the list is long
the first time you invoke the command, this is
If it's running on Linux the oom killer could be to blame. Ask them customer to
check dmesg
--
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
Can you show an example of your program and how you are capturing the profile.
The common mistake is to not close the profile before the program ends.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
Try setting GODEBUG=gctrace=1 (untested)
--
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 the sample program you provided is not the one which is causing the
panic. For example there is no mention of Kenisis provider in the sample code
you provided, but it is part of the stack trace you showed.
1. Can you reproduce the crash with the sample code you provided?
2. Can you
Have you built your program with the -race flag and confirmed there are no data
races in your program?
--
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
IMO it's simpler to start with all you code in a single package and only break
something out when you find three or more cases where the code could be reused.
Some other markers I use to guide breaking the code up into separate packages
are if you find you have written a significant amount of
I've always argued that a package's name is a one word elevator pitch for what
it provides--not what it contains.
Package models fails this tests because it enumerates the contents of the
package.
You could argue that this also provides the models for your project, but think
about what
I do feel like people might not be so careful and then
> dereferencing a nil *Foo will be a clearer symptom to debug, than debugging
> whatever weird value Open might theoretically return being used
> accidentally.
>
> On Sat, Apr 1, 2017 at 2:26 AM, Dave Cheney <da...@cheney.net
ary, because people shouldn't rely on the
> first return if there's an error anyway.
> Because I do feel like people might not be so careful and then
> dereferencing a nil *Foo will be a clearer symptom to debug, than debugging
> whatever weird value Open might theoretically return be
> On 1 Apr 2017, at 11:02, Axel Wagner <axel.wagner...@googlemail.com> wrote:
>
>
>
>> On Sat, Apr 1, 2017 at 1:50 AM, Dave Cheney <d...@cheney.net> wrote:
>>
>>
>>> On 1 Apr 2017, at 10:41, Axel Wagner <axel.wagner...@googlemail.com
ng to say that I'm training them to not adhere to the contract?
> Because I don't see how; it's blowing up either way, just, in one case the
> blowup might be easier to detect and debug.
>
> I respect your opinion and I do agree, but we just seem to be talking about
> diffe
I think the simpler contract is to give no guarantee whatsoever of the state of
the other return values in the presence of an error.
It's a simple, clear, and most importantly consistent contact.
To guarenteed that in the presence of an error the values that can be
respresented by nil _will_
My position is the caller cannot make any assertion about the state of the
other values returned until they have checked the error. If the error was non
nil then nothing can be said about the state of the other values returned.
--
You received this message because you are subscribed to the
What is the reason you want to recompile all the source code? The go tool
automatically recompiles anything that is out of date.
What is the problem you are trying to solve by using -a to force recompilation
of everything.
--
You received this message because you are subscribed to the Google
On Friday, 31 March 2017 16:58:15 UTC+11, KDr2 (ZHUO QL) wrote:
>
> My go workspace is simple:
>
>
> [000]kdr2@Debian-X230:~/gows$ pwd
> /home/kdr2/gows
> [000]kdr2@Debian-X230:~/gows$ tree
> .
> └── src
> └── test
> └── m.go
>
> 2 directories, 1 file
>
>
> And the content of m.go is
Arm means arm as in linux/arm.
--
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
0004346d2 in runtime.stopm ()
> #4 0x004375bc in runtime.exitsyscall0 ()
> #5 0x0045fb3b in runtime.mcall ()
> #6 0x00c82004c000 in ?? ()
> #7 0x in ?? ()
> Thread 1 (Thread 0x7f8ffa7c9700 (LWP 37229)):
> #0 0x00463563 in runtime.f
Or to answer your question another way; the more allocations your program
performs, the higher the GC overhead to clean them up.
Are you asking: is there a way to limit the % CPU the GC is allowed to use? If
so, the answer is no, because:
1. If the GC doesn't keep up with the garbage your
I'm not sure what you expected to see. That program does nothing but generate
garbage. It's going to have a high overhead to clean up that garbage.
Can you show some data from your real program?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
I suggest two things
1. Post the GODEBUG output here, someone will be able to confirm how much time
they GC is using.
2. Use github.com/pkg/profile to generate an execution trace and analyse it
with go tool trace.
--
You received this message because you are subscribed to the Google Groups
the concurent gc could occupy all cpu core ?? does
> it have cpu usgae limit ?
>
no
>
>
> 在 2017年3月27日星期一 UTC+8下午5:28:38，Dave Cheney写道：
>>
>> You can enable monitoring of the gc with this environment variable
>>
>> GODEBUG=gctrace=1
>&g
You can enable monitoring of the gc with this environment variable
GODEBUG=gctrace=1
The format of the output is described on this page.
https://golang.org/pkg/runtime/
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
I think it's a fine idea. For a decade C++ was actually compiled to C, via
cfront. It well past time that Go returns the favour.
This would also help flush out a lot of unspoken assumptions about what a Go
program requires from the underlying operating system.
--
You received this message
Well, that program isn't that simple because of the closure, but also
because it contains a data race
Something like this is easier to reason about
var x *int
func main() {
var a int
x =
fmt.Println(*x)
}
On Wednesday, 22 March 2017 21:59:17 UTC+11, T L wrote:
>
>
>
>
On Wednesday, 22 March 2017 20:51:18 UTC+11, T L wrote:
>
>
>
> On Wednesday, March 22, 2017 at 4:56:28 PM UTC+8, Dave Cheney wrote:
>>
>> The comment on
>>
>> https://github.com/golang/go/blob/master/src/runtime/mgc.go#L47
>>
>> //c. GC pe
716612 / 4092340 is ~ 17.5%
On Wednesday, 22 March 2017 20:49:25 UTC+11, tpoisonooo wrote:
>
> Thanks @Dave Cheney, I add 512MB `swap`, now Ubuntu would not kill Go
> application.
> But I still don't understand why `top` shows 17.5% memory usage.
>
--
You received this mess
:
>
>
>
> On Wednesday, March 22, 2017 at 4:33:21 PM UTC+8, Dave Cheney wrote:
>>
>>
>>
>> On Wednesday, 22 March 2017 19:29:02 UTC+11, T L wrote:
>>>
>>>
>>>
>>> On Wednesday, March 22, 2017 at 4:08:02 PM UTC+8, Dave Cheney wro
It looks like the vm you're running in has no swap configured. It's usually
a good idea to add a small amount of swap, even if it is never used, it
will make the linux vmm system less paranoid about running out of memory.
If that isn't an option you need to alter the overcommit options to let
On Wednesday, 22 March 2017 19:29:02 UTC+11, T L wrote:
>
>
>
> On Wednesday, March 22, 2017 at 4:08:02 PM UTC+8, Dave Cheney wrote:
>>
>>
>>
>> On Wednesday, 22 March 2017 19:04:36 UTC+11, T L wrote:
>>>
>>> In this article: https://bl
Top is not reporting the accurate memory usage of your application.
There are several ways to introspect your Go application to find its real
memory usage, but the easiest way is to set GODEBUG=gctrace=1 and wait for
lines that start with scvg: to be printed, they will tell you the current
On Wednesday, 22 March 2017 19:04:36 UTC+11, T L wrote:
>
> In this article: https://blog.golang.org/go15gc , it mentions
>
> ..., The GC visits all *roots*, which are objects directly accessible by
>> the application such as globals and things on the stack, and colors these
>> grey. ...
>
>
>
fmt is outputting an error because you passed it an integer type when you
asked it to format a boolean type. I think you wanted %T, not %t
https://play.golang.org/p/Uvws_k2peX
On Wednesday, 22 March 2017 12:23:04 UTC+11, WinD zz wrote:
>
>
> func main() {
> const abc = 111
>
I don't think cgo is to blame then, the only cgo used by the http package is
your system's DNS resolver.
--
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
What cgo calls were those? Are you using an alternative crypto implentation?
--
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
A few clarifications, b does not point to a. a and b are variables of type
[]int. The value of each slice's ptr fields point to a backing array of some
capacity.
If you append to a, this does not change th length or cap fields of b. If you
do this enough times that ptr field of a will be
Here is a short example I wrote for the Go 1.8 release party.
https://talks.godoc.org/github.com/davecheney/go-1.8-release-party/presentation.slide#36
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
go install -v
--
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
Point of order, my talk was called "SOLID Go Design", and talks about the
SOLID design _principles_, not patterns. This is important.
On Saturday, 4 March 2017 02:15:33 UTC+11, JM wrote:
>
> Dave Cheney Solid Design Patterns in Go
> https://www.youtube.com/watch?v=0IaBAl7
The oscar for worst autocorrect in a technical debate goes too ...
On Thursday, 2 March 2017 21:04:16 UTC+11, Michael Jones wrote:
>
> Go deserves a keyword to "make love objects."
>
> On Thu, Mar 2, 2017 at 9:47 AM Dave Cheney <da...@cheney.net >
> wrote:
>
&
Yup. A syscall causes the scheduler to create a new thread that replaces the
one blocking on the syscall.
--
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
Your spinning goroutine is block the garbage collector which needs to stop,
temporarily, all the running goroutines to make love objects.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
No, that's is not thread safe. The race detector will spot that.
--
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
On Sunday, 26 February 2017 16:54:25 UTC+11, Oleg Puchinin wrote:
>
> Hello !
> What is wrong and how to do it ?
>
What did you expect to happen? What happened instead?
>
> func handleconnection(tcp net.Conn) {
> cmd := exec.Command("/bin/bash")
> cmd.Stdin = tcp
> cmd.Stdout =
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
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
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()
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
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
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
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
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
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
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:
>
>
^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
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
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
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
> 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
> 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'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
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
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
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
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.
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
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
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
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().
>
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,
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
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
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
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
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
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
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 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
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
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
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
The former.
--
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
Second dumb question, if your messages are 100 bytes long, why not use UDP?
--
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
Dumb question, what about your design prevents you from pooling and reusing
connected sockets?
--
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
This is a somewhat known issue. Each token in a parsered .go file is
represented by a Node structure inside the program. The Node structure is
large, especially on 64 bit systems.
Normally this is not a problem, but in th e case where code has large tables of
data memory usage when compiling
I published a series of blog posts comparing compile times over various
releases of Go. The source of the benchmarks, the packages I compiled and
timed, are online and linked
from https://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvements. The
jujud tests compile some 512 packages of
What you are talking about is called a torn write, which can occur if a value
is written to memory but not aligned properly as the processor or memory
subsystem must convert this write into two to correct for the miss alignment.
Most processors that I know of, and all the ones that Go
Can you paste the *complete* crash output, the entire list of goroutines, from
the crash? It should be straight forward to explain what has gone wrong.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
tion with the complexity of the program.
>> 在 2017年1月4日，下午2:52，Dave Cheney <d...@cheney.net> 写道：
>>
>> Can you provide a runnable sample which shows the problem?
>>
>> How are you determining you are leaking memory? Can you please provide a
>> sample of your
and at the end of the day, the difference per access is 1ns, 3-4
instructions on a modern Intel processor.
On Friday, 6 January 2017 11:21:32 UTC+11, Keith Randall wrote:
>
> You're not really testing what you think you are testing.
>
> When you do "_ = load something", the compiler just throws
go run cmd/main.go -- tests/a/in.go
But you've probably reached the practical limit of what go run should be
used for. I recommend using the expected GOPATH package layout, go
build/install, etc.
On Thursday, 5 January 2017 16:02:50 UTC+11, bsr wrote:
>
> Following works.
>
> go run
https://play.golang.org/p/dwYZTQ4qDs
On Thursday, 5 January 2017 12:28:48 UTC+11, Alihan Kayhan wrote:
>
> Hello
>
> I want to find empty line on file
> e.g.
> Favorman.txt contains
>
> First Line: Hello
> Second Line: // Empty Line
> Third Line : Everybody
> Fourth Line : // Empty Line
> Fifth
Can you provide a runnable sample which shows the problem?
How are you determining you are leaking memory? Can you please provide a sample
of your application leaking memory with GODEBUG=gctrace=1 set.
Note, you need to close (or stop, I cannot remember the exact syntax) a profile
to release
301 - 400 of 647 matches
Mail list logo
