There is currently an effort to create a common back end for instruments via sigrok, which is a step towards unifying the code base. We will also need a common back end for things sigrok does not provide, such as the board's serial buses (UART, I2C, SPI). This back end should use libserialport (which sigrok also uses) in order to limit the number of dependencies.
Above these layers, we need higher-level functionality and specific sensor implementations. We don't have the resources to implement and support a large number of sensors ourselves, so this layer should be written in a language for which there already exists a large number of sensor libraries. That means Python, or possibly C++.
@bessman Once we are done with sigrok integration, what will the project structure look like?
This is what I had in mind
4 replies
Please review my draft GSoC Proposal : https://docs.google.com/document/d/1TFl1_0obrcRcIAG2SFgEq36CL2SnedAhGIj1hxcfLwY/edit?usp=sharing
@mariobehling @bessman @CyReVolt:matrix.org @nielek2 Any suggestion with the timeline or any other area of improvement?
Please review my GSoC proposal.
https://docs.google.com/document/d/14flk591eItsGqA1Big6lFZIgr7xAcaPTL2S98CGU208/edit?usp=sharing
and please reply for any suggestions.
@bessman @mariobehling
2 replies
PYTHONPATH, see what it currently points to; just echo $PYTHONPATH
@CyReVolt:matrix.org I did some digging …
Unfortunately setting PYTHONPATH in .bash_profile didn’t work, good thing is it explained why not … according to stackoverfow friends, basically the issues is that on OS X, command line applications and GUI applications are treated differently.
“Note that you may see here and there recommendations to either put environment variable definitions in ~/.bashrc or always launch login shells in terminals. Both are bad ideas. The most common problem with either of these ideas is that your environment variables will only be set in programs launched via the terminal, not in programs started directly with an icon or menu or keyboard shortcut.”
https://superuser.com/questions/183870/difference-between-bashrc-and-bash-profile
then I tried the ‘ setenv variable value’ in ~/Library/LaunchAgents/environment.plist
https://stackoverflow.com/questions/25385934/setting-environment-variables-via-launchd-conf-no-longer-works-in-os-x-yosemite?noredirect=1&lq=1
But apparently this is quite specific to several Mac Versions (I have Mojave 10.14 and earlier versions require edits in /etc/launchd.conf )
There are tools I can check out, though I am not sure it’s a practical approach, especially if it changes with macOS versions. One tool I found accidentially is this one https://github.com/ersiner/osx-env-sync
Maybe the most pragmatic solution is to say ‘you need to open PSLab from the cmd line’.
one question (to be safe) PYTHONPATH is to make the PSLAB files findable so they can be imported, correct? So at the moment I just point to the pip folder
/usr/local/lib/python3.9/site-packages/pslab
with the usual PSLab files, e.g. 99-pslab.rules, bus, instrument, sciencelab.py etc
So in general, if we can limit it to a two step process (a) pip install pslab + (b) download the .app
That would be a good installation, fiddling with setup files probably not ..
What do you think - should we just stick to the start from the cmd line approach?
2 replies
/usr/bin/python[3] and /usr/bin/pip[3]?
… just testing the process on a non-dev laptop where you get out of the box
- Python 2.7
- no pip
- no brew
what I think an average user could still manage - I went with the python installer ver 3.9 from python.org => Calling python still gets you 2.7 ; python3 and pip3 are good to go;
‘which python3’ points you to /Library/Frameworks/Python.framework/Version/3.9 … etc - pip3 install pslab .. installs automatically in that framework, so starting python3 and importing pslab works
- However, without any tinkering - when launching the app via icon or from the terminal, it wouldn’t connect with the device …
So maybe we have to ‘educate’ the average user :-)
4 replies
And also i dont have GSoC proposal can i still participate?
require not being available in the windows by default. I had a brief look, but couldn't figure it out exactly. We may need to rework the electron-load-balancer module. My suggestion is to spawn an org on npmjs.com for fossasia and put it there. Then we can publish our own @fossasia/electron-load-balancer as needed. WDYT?
@CyReVolt:matrix.org Hmm ok that's strange, I'll take a look at updating myself. Do you think we need to rework the electron-load-balancer because of changes in Electron 12?
If so, I think it might be simpler to migrate away from electron-load-balancer to Web Workers rather than maintain another module.
2 replies