That's not bad and good to know.
Thanks for sharing !
Fundamentally I want to include the tests in the main though executable and
then run testing.T myself in the normal main
(Through a CLI command)
I'm willing to accept it can't be done because ts not idiomatic but thought
I'd inquire.
On Tue,
You can ask go test to leave the test executable for you to use later.
This is done with the -c flag. It will leave a -test binary
that takes all the flags that go test takes. This is at least similar
to what you are asking for.
On Tue, 2019-07-09 at 18:35 -0700, farid.m.zaka...@gmail.com wrote:
>
That proposal is materially different, due to using handler functions, rather
than the already existing scoped labels, both in terms of cognitive load -
where is the function called - what does the stack look like?What about
panics?, and in terms of lines of code (functions are far more verbose)
See https://github.com/golang/go/issues/32500
On Tuesday, July 9, 2019 at 10:25:36 AM UTC-7, Robert Engels wrote:
>
>
> There is probably a similar proposal out-there, but if there is it hasn't
> surfaced, so I thought I would throw this out there.
>
> It only requires 2 simple changes and is co
Thank you for your answer, this makes sense.
在 2019年7月9日星期二 UTC+8下午9:15:52，Than McIntosh写道：
>
> Hi,
>
> This is a good question, and I think it points out that the name of this
> command line flag ("-enable-gc") is not ideal. It should really be
> something more like "-enable-precise-stack-scan=
We've written some diagnostic tests that we execute during the test phase
(go test) however I was wondering if there's an established
pattern for how to include tests in the final binary and execute them
afterwards.
The analogous version in Java would be that you could create a "test JAR"
which
My gollvm version is
commit 29005f52b3501c489cb1653506cd479d5a178e98 (HEAD -> master,
origin/master, origin/HEAD)
Author: Cherry Zhang <...>
Date: Sat Jun 29 00:25:46 2019 -0400
bridge: support builtin memset
Change-Id: I7321f57e0d58c0ff5c3a19f7cbf5721fabbf1263
Reviewed-on: htt
This is not necessarily true. A single call may return a variety of
errors. Otherwise a simple (ok bool) would be enough.
On Tue, 2019-07-09 at 15:49 +0200, Nicolas Grilly wrote:
> On Tue, Jul 9, 2019 at 3:36 PM Wojciech S. Czarnecki >
> wrote:
>
> > Because given piece of contemporary productio
color change, from aqua to teal, was jarring to me.
On Tue, Jul 9, 2019 at 2:14 PM mh cbon wrote:
> ... is awesome. so much better to read. much much more enjoyable.
>
>
> Thank you!
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To un
... is awesome. so much better to read. much much more enjoyable.
Thank you!
--
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...@googlegroup
The try/goto proposal is similar but I think slightly inferior for two reasons:1) the try(try(try())) nesting is still possible, and I don't think that is easy reading2) I don't see how the 'last error' to be used in the handler is defined, so how do you write the handler method ?Furthermore, the _
Hi Roman,
> For a project considering switching to Go modules, is that possible to
> reference a package without support of modules (doesn't have a
go.mod/go.sum files)?
Yes, as far I understand, that should usually work.
Using your example of wanting to consume a non-module dependency
anEnt
Hi Robert,
You might be interested in the discussion here:
https://swtch.com/try.html#goto
which include 3-4 comments discussing a similar (but not identical) idea
from @josharian and @griesemer.
Best,
thepudds
On Tuesday, July 9, 2019 at 1:25:36 PM UTC-4, Robert Engels wrote:
>
>
> There
>
>
> And not only that, it's complicated. The language spec is not the
> right place to dig into the complexities of how to use select safely
> while avoiding race conditions. There is just too much to say. And
> there are no docs for select other than the language spec.
>
>
Well here's th
On Tue, Jul 9, 2019 at 10:36 AM Daniel Eloff wrote:
>>
>>
>> In my opinion the best place for this kind of discussion is a blog
>> post or talk.
>
>
> I disagree strongly. If there's a mode of operation that's dangerous when I'm
> operating a car or machinery I want it to not just be called out i
>
>
> In my opinion the best place for this kind of discussion is a blog
> post or talk.
>
I disagree strongly. If there's a mode of operation that's dangerous when
I'm operating a car or machinery I want it to not just be called out in the
manual, but called attention to in a big bold font.
There is probably a similar proposal out-there, but if there is it hasn't
surfaced, so I thought I would throw this out there.
It only requires 2 simple changes and is completely backwards compatible.
Currently, idiomatic Go error handling code looks like this:
v,err := somefunc()
if err!=nil
On Tue, Jul 9, 2019 at 9:27 AM Dan Eloff wrote:
>
> So I guess the best thing to do in these cases is don't combine select with
> sending unmanaged resources over a channel. It's probably worth warning about
> this problem in the docs for select? It's not an obvious gotcha.
In my opinion the be
I couldn't use <-channel.Close since in my case the goroutine isn't
guaranteed to have something sent, so that would leak goroutines. I added a
cleanup goroutine to scan timed-out channels and close them, which solves
this problem. But now I can use that close as a signal to the receiver than
the a
On Tue, Jul 9, 2019 at 4:44 PM Space A. wrote:
> Did you ever read below the title
>
Yes, I did. I even read the full proposal, all the comments and related
issues in the issue tracker, and all the messages in this thread and other
threads on golang-nuts. This is why I wrote this message :-)
--
On Tue, Jul 9, 2019 at 9:02 AM daniel wilson
wrote:
>
> Hi,
>
> I have this pipeline in bson
>
> pipe := db.C(COLLECTION).Pipe([]bson.M{
> {"$match": bson.M{"nfType": "AMF"}},
> {"$unwind": bson.M{"$ipv4Addresses"}},
> {"$group": bson.M{
>"_id": bson.M{"$dista
Hi,
I have this pipeline in bson
pipe := db.C(COLLECTION).Pipe([]bson.M{
{"$match": bson.M{"nfType": "AMF"}},
{"$unwind": bson.M{"$ipv4Addresses"}},
{"$group": bson.M{
"_id": bson.M{"$distance"},
"ipv4Addresses": bson.M{"$addToSet": "$i
Did you ever read below the title, or just seen the heading and immediately
start this teachings of emotional posts in your emotional write-up? Some
ppl see more, e.g. they can see what is the destination after first step
made. It's not the fist time ever, when someone trying to "improve" the
langu
That stack trace looks a lot like
https://github.com/golang/go/issues/32778
which was fixed last week. What vintage is your gollvm?
Thanks, Than
On Tue, Jul 9, 2019 at 9:54 AM Yuan Ting wrote:
> In addition, I also failed to build etcd.
>
> $ git clone https://github.com/etcd-io/etcd.git
> $
In addition, I also failed to build etcd.
$ git clone https://github.com/etcd-io/etcd.git
$ cd etcd/ && ./build
go build: when using gccgo toolchain, please pass linker flags using
-gccgoflags, not -ldflags
# go.etcd.io/etcd/etcdserver/api/rafthttp
#0 0x55ecc4cfa34a llvm::sys::PrintStackTra
On Tue, Jul 9, 2019 at 3:36 PM Wojciech S. Czarnecki
wrote:
> Because given piece of contemporary production code may succeed in
> only ONE way, but it may FAIL in many ways.
If a piece of code may fail in many ways, then it will probably have
several if blocks, and try will not be used. I don'
On Tuesday, July 9, 2019 at 12:44:12 PM UTC+2, ohir wrote:
>
> Harsh reactions stem from what experienced programmers see as `unintended
> consequences`
>
Don't you think that the "experienced programmers" composing the Go team
are also able to foresee and assess the consequences of the try prop
On Tue, Jul 9, 2019 at 6:48 AM wrote:
>
>
>
> I can query my mongodb collection to get the ipv4Addresses based on the
> nfType and the minimum distance using the command line query
>
> db.nfinstancesdb.aggregate([
> {
> "$match": {
> "nfType": "AMF"
> }
> },
> {
> "$unwind
On Tue, 9 Jul 2019 15:19:22 +0200
Nicolas Grilly wrote:
> I agree that the "sad" path is as important as the "happy" path, but I
> wouldn't say it's more important to the point of dominating the number of
> lines in a function. In some functions, 2/3 or 3/4 of the lines are
> dedicated to error h
Thank you for your help. I didn't add any flags about modules when
compiling gollvm or compiling k8s.
On Tuesday, July 9, 2019 at 9:10:55 PM UTC+8, Than McIntosh wrote:
>
> Hi,
> I'll take a look later this morning; off the top of my head I'm not sure
> what the issue might be.
> Question: are
On Tue, Jul 9, 2019 at 2:00 PM Ian Davis wrote:
> It's quite a bit more than a just new function since it brings some new
> behaviours that we don't have for functions in Go at the moment:
>
> 1. like panic it interrupts its caller's control flow
>
> 2. It may only be used within functions/method
For a project considering switching to Go modules, is that possible to
reference a package without support of modules (doesn't have a
go.mod/go.sum files)?
module anEnterpriseCompany.com/aProject
require anEnterpriseCompany.com/anotherProject v0.0.0
go 1.12
"anEnterpriseCompany.com/anotherPro
On Tue, Jul 9, 2019 at 1:57 PM Jan Mercl <0xj...@gmail.com> wrote:
> It's not verbosity. It's error handling. And because error handling is
> usually not the happy path, it's good when it stands out clearly. That
> improves readability as the important part catches attention easier.
>
I agree tha
Hi,
This is a good question, and I think it points out that the name of this
command line flag ("-enable-gc") is not ideal. It should really be
something more like "-enable-precise-stack-scan=".
The garbage collector used by gollvm is substantially the same as the one
used by the main Go compiler
Hi,
I'll take a look later this morning; off the top of my head I'm not sure
what the issue might be.
Question: are you building with modules enabled?
Thanks ,Than
On Mon, Jul 8, 2019 at 11:05 PM Yuan Ting wrote:
> Hi, I'm working on converting some Go projects to llvm IR for static
> analysis.
The controversy between try and explicit error checking is why I wrote this
proposal, to provide a compromise that's both explicit and terse.
On Fri, Jul 5, 2019, 11:08 PM Liam Breck wrote:
> I've expanded the proposal to address feedback from the Go team. It now
> offers a more special purpose
I can query my mongodb collection to get the ipv4Addresses based on the
nfType and the minimum distance using the command line query
db.nfinstancesdb.aggregate([
{
"$match": {
"nfType": "AMF"
}
},
{
"$unwind": "$ipv4Addresses"
},
{
$group: {
"_id": "$dista
On Tue, Jul 9, 2019 at 2:03 PM Henrik Johansson wrote:
>
> Not sure if anyone has already mentioned the possibility that "try" could
> actually improve error handling
> by simply removing much of the tediousness. Both reading and writing all the
> error checks becomes a
> nail in my eyes even if
Hello Gophers,
I have updated my list of all Go interfaces for these releases:
http://sweetohm.net/article/go-interfaces.en.html
Enjoy!
Le mar. 9 juil. 2019 à 00:45, Alexander Rakoczy a écrit :
> Hello gophers,
>
> We have just released Go versions 1.12.7 and 1.11.12, minor point releases.
>
>
Hi Than, when I read the code, I found enable_gc_ is false by default, the
description of option "-enable-gc=" is "Enable stack map
generation". I guess gollvm should have implemented garbage collection. My
question are:
1, what kind of gc does gollvm currently implement, and what is the
diffe
Not sure if anyone has already mentioned the possibility that "try" could
actually improve error handling
by simply removing much of the tediousness. Both reading and writing all
the error checks becomes a
nail in my eyes even if realize that it is very important. What if "try"
could take some of t
On Tue, 9 Jul 2019, at 11:43 AM, Nicolas Grilly wrote:
>
>> So why complicate the language with a new keyword which has really no
>> purpose.
>
> As mentioned in the proposal, try is not a new keyword, it's just a new
> built-in function.
It's quite a bit more than a just new function since it
On Tue, Jul 9, 2019 at 1:48 PM Nicolas Grilly wrote:
> The goal of the try proposal is not to "save a few keystrokes". The goal is
> to reduce error handling verbosity when reading code.
It's not verbosity. It's error handling. And because error handling is
usually not the happy path, it's goo
On Thursday, July 4, 2019 at 5:14:40 PM UTC+2, Michael Ellis wrote:
>
> In my view, saving a few keystrokes is not the reason to support such a
> test. I've already got an editor snippet that generates a default "if err
> != nil ... " clause.
>
The goal of the try proposal is not to "save a few
On Tue, 9 Jul 2019 02:26:03 -0700 (PDT)
Nicolas Grilly wrote:
> try is just syntactic sugar for `if err != nil { return ..., err }` and
> nothing more.
Unfortunately it is NOT.
It (`try`) does magical things to the return parameters, ie. it elides
the last one but only if it is **not** in th
On Thursday, July 4, 2019 at 10:55:50 AM UTC+2, Slawomir Pryczek wrote:
>
> going to turn code into unreadable, fragmented mess
>
Do you really think that replacing:
f, err := os.Open("file.txt")
if err != nil {
return err
}
By:
f := try(os.Open("file.txt"))
Will "turn code into unreadable,
On Monday, July 1, 2019 at 8:46:29 AM UTC+2, Sanjay wrote:
>
> His actual proposal paper is also an interesting read:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf.
>
This is fascinating read about language design in general and error
handling in particular. Thanks for sh
On Saturday, July 6, 2019 at 12:22:33 AM UTC+2, Jakub Labath wrote:
>
> Some of us had to fix so much broken java/python code with invisible and
> anonymous goto statements (aka exceptions) that even just seeing the
> keyword try prompts a physical reaction.
>
"Just seeing the keyword try prompt
On Tue, Jul 9, 2019 at 11:05 AM sasikala tholisam
wrote:
>
> var timingDefinitionInt int
> timingDefinitionInt, err = strconv.Atoi("2")
> if err != nil {
> log.Fatalln("file format is incorrect!", err)
> }
>
> errors are just being logged using log.Fatalln(). Instead, j
var timingDefinitionInt int
timingDefinitionInt, err = strconv.Atoi("2")
if err != nil {
log.Fatalln("file format is incorrect!", err)
}
errors are just being logged using log.Fatalln(). Instead, just return the
error.
--
You received this message because you are s
50 matches
Mail list logo
