<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #281: Allow horizontal scrolling with mouse wheel or touchpad - https://git.io/JkOnw
d1b2 has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #184: When loading a save file, the view sometimes has a weird negative offset putting the view off to the left of the data - https://git.io/JkOzw
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #184: When loading a save file, the view sometimes has a weird negative offset putting the view off to the left of the data - https://git.io/JUggb
<d1b2>
<esden> Hey everyone from the 1BitSquared Discord server. 🙂 o/
<azonenberg>
Woo
alexhw has quit [Ping timeout: 240 seconds]
<d1b2>
<Attie> o/ hi all
<d1b2>
<esden> still need to fix the webhook on the discord side of things...
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #scopehal
<esden>
ok let's see how that looks
<d1b2>
<esden> ok, that is better I guess... 😉
<azonenberg>
attie: so how's your setup going? and remind me which scope were you planning to use?
<azonenberg>
I implemented the 1-wire decode based on the CSV you sent me, but haven't touched the I2S
<d1b2>
<Attie> going okay so far thanks... looks like Catch2 might be a new dependancy - i'll make a PR with revised steps if so
<d1b2>
<Attie> and it'll be an Agilent MSO-X 2024A
<azonenberg>
attie: catch2 is a new dependency, it's documented in the manual
<azonenberg>
tl;dr most distros don't have version 2 in the repos yet as a prebuilt
<d1b2>
<Attie> fair enough... I was going to send a new 1-wire capture (with a note about what was actually expected after decode)
<azonenberg>
i think ubuntu 20.10 is the first to have it
<d1b2>
<Attie> ah, don't forget i'm on windows atm
<azonenberg>
We do not currently have instructions for setting it up on windows so yeah a PR is welcome. You can also just disable testing
<d1b2>
<Attie> (it doesn't appear to be mentioned in the windows setup steps)
<azonenberg>
there's a cmake switch in the manual talking about turning it off i think?
<d1b2>
<Attie> oh i see
<azonenberg>
it's only needed if you want to build the two unit tests we have
<azonenberg>
although hopefully down the road we will have a lot more :p
<d1b2>
<Attie> understood - i missed that note
<d1b2>
<Attie> ^_^
<azonenberg>
let me know how it works for you on windows. i havent tried using it on win for a while
<azonenberg>
we have windows CI builds so it should at least compile
<d1b2>
<Attie> [ 35%] Built target scopehal ......
<d1b2>
<Attie> there's a pretty sizable lump after that ... same for you?
<d1b2>
<Attie> i just had to start the build again, and ran into the same stall
alexhw has joined #scopehal
<azonenberg>
d1b2: is it just linking? i seem to recall hearing mingw's linker is slow
<azonenberg>
attie*
<azonenberg>
sorry, talking to you not the bridge :p
<esden>
heh... the tab completion with those bridges is not ideal... sorry :(
<Bird|otherbox>
azonenberg: sorry for the slowdown, hardware juggling is in season atm
<azonenberg>
Bird|otherbox: lol, no problem. Was just following up with everyone who said they were working on some stuff figuring out what status was
<azonenberg>
if the status is "no progress" that's fine, i just want to know
<d1b2>
<Attie> @azonenberg - i could be, though if it was linking, i'm surprised it's going it again on subsequent runs...?
<d1b2>
<Attie> it's built, and seems to be talking to the scope!... icons are all missing though
<azonenberg>
attie: interesting @ icons
<azonenberg>
it's probably a path resolution issue of some sort
<azonenberg>
wrong current directory or something
<d1b2>
<Attie> hm, ok... i'll look into it
<d1b2>
<Attie> also all the stdout/stderr is coming out wrapped to a single column (in the MINGW64 shell)
<azonenberg>
interesting. That is probably a bug in liblogtools
<azonenberg>
It tries to detect terminal size on windows by calling GetConsoleScreenBufferInfo()
<azonenberg>
that might be going bad
<azonenberg>
if you wanna investigate that, set a breakpoint on lib/log/STDLogSink.cpp:67 and see what m_termWidth is being set to
<d1b2>
<Attie> sounds like a reasonable explanation
<azonenberg>
we also are not checking the return value on 66 so if that's failing that could be part of it
<azonenberg>
Maybe under mingw windows we should be using posix apis and not windows apis
<azonenberg>
File a bug against liblogtools with a screenshot, if you have time look into it
<d1b2>
<Attie> i'm afraid i can't comment on that one... though i wouldn't have thought it would be required / broken
<azonenberg>
(github.com/azonenberg/logtools/)
Bird|otherbox has quit [Remote host closed the connection]
<azonenberg>
The reason logtools cares about width rather than just letting the shell wrap is that it does smart indentation
<azonenberg>
so if you wrap inside an indented block it will indent the wrapped text
<azonenberg>
Anyway, the icon loading is probably failing in OscilloscopeWindow::PopulateToolbar()
<azonenberg>
it looks for the icons in icons/ in the current working directory, and i believe when glscopeclient starts up it chdirs to the directory the binary is located in
<azonenberg>
The cmake script is supposed to copy them there but it's possible that failed somehow
<azonenberg>
As a short term fix you can probably just copy the icons there
<azonenberg>
if they're already there something else went wrong
<d1b2>
<Attie> copying the icons dir resolves that one - the step is missing in the windows instructions (it doesn't say to use cmake for install), and placing icons next to the binary, we end up with /mingw64/bin/icons, which is not ideal
<d1b2>
<Attie> re wrapping, i'll dig in now
<d1b2>
<Attie> ... re icons, actually we already have shaders, styles and gradients in /mingw64/bin, so i'll just add the icons step