Convenient command line parsing for Scala
Hack to read NPM modules from a Maven repository
A concise unit testing framework for Scala
Fork of golang.org/x/crypto adding some non-standard SSH modes seen in the wild
An ugly way to manage translated copy
A simple and concise unit testing framework for C
First the out-of-date part: In https://github.com/golang/go/commit/c55a50edb9454dbdaca165be4b030a1e0cfbaa19 the special-casing of
-timeout was removed, but the documentation for this behaviour at https://github.com/golang/go/blob/master/src/cmd/go/internal/test/test.go#L131 is still there.
Now the misleading: To correctly interpret "the run involves the same test binary and the flags on the command line", one has to understand some amount of the inner workings of the test process - specifically that we are talking about only those flags that are actually forwarded to the binary under test, and not all flags passed to
go test itself. So for example
-vet is fine to use for a cacheable run. Further, AFAIK the flags that are/aren't forwarded aren't enumerated in any documentation, or even in a single place in the code - there's a little discussion at
go help testflag but no list.
I think the clearest way to resolve this would be to remove the flag-level detail in that paragraph, and instead explictly state the caching behaviour of each flag in
go help testflag, i.e. "Cacheable" / "Ignored for caching" / "Prevents caching".
created time in 19 hours
Any news on this? It's a one-line fix. (trabab's proposed workaround is not valid - cannot possibly compile - since TimeAmount is not a pointer.)
comment created time in a month
-DesktopSize is just the command-line equivalent of the GUI option I mention in (2). AFAIK it's limited to specifying the framebuffer bounding rectangle, i.e. it can't transmit the correct layout information to allow the remote to do things like maximise a window to fill one monitor. The dynamic remote resize logic is actually smart enough to send the full multi-monitor layout to the remote (and for me this correct multi-monitor handling is the single biggest advantage of TigerVNC over its peers).
-DesktopSize to support specifying a complete layout would be an option that's consistent with TigerVNC's abilities in general, but seems like bad UX: It would be painful for the user to come up with the correct parameters, and I can't imagine any parameters being chosen other than "what I have physically in front of me". That is, another way to read my suggestion (2) is "Provide a
-DesktopSize=fullscreen option, supporting multi-monitor layouts, plus equivalent GUI".
Regarding the remote (Gnome) handling resizes gracefully, it sort of mostly works, but seems flaky. It seems to randomly miss windows, change window z-order, and also to move windows one at a time, which for me means shipping all the pixels of a 5760x2160 framebuffer several times over, so it's pretty janky.
comment created time in 2 months
I find myself connecting to the same server from clients with different multi-monitor configurations. While using the client, I'll mostly run full-screen, but occasionally jump out to use the local machine. I don't want my remote window layout messed up every time I do this.
Currently AFAIK getting this to work involves a little dance each time I connect:
- Make connection
- Settings -> Screen -> Enable remote resize
- Go full-screen
- Settings -> Screen -> Disable remote resize
Seems like what I want is one or both of:
- A single-shot "Resize session to window" menu option, to complement the existing "Resize window to session".
- Changing the "Resize remote session on connect" option to allow specifying a size that's "whatever my selected fullscreen layout is", which may be non-rectangular.
I'd take a look at implementing these, but I'd appreciate some feedback first on the approach.
created time in 2 months