<azonenberg>
Anyway, the next board i'm doing will be the active diff probe
<azonenberg>
and the SMA launch there will be rigid
<azonenberg>
but before i do the board i have a few mechanical design iterations left to do i think
<GenTooMan>
If you have suggestions on good SCPI API design for users let me know. I would like to learn from other's mistakes instead of repeat them to be honest.
<azonenberg>
you mean for building your own instruments?
<azonenberg>
Fundamentally, the big problem with the classical SCPI model is a) it's polling based and b) data and control plane are mixed
<azonenberg>
Which is why in the pico bridge i solve both of those by having a scpi socket for control plane and a separate socket for binary waveform download that's push based
<azonenberg>
i.e. you don't need to ask for a waveform
<azonenberg>
it's sent as soon as it's ready
<azonenberg>
Other than that, the big thing is orthogonality. Don't have 30 different ways to refer to the same concept
<azonenberg>
have analog and digital channels share common controls and formatting whenever feasible
<azonenberg>
Have commands do expected things and be tolerant of latency
<azonenberg>
avoid situations where you have to send one command based on the return value of another
<azonenberg>
A lot of these problems are largely eliminated in the headless model anyway
<azonenberg>
e.g. there's no worry of the user messing with settings on the front panel under your nose
<azonenberg>
but consider the case of what happens if the user turns on a channel after arming a trigger
<azonenberg>
or off
<azonenberg>
or changes timebase
<azonenberg>
and what if you're halfway through an acquisition when that happens
<azonenberg>
So it's important to plan synchronization, maybe even discard triggers or something, so you dont end up with garbage as settings change halfway through a capture
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<dang`r`us>
azonenberg, so quick heads up, my plan is to properly redo my port in a few hours. I also have an intel macbook here so I'll first port to that, making sure all BSD& appleisms are covered, and afterwards do the m1 work
<dang`r`us>
I also got my employer interested in using glscopeclient for an upcoming embedded course, so if that materializes I'll be able to dedicate a bit of my work time to the port!
someone--else has joined #scopehal
<monochroma>
did the lack of opengl compute shaders on mac os get figured out?
someone--else has quit [Quit: Connection closed]
bvernoux has joined #scopehal
someone--else has joined #scopehal
<azonenberg>
dang`r`us: awesome
<azonenberg>
monochroma: No, although we have a plan forward (writing an OpenCL based alternate renderer)
<azonenberg>
as of now libscopehal and libscopeprotocols compile and (probably) run with dang's ports on mac
<azonenberg>
glscopeclient builds and runs to the point of trying to initialize the waveform area
<azonenberg>
then fails with missing opengl features
<azonenberg>
Any idea on when you'll get around to fixing the merge conflicts around the mingw package cleanup?
<azonenberg>
GyrosGeier: status on the debian packaging?
<dang`r`us>
judging from his twitter/irc activity the last days GG seems to have been derailed by Jenkins
<azonenberg>
Lol, i see
<azonenberg>
Ok so i'm probably gonna be doing a bunch of GUI oriented stuff today
<azonenberg>
let's see how far i get
<GyrosGeier>
indeed
<GyrosGeier>
but after two days I now know that the success of compiling an FPGA image that uses Qsys depends on the contents of ~/.altera.quartus/quartus2.ini
<GyrosGeier>
also, I have a desire to set things on fire I didn't have on Friday
<GyrosGeier>
the packaging is in "needs testing" state
<GyrosGeier>
to see if some path is broken
<GyrosGeier>
otherwise all that's left is a few finishing touches to get rid of warnings from the automatic checks
<GyrosGeier>
(these are harmless, mostly complaints about missing versions on the shared libraries)
<GyrosGeier>
since the libraries aren't meant to be shared, that's fine
<GyrosGeier>
other than that, it will be portability fixes from the porters (which likely happens after the packages hit Debian unstable) and some extra work to make ffts fast everywhere
<GyrosGeier>
like identifying configurations where a separate binary is worth it
<GyrosGeier>
ffts is significantly more work than glscopeclient
<azonenberg>
Yeah i figured
<GyrosGeier>
also because m68k people have an expectation that ffts works there
<azonenberg>
Do you think having alpha level packages people can install for testing by mid July is viable?
<GyrosGeier>
the ones in my tmp folder are fine for that
<azonenberg>
The reason i ask is, i'm doing a conference talk on glscopeclient for hardware RE in july, exact date TBD
<azonenberg>
it looks like it's going to be a 30 minute talk plus 30 minutes of interactive mini-workshop with people following along examples
someone--else has quit [Quit: Connection closed]
<azonenberg>
So even if we're not at a 0.1 release yet, i at least want nightly binaries they can play with and install easily
<GyrosGeier>
these packages are usable from my POV, they just need some polishing for Debian still, and more tests than "the demo source can be decoded"
<GyrosGeier>
for automated nightlies, the tarball script I have + a job that calls uupdate in a Debian container should work
<GyrosGeier>
I can probably set up something like that
<azonenberg>
Great. Not a huge rush but i'd like it by end of June if possible
<GyrosGeier>
might make sense to allow concurrent installation with a stable release
<azonenberg>
I don't see that being necessary at this stage of things, since the official v0.x series will be essentially public betas anyway
<azonenberg>
"stable" will start at v1.0
<azonenberg>
I expect there will be a lot of changes by that point
<GyrosGeier>
mh
<azonenberg>
in the near term if people want a dev build to play with that won't mess with a binary release, they should just install from source and run in the build directory
<azonenberg>
and if they want to "make install" that to /usr/local they can do that
<GyrosGeier>
I want to have some packages in Debian so they are known to the archive management software
<azonenberg>
Yeah, in experimental
<GyrosGeier>
yes
<azonenberg>
But they shouldn't be hitting stable until 1.0
<azonenberg>
I don't yet know how many 0.x releases there will be
<azonenberg>
so far i have plans for 0.1 and 0.2
<GyrosGeier>
stable releases are a different beast
<GyrosGeier>
because users expect support
<azonenberg>
Yeah exactly. also things like some level of ABI compatibility etc
<GyrosGeier>
so I'd block that unless we have a volunteer to support the version that ships in stable until the next release
<azonenberg>
The main point of the 0.x series is to be usable for early adopters to shake out more bugs, get more eyes on the code, and prepare for an actual stable release
<GyrosGeier>
there is a "volatile" distro that users have to explicitly enable with laxer restrictions
<azonenberg>
Yeah it could work for that
<azonenberg>
but e.g. i won't be backporting any fixes for bugs or anything at the current state of development
<electronic_eel>
azonenberg: are you interested in having packaging prepared/tested for other distros than debian?
<GyrosGeier>
"stable" in Debian means "we ship with 1.0 and users will install that from CD-ROM for the next three years"
<azonenberg>
Yeah, exactly
<dang`r`us>
ah, GyrosGeier has spawned
<electronic_eel>
i mean not officially in the repos, but prepared to be upstreamed
<azonenberg>
electronic_eel: There is a pending ticket for an arch package that AFAIK nobody is working on
<azonenberg>
I don't know if anyone has made a ticket for RPM-based packaging yet
<dang`r`us>
GyrosGeier, I'm about to start here, will first fork ffts and then start with an *intel* mac port of scopehal
<electronic_eel>
i could do Fedoar if you want
<azonenberg>
but i will take one if folks are interested
<electronic_eel>
*Fedora
* GyrosGeier
is on the way to bed
<azonenberg>
electronic_eel: please file a ticket for that so we can track status
<GyrosGeier>
long week ahead
<GyrosGeier>
because none of my code is working
<electronic_eel>
ok, will do
<GyrosGeier>
(at work)
<azonenberg>
electronic_eel: If you can get an alpha level fedora package in time for hardwear.io USA in July, that would be ideal
<azonenberg>
i'm going to try and get the windows MSI packages to a testable level by that point too
<dang`r`us>
GyrosGeier, ok I'll just march on the
<dang`r`us>
n
<GyrosGeier>
dang`r`us, yes, we shouldn't conflict there unless you add testcases
<GyrosGeier>
and even there I'm not anywhere where I have something usable
<dang`r`us>
won't have time for that tonight.
<electronic_eel>
iirc i'm already running a packaged version for Fedora. what really takes time and patience with Fedora is getting it upstreamed, because that requires a peer review
<GyrosGeier>
same for Debian
<GyrosGeier>
which is why we're getting this started now
<GyrosGeier>
anyway
<electronic_eel>
so getting something ready, that is not upstream in Fedora, but just on the scopehal website or similar, is easy
<GyrosGeier>
11 PM, I defo need to sleep if I want to be at work at 5
<electronic_eel>
an perfectly reasonable to do in june
<dang`r`us>
oof
<dang`r`us>
n8
<azonenberg>
electronic_eel:l Yeah exactly. First milestone is getting the scripts and packages ready
<azonenberg>
in time for the con
<GyrosGeier>
will likely be 6 or 7 anyway
<GyrosGeier>
n8
<azonenberg>
but i want to get the ball rolling for upstreaming too
<azonenberg>
I don't intend to be shipping a fully upstreamed package you can install on a stable debian release until v1.0, arch and fedora are targeting more bleeding-edge stuff so we might consider upstreaming 0.x packages for them
<azonenberg>
But in any case the prep work of getting the package generation scripts reviewed, dependencies figured out, etc needs to start happening now
<electronic_eel>
i would start with a custom scopehal repo you can easily add to your system. adding that is pretty simple and gives the users everything they need
someone--else has joined #scopehal
<electronic_eel>
something completely different: i'm making a board where i want some testpoints. these testpoints should be optimized for usage with the AKL-PT1. does anybody have proven testpoint layouts for this?
<azonenberg>
electronic_eel: For the PT1? the signal and ground contacts are at 2.5mm spacing
<electronic_eel>
i thought of two holes spaced for the signal and gnd sockets. then solder short stubs of 0.6mm wire into the holes. the the 0.6mm wire can directly plug into the sockets of the probe
<azonenberg>
I've never tried doing that, you could try
<azonenberg>
if you wanted solder in why not use an AKL-PT2?
<electronic_eel>
hmm, i don't have PT2s at hand
<azonenberg>
That's a valid reason i guess. but if you're designing boards anyway why not make one?
<azonenberg>
you can do it on oshpark flex, just will have to cut a piece of scrap pcb to shim under the SMA to stiffen it
<electronic_eel>
there are like 6 testpoints on my board and i expect i will want to switch probing between them. so i would have to solder 6 PT2s on there. soldering just the wires and then plugging in the PT1 seems easier to me
<electronic_eel>
ok, i think i'll have to experiment with that
<dang`r`us>
so I've looked at existing ffts forks and this one seems to be at least somewhat active: https://github.com/vochlea/ffts - I'll branch off this one for now.
<electronic_eel>
if i read the debian packaging description https://github.com/azonenberg/scopehal-apps/issues/141 correctly, you plan to just have glscopeclient, glscopeclient-dev and ...-data, but no separate libscopehal package?
<azonenberg>
electronic_eel: There will be no -dev package or libscopehal/libscopeprotocols package until v0.1
<azonenberg>
We will not be packaging headers
<azonenberg>
until v1.0*
<azonenberg>
This is by design, as the ABI is not stable yet
<electronic_eel>
but libscopehal is a separate project with it's own repo and releases, right?
<azonenberg>
We want to discourage people from relying on the libraries other than with the provided glscopeclient binary
<electronic_eel>
ok, i understand
<azonenberg>
Once v1.0 happens and there is some semblance of abi stability
<azonenberg>
the libscopehal/libscopeprotocols binaries will move to their own package
<azonenberg>
and a -dev package will be created
<azonenberg>
In the meantime, anyone who wants to build against the libs has to build from source
<electronic_eel>
but the fedora packaging guidelines very strongly nudge you to create a separate libscopehal package for this case. so i would already do it this way, to keep packaging consistent
<azonenberg>
As long as it's not merged into mainline, sure. What about libscopeprotocols?
<azonenberg>
you could hypothetically use scopehal without scopeprotocols
<azonenberg>
although glscopeclient depends on both
<electronic_eel>
yes, libscopeprotocols would get it's own package too
<azonenberg>
Ok
<azonenberg>
Yeah, if you want to do that for your own unofficial repo that's fine
<azonenberg>
Basically i want to avoid a situation where somebody creates a project that depends on our binary libscopehal v0.1 release then it bitrots when v0.2 comes out
<azonenberg>
or even v0.1+ nightlies
<electronic_eel>
i think if you clearly state that the abi isn't stable and will constantly change, users basing their stuff on it without coordination with you are just stupid
<electronic_eel>
especially since you don't seem like the type to me that is hard to get in touch with
<azonenberg>
True
<azonenberg>
As a general rule, the 0.x series will get no backported fixes, and binaries built from two different git commits are not assumed to be abi compatible
<azonenberg>
the intent is that by 1.0 we will have support for enough scopes, and enough platforms, that we won't be doing any broad refactoring for a while
<azonenberg>
and we can limit ourselves to bug fixes, support for new instruments and protocols, etc
<electronic_eel>
do you plan to host the package repos for the different distros at antikernel.net (or similar) until they are taken into the official distro repos?
<azonenberg>
I haven't figured that part out yet
<azonenberg>
We also don't have a website for the project outside of the github page
<azonenberg>
So that needs to change by v0.1 as well
<azonenberg>
Generally polish work all across the board
<azonenberg>
i need to make a pass through the user manual and make sure all of the setup information, dependencies, etc is correct, the list of supported scopes is up to date
<electronic_eel>
ok, no problem. but would be nice to have at least a stable url when you want some people to install it in july
<azonenberg>
Exactly
<electronic_eel>
website doesn't need to look pretty, just stable urls
<azonenberg>
That and v0.1 will be happening this summer
<azonenberg>
so june is going to be our time to get all of that ready
<dang`r`us>
so (still on intel mac) - how do I make catch2 optional? currently: https://dpaste.org/kAHy
<dang`r`us>
this pastebin also shows suspicious activity around yaml-cpp (I mentioned this before, but let's focus on catch2 first)
<dang`r`us>
I suppose BUILD_TESTING defaults to true, I'll try messing with that
<dang`r`us>
ah yeah, -DBUILD_TESTING=OFF. got it.
<_whitenotifier-7>
[scopehal] mubes opened pull request #488: Changes as a result of testing Siglent Triggering modes - https://git.io/JGlr2
<dang`r`us>
side note: the shell commands in the PDF doc aren't very copy-pasteable (LaTeX inserts some whitespace...)
<dang`r`us>
ok, so one issue with yaml-cpp seems to be that scopehal requires it, but only glscopeclient sets the inclue path: https://dpaste.org/kr75
<dang`r`us>
I'll try to augment.
bvernoux has quit [Read error: Connection reset by peer]
<dang`r`us>
yeah, adding the same yaml dance to scopehal that's present in glscopeclient does the trick.
<_whitenotifier-7>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±12] https://git.io/JGlKp
<_whitenotifier-7>
[scopehal] mubes 33866a1 - Changes as a result of testing Siglent Triggering modes
<_whitenotifier-7>
[scopehal] azonenberg 939873a - Merge pull request #488 from mubes/siglent_test Changes as a result of testing Siglent Triggering modes
<_whitenotifier-7>
[scopehal] azonenberg closed pull request #488: Changes as a result of testing Siglent Triggering modes - https://git.io/JGlr2
<dang`r`us>
for whatever reason, Apple does not ship CL/cl2.hpp .. unsure how to *properly* fix this. it's a separate download from Khronos anyway, probably just mention in the docs that people should put it in e.g. /usr/include/CL ... (see also e.g. https://qrack.readthedocs.io/en/latest/opencl.html )
<azonenberg>
dang`r`us: afaik it's a wrapper around the opencl api
<azonenberg>
so it should be possible to just grab that header
<dang`r`us>
exactly
<dang`r`us>
I mean, I'd vendor it, but that's probably not cool licensing wise
<azonenberg>
but if it's missing while the rest of opencl is present, it should be detected at cmake time