<p>/edit seems like LiteIDE has something like "FileRun" which didn't occur when searching via google for a solution. Shortcut ALT+SHIFT+R.</p>
<p>I want to do Project Euler. So I created a "Project Euler" folder, stuffed my "task xyz.go" in it and wanted to progress.
But now the main function from task 1 is blocking the execution from task 2 because .... DOUBLE MAIN DECLARED.</p>
<p>I will NOT put my PE files into separate folder each because that's total bullshit and just stuffing them in the main folder \Golang\task 1.go and \Golang\task 2.go doesn't work either, </p>
<blockquote>
<p>main redeclared in this block
previous declaration at .\task 1.go:8</p>
</blockquote>
<p>So ..... how can I solve this?</p>
<hr/>**评论：**<br/><br/>captncraig: <pre><p>If you want anything other than "1 folder = 1 executable" you are going to be fighting the go tool, and that may be a sign you are doing things wrong. That being said, a quick brainstorm and I have a few options:</p>
<ol>
<li><p>Hack your ide to do what you want to do. I was able to accomplish this in liteide by adding the following to gosrc.xml:</p>
<pre><code><action id="BuildThis" img="blue/buildrun.png" key="Ctrl+Alt+4" cmd="$(GO)" args="build -o $(TARGETNAME) -i $(EDITOR_FILE_NAME)" save="all" output="true" codec="utf-8" regex="$(ERRREGEX)" navigate="true"/>
<action id="BuildAndRunThis" img="blue/buildrun.png" key="Ctrl+Alt+5" task="BuildThis;Run" killold="true"/>
</code></pre>
<p>Running the <code>BuildAndRunThis</code> command builds only the current file and runs it. One limitation to this is that any other utility files you have will not be compiled in. As you do euler you will find things like primes and permutations that occur often enough you will want reusable code for them. These will need to go in a subpackage and be imported by your mains.</p></li>
<li><p>Each problem in its own folder in it's own main package. This is really the sensible option, and I think you are overstating the problems associated with it. I know it sounds apologetic, but there are some facets of go where you just need to bite the bullet and do the ugly thing for no other reason than pike says so. Fighting the tooling is rarely worth it.</p></li>
<li><p>Single main. You will rarely be working on multiple problems at once so just have a single main function and a function for each problem. Your main will simple be a call to <code>euler47()</code> or whichever one you are working on at the time. Yeah, you have to manually change it, but it may be the simpler option for you. </p></li>
<li><p>When I was doing PE in c# I implemented each one as an nuint test so I could run them on demand, but go also doesn't yet seem to have a good tool for running only a single test. You could do <code>go test -run Euler42</code> and have your individual functions implemented as uint tests: <code>func TestEuler42(t *testing.T)</code> </p></li>
</ol></pre>natefinch: <pre><p>well, first off, it's not bullshit, it's the way go works.</p>
<p>Second, if they're all likely going to be single file programs, you can just target them individually:</p>
<pre><code>go build task1.go
// outputs executable in current directory called task1
// won't build any files not specified on command line
</code></pre></pre>Yojihito: <pre><p>Then I have 500 folders I have to create, rename and every folder has 1 single file. Brilliant idea ......</p>
<p>And I don't work on the console, I use LIteIDE, CTRL+R to run, done. That's the reason I use an IDE.
I guess your solution doesn't work in LiteIDE or any other IDE? Without me typing in the console at all of course = shortcuts.</p></pre>om0tho: <pre><blockquote>
<p>And I don't work on the console,</p>
</blockquote>
<p><a href="http://i.kinja-img.com/gawker-media/image/upload/s--bfm5sLsU--/gaqifx9s5k33teds1xif.jpg" rel="nofollow">http://i.kinja-img.com/gawker-media/image/upload/s--bfm5sLsU--/gaqifx9s5k33teds1xif.jpg</a></p></pre>davecheney: <pre><p>Please don't be hyperbolic. The time taken to create a directory in addition to creating a file inside that directory, and of course, solving the problem, is negligible.</p>
<p>This is the layout mandated by the go tool, you don't have to use it if you don't want to, but if you do use the go tool, you have to live by its rules.</p></pre>Yojihito: <pre><p>No, it is not negligible, at least for me. And if I don't use the go tool, I have to compile via console and lose gofmt, so much fun on Windows ....</p>
<p>I drop Go, no need to stick around with a company that competes with Apple to force people to use their way. Thanks for the help, but "use Gopath or fuck off / develop like it's the 80s" is not for me I guess.</p></pre>skelterjohn: <pre><p>Your response is a bit baffling. The difference between creating a file with euler code and creating a directory with a file with euler code really is negligible. </p>
<p>Presumably, most of your time would be spent writing the euler code.</p></pre>Yojihito: <pre><p>When I have to look at source code from one of the files I have to dig through 500 folders instead of having every file lined up for example. I'm totally fine with a mandatory structure like "src + bin + whatever config makefile or so".</p>
<p>But I want to structure my projects in my own way, creating 500 different project folders because the Go toolchain is too dumb to handle when they all belong in the same folder because it's the SAME project but different parts of the project is nothing I will ever do.</p></pre>skelterjohn: <pre><blockquote>
<p>But I want to structure my projects in my own way</p>
</blockquote>
<p>That's the bit. You don't get to do this with the go tool. And it's good, because then everyone structures their projects the same way.</p>
<p>Sorry, you're still ridiculous.</p></pre>Yojihito: <pre><p>On my own PC at home I feel like I should be able to do so. Also, what's bad about "everyone structures tbeir projects the same way"?</p></pre>skelterjohn: <pre><p>The first post indicated you can have dir/a.go dir/b.go etc., run "go build a.go && a" or "go run a.go", and everything works fine.</p>
<blockquote>
<p>Also, what's bad about "everyone structures their projects the sane way</p>
</blockquote>
<p>The problem is that there are too many sane ways to do it. The go toolchain chose exactly one sane way to structure things for when you want imports to work, and to automatically know if several files are supposed to be compiled together into one package. The rule is: if they're in the same directory, then running 'go install' pointing at that directory will use all of them.</p></pre>Yojihito: <pre><p>Sorry, got autocorrected from "same" to "sane". Also I misreaded your post, now the "everyone has projects the same way" makes sense.</p></pre>davecheney: <pre><p>Google haters anonymous is the next sub reddit over. Keep it nice or don't post at all, thanks.</p></pre>Yojihito: <pre><p>Where did I hate Google? You can't distinguish between "criticism/I don't like something because reasons" and hate it seems.</p></pre>davecheney: <pre><blockquote>
<p>I drop Go, no need to stick around with a company that competes with Apple to force people to use their way.</p>
</blockquote>
<p>Seemed pretty hateful to me.</p></pre>Yojihito: <pre><p>You need to reread the definition of "hate" ....</p></pre>natefinch: <pre><p>You seem to be complaining to me that your IDE doesn't do everything that the go command line tool does. I don't think that's my fault.</p></pre>om0tho: <pre><p>Supposing you have one folder with a bunch of <code>probn.go</code> files in that folder, you could do this.</p>
<pre><code>go run prob1.go
go run prob2.go
go run prob3.go
</code></pre></pre>Yojihito: <pre><p>But I only want to compile and run one .go file at once. In my IDE. In the IDE console. Because that's why I use an IDE.</p></pre>captncraig: <pre><p>LiteIde is suprisingly configurable. If you open up gosrc.xml you can see the command button config. You could easily rig one up to do 'go run currentfile.go` on whatever key you want.</p></pre>Yojihito: <pre><p>I don't see something like that in the xml file, could you give me the name of the "id" field where this option is in the config?</p>
<p>Do you know the command options to get "go run currentfile.go" into some valid parameters?</p></pre>om0tho: <pre><blockquote>
<p><a href="http://i.kinja-img.com/gawker-media/image/upload/s--bfm5sLsU--/gaqifx9s5k33teds1xif.jpg" rel="nofollow">http://i.kinja-img.com/gawker-media/image/upload/s--bfm5sLsU--/gaqifx9s5k33teds1xif.jpg</a></p>
</blockquote></pre>ChristophBerger: <pre><ol>
<li><p>Please follow the rediquette when posting here. (edit: I am referring to some of the comments you made here, not to the original post.) It is a matter of respect towards those who you seek help from.</p></li>
<li><p>Have you already thought about creating a single executable only? Have your main() function read the name of the task from os.Args() and call the respective function. Then call the exe with the task name as the first parameter. This way you can keep all source files in one directory.</p></li>
</ol></pre>Yojihito: <pre><p>So you mean a main.go with 500 lines of "switch case" that parses the os.Args() and calls the parametername.exe when it gets a match?</p>
<p>Won't do that because of 500 times switch/case, that's just insane.</p></pre>ChristophBerger: <pre><p>That's probably the solution a beginner would come up with.</p></pre>Yojihito: <pre><p>I am a beginner.</p></pre>ChristophBerger: <pre><p>Don't get me wrong: It would be perfectly fine (that is, not a "beginners solution") to use something like a switch statement if the number of cases is reasonably small. But I agree that this approach does not scale well.</p>
<p>To save a bit of typing work, you can replace the switch/case code by a map from string to function. Whenever you write a new Euler task function, add it to this map. The key would be the name you give it on the command line.
Then you can lookup the function by its command name and call it.<br/>
See a working example <a href="http://stackoverflow.com/a/15507147/2322962" rel="nofollow">in this stackoverflow post</a>.</p>
<p>To be honest, for the ultimate reduction of this problem I was thinking of using reflection - I had something like a "CallFunctionByName(name)" call in mind, but it turned out that the reflect package <a href="http://golang.org/pkg/reflect/#Value.MethodByName" rel="nofollow">can do this only with methods</a> but not with free functions. </p></pre>
