<p>I ported tinywm to Go as an intro into OS dev.</p>
<p><a href="https://github.com/collinglass/tinywm">https://github.com/collinglass/tinywm</a></p>
<p>It was pretty fun. Although dealing with C unions is uncomfortable, tips and comments are very welcome! Cheers Gophers :)</p>
<hr/>**评论：**<br/><br/>dim13: <pre><p>Why didn't you use <a href="https://github.com/BurntSushi/xgb">https://github.com/BurntSushi/xgb</a> ?</p></pre>collinglass: <pre><p>O_O This looks useful. Thanks!</p></pre>gesis: <pre><p>I've been working on learning go and figured a wm would be a good project, so I looked into this. Sadly, all the example code is busted and won't run.</p></pre>burntsushi: <pre><p>Could you file a bug report please? You should also check out xgbutil and Wingo. I built Wingo a few years ago, and I've been using it as my WM since then without incident. :)</p></pre>gesis: <pre><p>when I have a bit of free time, I'll download it again and get some more useful info than "it don't work".</p></pre>lapingvino: <pre><p>now running ChromeOS, but when on Linux, Wingo was for me the perfect middle between XMonad and the usual default :).</p></pre>dim13: <pre><p>btw, if I see you here. There is a small, but annoing bug in wingo: there is a 1 pixel glitch between window content and window decoration (best seen in corners). Didn't managed to fix it myself, but since you are there, may be you can check it out?</p>
<p>And, thank you for xgb and wingo! :) Used it in some my small projects. It's really great!</p></pre>AnimalMachine: <pre><p>Oh wow. I have to take a look at that some time.</p>
<p>/bookmarked</p></pre>mc_hammerd: <pre><p>is this actually a valid way to do something: <code>someslice[:]</code>? please tell me i can get a slice copy like that!</p></pre>TheMerovius: <pre><p>It's valid, but useless (under the assumption, that <code>someslice</code> is a slice, not an array). It's the same as <code>someslice[0:len(someslice)]</code>, which is the same as <code>someslice</code>. If, on the other hand, <code>someslice</code> is an array, then that's basically a cast from an array to a slice.</p></pre>mc_hammerd: <pre><p>ok thx!</p></pre>SaidinWoT: <pre><p>It's a perfectly valid way to get a slice that fully contains an array. You can also use it to re-slice an existing slice, but it won't be copying the underlying data. Re-slicing a slice like that will just make a new, mostly-identical slice header (potentially with a different capacity, otherwise identical) pointing at the same data.</p></pre>Thomasdezeeuw: <pre><p>You can use copy (<a href="https://golang.org/pkg/builtin/#copy" rel="nofollow">https://golang.org/pkg/builtin/#copy</a>) to copy a slice or array.</p></pre>dilap: <pre><p>copy doesn't do what a lot of people expect, in particular:</p>
<blockquote>
<p>The number of elements copied will be the minimum of len(src) and len(dst).</p>
</blockquote>
<p>If you have a slice, and you want a new slice w/ the same contents, the easiest way to do that is</p>
<blockquote>
<p>slice2 := append([]someType(nil), original...)</p>
</blockquote>
<p>I think this trips a lot of beginners up.</p></pre>Fwippy: <pre><p>Any reason not to do <code>slice2 := append(nil, original...)</code> ?</p></pre>dilap: <pre><p>Only because Go requires the first argument to be a typed slice.</p>
<p><a href="http://play.golang.org/p/DQiYGNoRWI" rel="nofollow">http://play.golang.org/p/DQiYGNoRWI</a></p>
<p>Spoiler:</p>
<p>prog.go:6: first argument to append must be typed slice; have untyped nil</p>
<p>I don't think there's any reason the compiler <em>couldn't</em> figure out the type of the slice from the other arguments, but it doesn't.</p>
<p><em>shrug</em></p></pre>Fwippy: <pre><p>Oh! That's a pretty dang good reason. I'd swear I did that before, but it must have been a previously-declared var containing a nil slice. Thanks :)</p></pre>mc_hammerd: <pre><p>tbh i totally wont because its copy(b,a) and not copy(a,b)... im just kidding.</p></pre>awaitsV: <pre><p>hey i noticed that you use named returns in the func line but don't actually use the return by name</p>
<p>like <a href="https://github.com/collinglass/tinywm/blob/master/tinywm.go#L16" rel="nofollow">here</a></p>
<pre><code> func unionToInt(cbytes [192]byte) (result int) {
</code></pre>
<p>but in the return statement you do</p>
<pre><code>return *(*int)(unsafe.Pointer(uptr))
</code></pre>
<p>and</p>
<pre><code>return 0
</code></pre>
<p>a better way would be to set <code>result</code> to the proper value and just <code>return</code></p>
<pre><code>func unionToInt(cbytes [192]byte) (result int) {
result = 0
buf := bytes.NewBuffer(cbytes[:])
var ptr uint64
if err := binary.Read(buf, binary.LittleEndian, &ptr); err == nil {
uptr := uintptr(ptr)
result = *(*int)(unsafe.Pointer(uptr))
}
return
</code></pre></pre>collinglass: <pre><p>thanks, I'm aware of this actually my code should be updated to similar to your answer</p></pre>eikenberry: <pre><p>IMO it is a valid use case to name your return value but not use the name, great way to highlight the meaning of the return for godoc while still being explicit about what you are returning (some people don't like the bare return).</p></pre>Fwippy: <pre><p>I agree in the general case, but <code>result</code> isn't the most enlightening name.</p></pre>
