CloudyPadmal on bootloader
init: all module files added wi… (compare)
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
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.
and please reply for any suggestions.
PYTHONPATH, see what it currently points to; just
@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.”
then I tried the ‘ setenv variable value’ in ~/Library/LaunchAgents/environment.plist
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
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?
… just testing the process on a non-dev laptop where you get out of the box
So maybe we have to ‘educate’ the average user :-)
requirenot 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-balancermodule. 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-balanceras 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.