If you are wondering where the data of this site comes from, please visit GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Jamie Webb jwebb XTX Markets London

jwebb/optional 5

Convenient command line parsing for Scala

jwebb/npmmvn 4

Hack to read NPM modules from a Maven repository

jwebb/minitest 1

A concise unit testing framework for Scala

jwebb/crypto 0

Fork of adding some non-standard SSH modes seen in the wild

jwebb/echo 0

An ugly way to manage translated copy

jwebb/minctest 0

A simple and concise unit testing framework for C

issue openedgolang/go

cmd/go: "help test" caching paragraph is out-of-date and potentially misleading

First the out-of-date part: In the special-casing of -timeout was removed, but the documentation for this behaviour at 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

issue commentopsgenie/opsgenie-go-sdk-v2

Cannot define immediate notification in notification rule step

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

issue commentTigerVNC/tigervnc

One-shot remote resize

-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).

Extending -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

issue openedTigerVNC/tigervnc

One-shot remote resize

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:

  1. A single-shot "Resize session to window" menu option, to complement the existing "Resize window to session".
  2. 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