Now the basics are there for further releases. I need to dive a bit into the Docker thingies to figure out where to dig out the Windows build and we can publish that as well.
Someone already wrote in the venv issue that they could work on it. Maybe that will get us a full bundle.
Someone already wrote in the venv issue that they could work on it. Maybe that will get us a full bundle.
"unknown file type"
$ file pslab-2.4.0/pslab Sat 31 Oct 2020 08:07:58 PM UTC
pslab-2.4.0/pslab: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=ebb360e3c3f594213ec97bf809c969835f21f00a, stripped
Do other binaries run when you double-click them in Nemo?
Maybe the upgrade to Electron 10 will fix it. That is a bit out of scope for us. Otherwise, I would ask people to prefer the .deb/.rpm packages if they have distros built upon those, or just run from a command line. For distros where packages can be submitted easily - like Arch -, I can simply add a .desktop file there.
Is PSL supposed to be bundled? I can't find it.
Maybe there is something like a debug build option. One issue I have otherwise is that all the output is omitted, so I was completely in the dark regarding what might be going wrong regarding the path lookup for the Python scripts.
There is https://www.electron.build/#debug but that is only for build time investigation from what I can tell.
Okay, this works:
Then open http://localhost:8315/ and follow the link to
env ELECTRON_ENV=development ./pslab-2.4.0/pslab --remote-debugging-port=8315Then open http://localhost:8315/ and follow the link to
linker.html - that's the process that spawns the Python shell underneath. And then you can investigate errors there and should see the stdout/stderr output.
https://metaspora.org/pslab-debug.png should look like this
this is an example from not being able to connect without PSLab plugged in, and it should also output any other errors with interfacing with the Python library etc
The "just upgrade Electron" thing is a little more work than anticipated. There is quite some things going on in their future roadmap, so we might need to rework architectural bits. Don't worry though, there are always options and about every app relies on the core interfaces they are about to change.
With contributions towards testing and venv, we can gain stability around the integration. If IPC (inter process communication) turns put to be too complicated, we can always switch to TCP based RPC, like many other apps also do. Python can handle websockets for subscriptions, which we could use for continuous data flows like reading from sensors.
Is anyone still tracking the development of the original SEELablet / ExpEYES projects?
https://expeyes.in/ / https://github.com/csparkresearch looks like there is still much going on there.
https://expeyes.in/ / https://github.com/csparkresearch looks like there is still much going on there.
The made another board named kuttyPy, based on ATMEGA32: https://github.com/csparkresearch/KuttyPy-GUI
There are quite some docs, and this looks quite nice: https://github.com/csparkresearch/KuttyPy-GUI/tree/master/docs/firmware
We could wire up PSL with Pulseview: https://sigrok.org/wiki/Protocol_decoder_API#Backend_library
Then we don't need to care much about the logic analyzer GUI in our Electron app, in other words, we wouldn't need to reinvent the wheel. What do you think?
Then we don't need to care much about the logic analyzer GUI in our Electron app, in other words, we wouldn't need to reinvent the wheel. What do you think?
I opened this issue a long time ago using my phone (and I am a slow phone typer). So basically just noted down some bullet points back then as a reminder fossasia/pslab-hardware#74
Sure - and actually, we could even just write a decoder for it regardless. If all goes well, it is just a tiny bit of work, and suddenly, we are integrating with an awesome tool - no cons involved thus far except for a bit of work. :-)
The open questoin would be if we really want to have yet another full implementation of everything around logic analyzers. I think that is quite a bunch of work. The point I would like to raise is that a logic analyzer can very well be its own tool. Maybe it's something to brainstorm about on Saturday.
The open questoin would be if we really want to have yet another full implementation of everything around logic analyzers. I think that is quite a bunch of work. The point I would like to raise is that a logic analyzer can very well be its own tool. Maybe it's something to brainstorm about on Saturday.
Ah, I would move that issue to the Python repository. Nice!
The PSoC5LP from Cypress / Infineon may be a suitable SoC for a simple LA + oscilloscope sister board. A simple logic analyzer can be based on the CY7C68013A, which is what the BitMagic LA is based on: https://1bitsquared.de/products/bitmagic-basic
If we go for a more dedicated LA/oscilloscope, we may be able to offer more channels than the PSLab, on that note.