go Away()


  • Impossible Mission - B

    Ugh. I just discovered that in Go, "variable is declared but never used" is a compile-time error. Not a warning like it should be, like it is in more sane languages; an error. Which makes incremental development that much more difficult; if you want to evaluate something to a variable, look at its value in the debugger, and then write some more based on what you find, you need to find some way to work around that.

    @ben_lubar or anyone else who works in Go, is there any way to disable that ridiculous error and tell it to go Away()???



  • @masonwheeler Can't you just do a var_dump (or whatever is the equivalent in Go) on it ?
    Would make you see what it contains and make the "never used" error go away at the same time.


  • Banned

    @masonwheeler at my last workplace, we've had -Werror enabled. When faced with the same problem, we just cast the variable to void. I bet there's some similar no-op thingy in Go.



  • @masonwheeler

    var notSureImGonnaUse;
    notSureImGonnaUse = notSureImGonnaUse;
    

    Will that get rid of the warning? You could put it on one line, and it's harmless if you forget to remove the equals because you're just setting it to itself.



  • If you don't want to use a variable, do this:

    _ = variableName
    


  • @blakeyrat said in go Away():

    @masonwheeler

    var notSureImGonnaUse;
    notSureImGonnaUse = notSureImGonnaUse;
    

    Will that get rid of the warning? You could put it on one line, and it's harmless if you forget to remove the equals because you're just setting it to itself.

    You can do that, but it's recommended that you use _ as the destination for "I don't care about this value" assignments, since x = x looks like a bug in your code.



  • @ben_lubar Ah, I see @masonwheeler's snare has attracted both an M. blakei and a B. conlang (and, I suppose, a G. lambda as well). Good work.



  • @masonwheeler said in go Away():

    Not a warning like it should be

    By the way, they have this in the FAQ: https://golang.org/doc/faq#unused_variables_and_imports



  • @masonwheeler said in go Away():

    is a compile-time error. Not a warning like it should be

    -Werror is always mandatory, so I don't see how this distinction matters.



  • @kian said in go Away():

    @masonwheeler said in go Away():

    is a compile-time error. Not a warning like it should be

    -Werror is always mandatory, so I don't see how this distinction matters.

    -Werror is mandatory for my own code, but not for code written by other people that I just want to goddamn compile goddamnit.


  • Java Dev

    @kian said in go Away():

    -Werror is always mandatory, so I don't see how this distinction matters.

    Not during local hacking about it isn't.



  • And this is one of the reasons why I intend to tie the Thelema compiler code generation and warning/error messages to the staging status of the VCS branch being compiled.

    For example, when compiling code that is set to 'development' or 'development-experimental', it would do only the minimum error checking, and generate code in a way that focuses on a fast compile and easy debugging. By default, it would add more tests, and more complex and time-consuming analyses, as the particular update proceeds through to Unit Testing, Integration Testing, Effectiveness Testing (alpha testing), Acceptance Testing (beta testing), Release Candidate, and finally Release.

    It would also be set up to allow specific configuration checklists for each stage, though no stage would be permitted to have less stringent error reporting than the previous stage.

    I suspect it won't work as well as I would like, but AFAICT no one has done it before so it is probably something worth trying out.

    Of course, all of this is predicated on me actually developing the Thelema compiler, something that is, not to put too fine a point on it, probably never going to happen.


  • area_can

    @ben_lubar seems like a pain in the ass to do that for every variable and then undo it when you're done testing whatever change you're working on


  • Impossible Mission - B

    @ben_lubar said in go Away():

    @masonwheeler said in go Away():

    Not a warning like it should be

    By the way, they have this in the FAQ: https://golang.org/doc/faq#unused_variables_and_imports

    Wow. There is so much fail in that FAQ entry it's not even funny. :(


  • Discourse touched me in a no-no place

    @scholrlea said in go Away():

    Release Candidate, and finally Release

    You really want these to be the same, build-options-wise. Probably also for Acceptance Testing too. Otherwise the differences in compilation configuration can cause changes that are problems in themselves.



  • @dkf OK, that's actually a very good point. Thank you.


  • 🚽 Regular

    @ben_lubar said in go Away():

    If you don't want to use a variable, do this:

    _ = variableName
    

    (I just googled "go implement an interface", which in retrospect sounds like I'm sending them off somewhere)

    https://play.golang.org/p/zyluP2qBqD , namely:

    package main
    
    import (
    	"fmt"
    )
    
    type Intheface interface {
    	TestIt(arg1 string, arg2 string) string
    }
    
    type Test1 struct {
    }
    
    func (self Test1 ) TestIt(args_dont_need_to_have_the_same_name_as_in_the_interface_thats_a_relief string, arg4 string) string {
    	return "Test1 passed"
    }
    
    type Test2 struct {
    }
    
    func (this Test2) TestIt(_ string, _ string) string {
    	return "Test2 passed"
    }
    
    func main() {
    	tests := []Intheface{Test1 {}, Test2{}}
    	for _, test:= range tests{
    		fmt.Println(test.TestIt("val1", "val2"))
    	}
    }
    

    (8-char wide tabs, seriously?)

    Prints:

    Test1 passed
    Test2 passed
    

    It doesn't complain about unused function arguments. Hypocrite.

    On a secondary note, it accepts _ as the name of more than one argument, which is what I set out to test originally.



  • @zecc why WORD are WORD you WORD repeating WORD the WORD same WORD type WORD after WORD each WORD argument WORD?


  • Impossible Mission - B

    @ben_lubar Perhaps because it's easier to read and understand. You can read a declaration like that left-to-right and understand it all in a single pass with no backtracking. This is not the case when you say (arg1, arg2, arg3, arg4 myType).


    Filed under: Verbosity: not always a bad thing


  • 🚽 Regular

    @masonwheeler said in go Away():

    Perhaps because it's easier to read and understand.

    This. Totally this. It's not because I don't know Go's syntax and was basing my code on an example or anything.


  • Impossible Mission - B

    Running into a bizarre problem at work, and even the local Go expert has no idea what's going on, so I figured I might as well ask @ben_lubar.

    I have a project. In this project are two packages, each in its own folder. Each folder contains various .go files that are part of that package.

    In folder A, if I say go build -v, I get a list of the stuff it's building.

    In folder B, if I say go build -v, I get an immediate return with no output.

    Both folders contain nothing but .go files, and there is no easily-identifiable reason why it is building the code in the one and building nothing in the other.

    go version returns go version go1.7.5 linux/amd64

    How in the world do I figure out what's going on here?



  • @masonwheeler in folder B, the package is already built in the pkg folder. Try the following arguments on go build:

    • -a - ignore caches completely
    • -i - put built package files in cache, like go install and go get do
    • -x - even more verbose than -v, show every subcommand as it gets executed

  • Impossible Mission - B

    @ben_lubar said in go Away():

    @masonwheeler in folder B, the package is already built in the pkg folder.

    No, it's not. I checked that. There's nothing there. (Well, there's stuff there, but not the relevant package.)

    Try the following arguments on go build:

    • -a - ignore caches completely

    OK, that one finally gets a response.

    runtime/internal/sys
    go install runtime/internal/sys: open /usr/local/go/pkg/linux_amd64/runtime/internal/sys.a: permission denied

    So... what in the world is that supposed to mean ⁉ I haven't done anything at all with internal runtime files.



  • @masonwheeler that means it's trying to install a package to /usr/local/go, which you don't have write permission for. -a ignores all caches, including the ones in GOROOT.



  • @masonwheeler by the way, after the no-output command, does echo $? print 0 or a different number?


  • Impossible Mission - B

    @ben_lubar said in go Away():

    • -x - even more verbose than -v, show every subcommand as it gets executed

    This is actually entirely useless. go install -x outputs a single line:

    WORK=/tmp/go-build026498757

    Repeated runs do the same thing, but the random numbers in the temp filename are different each time. This is not a log of the "even more verbose" output, as the file does not exist after go install finishes.


  • Impossible Mission - B

    @ben_lubar said in go Away():

    @masonwheeler by the way, after the no-output command, does echo $? print 0 or a different number?

    0



  • @masonwheeler said in go Away():

    @ben_lubar said in go Away():

    • -x - even more verbose than -v, show every subcommand as it gets executed

    This is actually entirely useless. go install -x outputs a single line:

    WORK=/tmp/go-build026498757

    Repeated runs do the same thing, but the random numbers in the temp filename are different each time. This is not a log of the "even more verbose" output, as the file does not exist after go install finishes.

    That looks like the output I get when I build an already-built package. Try go clean -i -n in the package that's giving you that problem to see where it would try to delete files. The last line should be where it's getting the package cache from.


  • Impossible Mission - B

    @ben_lubar :facepalm: OK, that finally gives me something useful. There was a different output path! Somehow output for this project is showing up in two different places under $GOPATH/pkg, (:wtf:⁉,) and I was checking the wrong one.



  • @masonwheeler said in go Away():

    /pkg

    Wait, is GOPATH set to /?!


  • Impossible Mission - B

    @ben_lubar No, that's relative to $GOPATH. :P



  • @masonwheeler said in go Away():

    is a compile-time error. Not a warning like it should be

    Any warning that is not addressed IS an error! At the very least a lazy and incompetent programmer.

    Warnings occur when something "does not look right" to the compiler, yet does not violate any hard rule. A competent developer will review this situation and if it is indeed the desired operation inform the compiler.


  • Impossible Mission - B

    @thecpuwizard said in go Away():

    Any warning that is not addressed by release IS an error! At the very least a lazy and incompetent programmer.

    Code that is currently under active development, in the write-build-debug cycle, should not be expected to be held to the same standard. The Go designers apparently do not get that. People who put -werror or its equivalent into their compilers do get that.



  • @masonwheeler said in go Away():

    @thecpuwizard said in go Away():

    Any warning that is not addressed by release IS an error! At the very least a lazy and incompetent programmer.

    Code that is currently under active development, in the write-build-debug cycle, should not be expected to be held to the same standard. The Go designers apparently do not get that. People who put -werror or its equivalent into their compilers do get that.

    I disagree (quite strongly). As an example, I will use .NET. When a project is created two things get done.

    1. The initial project is set to "All Warnings are Errors"

    2. Commits to Source Control (TFVC, Git, whatever) are blocked unless a build passes, and part of that build is to validate that every project has "All Warnings as Errors".

    ps: We also do very rapid commit cycles with each developer typically commiting one or more times during each (code editing related) 45 minute "work burst".



  • @thecpuwizard said in go Away():

    Commits to Source Control (TFVC, Git, whatever) are blocked unless a build passes

    That's great until your build starts taking multiple seconds or longer.



  • @masonwheeler said in go Away():

    @thecpuwizard said in go Away():

    Any warning that is not addressed by release IS an error! At the very least a lazy and incompetent programmer.

    I suppose it depends on what kind of 'release' you have in mind. Because laziness and incompetent are pretty much SOP in this business.



  • @ben_lubar said in go Away():

    That's great until your build starts taking multiple seconds or longer.

    Goal for build time is 90 seconds. But that is largely immaterial. Tests are running via Live Unit Testing as the developer is typing along with background compiles. Build failure rates are about 1% to 2%. So 98% to 99% of the time, it is simple "comment and commit" and move to the next item (or continue if you have an incremental sub-item). Almost zero "interruption" of the developers workflow.


  • Discourse touched me in a no-no place

    @ben_lubar said in go Away():

    GOROOT

    0_1517675378609_8d900ede-2262-41f3-b325-23f86dbfd4ad-image.png


  • Discourse touched me in a no-no place

    @thecpuwizard said in go Away():

    Commits to Source Control (TFVC, Git, whatever) are blocked unless a build passes

    So nobody else can see what you are doing at all until you have a build that is working compiling? How does that help people work as a team?

    For contrast, we permit committing to development branches, and just block merges to trunk and release branches until after code review. Code review includes compiling and passing our integration tests (i.e., you can't expect to get past it without fixing things). But then our development cycle is tuned to git (with its cheap branching and merging) rather than svn (where branches are viewed as being more significant). Your tools definitely affect how you can work efficiently.


  • BINNED

    @thecpuwizard said in go Away():

    ps: We also do very rapid commit cycles with each developer typically commiting one or more times during each (code editing related) 45 minute "work burst".

    Maybe it's because I don't code all day (or sometimes not for weeks), but that sounds incredibly stressful.



  • @topspin said in go Away():

    @thecpuwizard said in go Away():

    ps: We also do very rapid commit cycles with each developer typically commiting one or more times during each (code editing related) 45 minute "work burst".

    Maybe it's because I don't code all day (or sometimes not for weeks), but that sounds incredibly stressful.

    Do some research on the Pomodoro method. There, the standard is 22.5 minutes of work and 7.5 minutes of break. So I am running at 1/2 that speed.

    Look at most guides for planning work. One does not plan 8 hours a day, the most common number is 6 hours of planned work. Now, if you try to come in an do that 6 hours uninterrupted you will fail. Same if you spend the first 2 hours "clearing your plate" so that you can try for the 6 hours at the end of the day....

    45 minutes out of each hour is the same 75% ratio. Once adopted, it is not that hard to eliminate 99% of interruptions during the "burst".



  • @dkf said in go Away():

    @thecpuwizard said in go Away():

    Commits to Source Control (TFVC, Git, whatever) are blocked unless a build passes

    So nobody else can see what you are doing at all until you have a build that is working compiling? How does that help people work as a team?

    Actually very well, because the code is always working (i.e. all tests passing, with TDD where the tests are written just prior to the code).

    Branches actually cause a conflict between collaboration and the ability to refactor. Imagine you are working on a branch for a few days. During that interval various developers have re-named, or re-organized the same files you are working on every hour or so [therefore about 20 changes]....try to merge that.

    The typical result is either:

    1. Refactoring is not done (because it is known that it will inhibit merges of branches)
    2. Merge Hell (and it does not matter that Source Control)

  • Discourse touched me in a no-no place

    @thecpuwizard If your code is such that you've got that much churn (the file renames aren't a problem BTW; many of the better VCSs can track that) then you're really not going to be able to do any significant changes anyway. It sounds like you're working somewhere that is so dysfunctional that it has affected your ability to distinguish what is good and what isn't.



  • @dkf said in go Away():

    @thecpuwizard If your code is such that you've got that much churn (the file renames aren't a problem BTW; many of the better VCSs can track that) then you're really not going to be able to do any significant changes anyway.
    You are right that many VCS can handle re-names (many still struggle with moves) - I was more referring to adjusting the names of classes (which will probable result in the rename of files) as well as members [methods, properties, et. al.]. So consider:

    1. this morning there is "Customer.Get()" and you invoke this from some code you are working on in a branch.
    2. this afternoon, the method gets renamed to "Customer.GetAll()".
    3. Tomorrow, you do to merge, and "Customer.Get()" will be an unresolved symbol.

    It sounds like you're working somewhere that is so dysfunctional that it has affected your ability to distinguish what is good and what isn't.

    I was going to send you some additional information, but your chat is set to DND - so I respected that. If you have any interest, feel free to chat me.


  • Discourse touched me in a no-no place

    @thecpuwizard said in go Away():

    your chat is set to DND

    Really? I didn't know… and I can't find any setting that lets me change that.



  • @thecpuwizard said in go Away():

    Goal for build time is 90 seconds.

    Don't make me have to clean my keyboard! (almost spewed my coffee!) Our builds take about 1.5 hrs on the build server (low powered VM). About 20 minutes locally.


  • ♿ (Parody)

    @dkf said in go Away():

    @thecpuwizard said in go Away():

    your chat is set to DND

    Really? I didn't know… and I can't find any setting that lets me change that.

    Under your settings, the privacy section:
    0_1517842048493_24129e61-574d-4273-a9ff-d806cad350cd-image.png

    Or so I presume.



  • @dcon said in go Away():

    @thecpuwizard said in go Away():

    Goal for build time is 90 seconds.

    Don't make me have to clean my keyboard! (almost spewed my coffee!) Our builds take about 1.5 hrs on the build server (low powered VM). About 20 minutes locally.

    My condolences (and, yes, I have been there!)....

    Hate to remember when "edit a line of code" and wait 20+ minutes until the program started to run...

    Somethings that help (in many cases, sometimes one is just doomed)...

    a) A few of the organizations I have worked with have invested in high-end "gaming rigs" (overclocked, SSD or better, liquid cooled) build machines....really can help.

    b) Small builds really help. As an example (using .NET), instead of having a solution with 80 projects, have many solutions each with a handful of projects that produce Nuget packages). Can cut down by over 90% the amount of "Stuff" that needs to be examined/processed during a build.

    c) "Incremental" everything. IF you change one file, then that file is the one that gets recompiled, along with those that have a direct dependency.



  • @thecpuwizard said in go Away():

    Commits to Source Control (TFVC, Git, whatever) are blocked unless a build passes, and part of that build is to validate that every project has "All Warnings as Errors".

    This is fucking dumb (at least for git). How are you supposed to save progress if what you're working on is borked and you have a emergency thing to do. Cloning to a different directory and stashing aren't necessarily good alternatives. This should be enforced on Pull Requests (or Push if you're using a non-forking workflow, but there really should be a filter on branches that allows you a way to do this on a path that merges are blocked on).



  • @jazzyjosh If someone is working with VSTS, assume that when they say 'commit' they mean what you think of as a 'pull request' - and then think about how words work, and begin to loathe git, as you will begin to regain a bit of your humanity in so doing.


Log in to reply