I'm trying to run a program (http://dar.linux.free.fr/) that I built myself using Cygwin for Windows/32. I'm now trying to run it using a more recent (not by much, just a few months) version of Cygwin. Instead of running, it spits out:
2 [main] dar (xxxx) shared_info::initialize: size of shared memory region changed from 37742 to 38776
I presume this is due to attempting to run using incompatible dynamic libraries. A curious thing is that if I run it from a regular (ie non-Cygwin) then it runs fine. It also runs if I type
cmd /S dar
although in the latter case I get some warnings about there being no terminal and hence no user interaction.
OK so maybe I should just rebuild it using the current version of Cygwin. But this is a slow and painful process, and not one I'd like to have to go through every time I upgrade Cygwin. And the fact that the code runs fine outside the Cygwin environment gives me hope that I can make it work.
I tried changing the PATH in the Cygwin environment to force it to pick up all the Cygwin dynamic libraries that were bundled with the dar executable (ie the same ones that are used when running outside Cygwin). But I had no luck there.
Can anyone suggest a simple solution or work-around?
Many thanks!
Related
How do I solve this?
TypeError: As of 3.10, the *loop* parameter was removed from Lock() since it is no longer necessary
I'm trying to use Binance socket manager, and I'm getting this error.
Should just be a case of upgrading your websockets version from 9.1 to 10.x
pip install --upgrade websockets
I've had the same issue. My bot ran fine on MacOS, but it popped up when I installed Fedora on the Apple instead. Never resolved it before moving on to other OS's, but I don't know if it would have happened on Ubuntu or Zorin, because a PIP problem stopped me long before then.
As for my primary, an MSI gaming laptop running Windows 11, I never had the issue on the command line python, IDLE, PyCharm, Visual Studio, nor Visual Studio Code, UNTIL this morning when my laptop overheated and shutdown. When I booted up again, the system no longer recognized the modules I had been using (pandas, pytz, python-binance) and they had to be installed again (from an elevated command line, which seemed odd). Then when running the program from VS, there comes the error again. Command prompt returns the same error, however, IDLE runs the program without issue. I'm not knowledgeable enough to say how to directly fix the bug, or even why it's happening, but it seems that there may be methods of skirting it. The error reads 'As of 3.10...' so if you cannot find an application that can run it, you might try rolling it back to 3.9. Sorry I can't be of any real aid, here. Hope you find your answers. I'll keep looking, too.
I've come up with several solutions.
I created my own ticker:
play = client.get_symbol_ticker(symbol='BTCUSDT)
def start_ticker():
global play
while True:
play = client.get_symbol_ticker(symbol='BTCUSDT')
print(play['Price'])
time.sleep(1)
bsm = ThreadedWebsocketManager()
bsm.start()
start_ticker()
Now, this is just a sort of preliminary example. I've tied it into my actual trading loop and removed the print function, but store and process the data second by second. I run multiple tokens simultaneously and set the sleep at the end of the entire loop, after the condition evaluations have been processed. You can tweak the rest time after testing the duration of your loop, but overall it's hasn't ever shown to be critical for it to be off by fragments of a second. One caveat is that it only delivers the flat price, but you can check the documentation for additional queries you can pull from: Python Binance 0.2.0 Websockets Documentation
Install Python 3.9:
This is easiest on Windows, as no system processes rely on it. If you install it parallel to your current version, you'll have to take extra steps to address it rather than the later version, such as with PATH edits or virtual environments. An easy tool for this is Anaconda, which can create the virtual environment with little fuss.
I run my trader on a PC running Fedora, which has proven to be more reliable with server connections (unfortunately, Windows 11 can't keep proper time without a looping PowerShell script that manually resyncs, and I get Windows semaphore errors even with the time issue fixed). However, Fedora relies on up-to-date Python for some system functions, so you have to install the pre-3.10 version beside it an create a symbolic link and a virtual environment to run it.
Modify the python-binance module to use a different Loop function, which I believe can be done with PyCharm or Anacondas, but from what I read it's not the best of ideas and I don't see a need for it at the moment. Also, I would probably just break it.
TypeError: As of 3.10, the *loop* parameter was removed from Queue() since it is no longer necessary
I was getting this error when i try to use proxybroker package.
I just downgrade python version to 3.6.8 and now error is gone.
Maybe your error to occurred by python version.
maybe helps
Make sure u installed asyncio and imported that. I had the same problem.
I'm packaging an application I have written into an AppImage so that it can be delivered to Linux users.
One of the key features of the GUI toolkit I'm using is that it is small and lightweight, allowing me to compile a build which is statically linked to the GUI library of around 6Mb.
However, after building the AppImage - where I do what the instructions say - use all the functionality (which basically includes only using file browser dialogues to load files) - it generates an absolutely enormous AppImage of around 200Mb!
I know that AppImages are supposed to be a "little bit" big, but this is completely mad as a proposed solution for portability when the natively compiled binary including a statically linked GUI toolkit is only 6Mb.
However, I'm not convinced at all that I need all of that 200Mb. A very similar piece of software to mine, but that additionally uses Qt (which is pretty bloated in comparison) is only about 30Mb. I actually suspect that appimage-builder is doing something very wrong - I think it is listing the files in the directory I explore when using the file browser dialogue as dependencies (they are big files). I have no real other explanation. But if so how do I stop it doing that?
Why is mine so big? What can I do about it?
For the record I am using this method for building my AppImage
Building my binary separately
Running appimage-builder --generate and completing the form
Running appimage-builder --recipe AppImageBuilder.yml --skip-tests
Edit: Removing the obviously not needed files that were being packaged have reduced the size of the appimage to just 140Mb, but this is still almost 5 times bigger than equivalent appimages I've seen. Are there some tricks/options I'm not aware of?
In few recent days got started with AppImage and faced the same problem.
Shortly: check dependencies of your app by any possible ways and configure recipe to include only concrete dependencies and avoid includings of any theme/icon/etc packages which are not realy used :)
My case is a small app, written in Dart (with Flutter). The built project itself weights about 22MB (du -sh . in output directory). My host os is Linux Mint (Cinnamon).
First time I run appimage-builder --generate it generated me the "recipe" with 17 packages to be installed and bunch of libraries to be copied from /lib/x86_64-linux-gnu/. When I generated AppImage from this recipe, result was about 105MB, which are extremely large in my opinion for small app.
My first experiments was to cleanup included files section, as I guess "all necessary" libraries should be installed from apt. I referred to a few configs from network where were marked only few libraries for include and was exclude section, which contains some DE related files (themes, fonts, icons and etc.)
Using that I got result about 50MB (which are still large enough).
Next experiments were referred to from this issue - https://github.com/AppImageCrafters/appimage-builder/issues/130#issuecomment-843288012
Shortly - after generating an AppImage file, there appeared file .bundle.yml file inside AppDir folder, which contains deployed libraries. Advice is to try exclude something from that. May be it's a good enough advice, but it takes too long time to check for each package/library if it breaks resulted AppImage file at least with official tests of appimage-builder (docker containers). I faced more broken results than any sane size reduction.
My next experiment was to reduce dependencies which should be installed from package manager and use files from host system. I deleted AppDir and appimage-builder-cache folders and regenerated the recipe. At next step I commented all packages which should be installed from package manager and leaved only included files. Result was fail, because of needing one package, but after adding it I got AppImage result in 36MB. That sounds much better than starting 105MB or even previous result of 50MB.
Here I got small "boost" - Flutter project built into AOT binaries, without runtime. So I checked output of ldd for my app, and then mapped list of required libraries to list of library files which were detected by appimage-builder. Finally some of them was correct, some not found in ldd output and some was in ldd output, but were not detected by appimage-builder. I added all undetected, removed all unused. My final result is 26MB and it passed all appimage-builder tests (running in docker images of fedora, cent, debian, ubuntu and arch)
I understand that it's bad enough for continuous building, because it will require to always check for used libraries and adapt config if something changed, but for rare enough builds I guess it's has some kind of balance between good and bad.
I am using Windows 10.
I downloaded setup-x86_64.exe from https://cygwin.com/install.html and am selecting the defaults (Install from Internet/Direct Connection/default locations).
I have tried several mirrors including cygwin.mirror.constant.com
I am accepting all the default packages plus some basic developer stuff (gdb, make) and check "Select required packages (RECOMMENDED)".
I get quite a way through the Cygwin Setup and then get the first of many pop-up messages "IO Error Opening file....._autorebase/binutils/cygwin/grep/mintty etc. Do you want to skip this package?"
If I skip the packages, I get a non-working Cygwin install (it can't find mintty). If I don't skip the packages, it hangs when the Cygwin installer hangs when it gets to the first of the problem packages.
Thanks in advance about what part of the setup process I am missing.
A bit late, but anyway: I have stumbled across the same problems yesterday when I tried to install Cygwin on Windows 10 the first time.
I have followed all advice given at various sites (including this one): Disabled antivirus software, followed the Cygwin FAQ, and so on, but to no avail.
Then I studied the setup log and found a line which told something about an address mismatch (sorry that I don't have the exact wording - I surely won't repeat the experiment ...). That lead me to the idea that it might something have to do with ASLR (a technique for hardening the system against malware).
The next step was to turn off ASLR via the UI of Windows Defender. After I had done that, I could install Cygwin without any problems. I have not yet tested if I actually could use Cygwin when I turn on ASLR again; I don't feel very comfortable when having turned it off completely.
The alternative would be to turn off ASLR per executable. This is also possible in Windows Defender's UI. But it could mean adding dozens of exceptions, depending on how many Cygwin packages you have installed.
The technical reason for the problem is how POSIX's fork() works. Basically, it clones the parent process's image, using the same offset addresses. But when ASLR is active, those offsets will change when cloning the process, which will make fork() fail. Since fork() is extensively used by Cygwin, it can't operate as intended when ASLR is active.
I want to run a program when my embedded Linux's desktop has started up, in the same way as Windows runs programs in the "Startup" folder. How can I do this?
Specifically, my target hardware is Beaglebone Black, the Debian variant (rev C board). The Window Manager is the default one.
In Linux these are called init scripts and usually sit in /etc/init.d. How they should be defined varies between different distros but today many use the Linux Standard Base (LSB) Init Script format.
Good readings on this:
https://wiki.debian.org/LSBInitScripts
https://www.debian-administration.org/article/28/Making_scripts_run_at_boot_time_with_Debian
There are multiple ways to start a program, it turns out. LXDE - the window manager - supports auto-start of .desktop files places in either ~/.config/autostart or /etc/xdg/autostart - hooray!
http://wiki.lxde.org/en/Autostart
Except... though I can run a simple program as proof-of-concept in this way, when I try to run mine, it fails. I can't figure out why. The file
.xsession-errors.old
contains X server errors ("resource temporarily unavailable").
I am now using another mechanism - running the code from a shell script (this is necessary because I need to specify a working directory for the program). This uses the "autostart" file in /etc/xdg/lxsession/, and at least it works. Well kind of. I either have to "sleep 5" before running, or prefixing the run with an # symbol which forces a retry if it fails. It looks a little like something my code is dependent on is not in place at the precise time the autostart mechanism finds it. I can find no way of ensuring startup order. This is plainly a crock of stinky stuff.
I am working on a MATLAB project which we want to export as .exe. The resulting file must then be able to run on both 32 and 64-bits Windows 7 PCs.
After a little research we realized this problem was easier to approach by developing on a 32-bit version of MATLAB building then a 32-bits .exe file.
Till this point, all our development was being carried in the 64-bits version of MATLAB. With it we had been able to successfully generate and run 64-bits .exe versions.
Now that we switched to MATLAB 32-bits, however, and we generate the .exe, something goes wrong and the following error is shown:
Undefined function ‘fmincon’ for input arguments of type ‘function handle’.
This is the line of code in which fmincon first appears:
Options = optimoptions('fmincon', 'DiffMinChange', 10);
A few remarks:
The same scripts which worked on MATLAB 64-bits also work on MATLAB
32-bits. Within the MATLAB environment, everything runs smoothly.
The scripts (with the same exact code) can still be made executable on MATLAB 64-bits without any problem.
In both cases, we properly installed the runtime required for the MATLAB executable to be run on the PC.
We have tried to run the 32-bits .exe in both 64-bits and 32-bits machines with the same result.
Is it possible that the 32-bits version of MATLAB's deployed executable has problems dealing with functions from the Optimization Toolbox (as fmincon is)?
What else could be the cause of this problem? Does anyone have an idea how to fix it?
The problem was only solved thanks to MATLAB's support. This is related to a bug in version R2014a, explained and patched in this Mathworks link.