Im trying to translate my chrome app to ios. I run the command cca create myapp --copy-from=manifest.json Some errors exist cp: copyFileSync: could not write to dest file (code=ENAMETOOLONG): $PATH_TO_PROJECT/project/platforms/ios/www/platform/..../www/platform/config.xml
where .... is 40 repeated directories of /www/platform
The translation succeeds and im able to run my project with android however, when trying to run in xcode i see an almost identical error saying File name too long.
Anyone have simmilar issues? Anyone able to get ios translations to run?
This is the result of a bug in the way we "import" your project when you specify --copy-from or --link-to arguments to cca create when your import directory is the same as your output directory.
Since the import in your example is a parent folder of the output, it copies itself over and over, recursively until the system kills the process. We have added protection against doing this (by warning during cca create if we detect this case), but that version hasn't released to npm just yet (sorry!).
The fix for the issue is simple: just create your project in another directory that is outside of your packaged app! i.e., either:
# From within packaged app directory
cca create ../myapp --copy-from=./manifest.json
or
# From outside packaged app directory
cca create myapp --copy-from=$APP_DIR/manifest.json
Related
For years I've been running a Docker container on my local machine and using it as a remote Python interpreter via SSH in PyCharm. This works great (though 2022.2.1 brought a lot of new bugs that have been slowly being ironed out) for running my code! I'm now on 2022.2.3.
However, I'm having issues running unit tests. In the past (i.e. before version 2022.2.1), I could simply right click my tests directory (a direct child of my main project directory) and click Run Python tests in test... and it would all work as expected.
Now, though, when I click this, I receive an error message about "No such file or directory."
I've tried everything I can think of- I've setup my path mappings in the Python test run config to exactly match those shown in my Python run config, and have tried every version of directory and subdirectory in the mappings and working directory, but I always receive an error about either having an empty test suite (no tests found), or that the directory "must be in the project."
It seems like no matter what I do, PyCharm is trying to create a temp directory somewhere, or is trying to read from some temp directory that I never specified, because I see errors this like:
AssertionError: /tmp/pycharm_project_405/docker/tests: No such file or directory
Yet I never created, specified, or requested a temp directory of any sort, let alone one named /tmp/pycharm_project_405/; this is a mystery to me.
PyCharm with an SSH interpreter is rapidly becoming unusable for me and my team because we cannot figure out how to set this up. Can anybody please offer some guidance on what we need to do?
Thank you all so very much!
I tried:
Changing run config for Python tests to match the working directory and path mapping of Python run configs (which work)
Directly specifying the path to the tests from the container's perspective
Setting up run config templates
Specifying one directory up/down from the actual tests
Expected:
Unit tests to be found and run as they were in previous versions of PyCharm
Answer
Create a run config for testing
In the testing run config, set Target: to Custom
Set the correct remote interpreter
Set Working directory to the test folder
Set TWO path mappings: 1) Map the code directory (in my case, the parent directory of the tests folder) and 2) Map the test directory itself
Voila!!!
I have an iOS app with a Build phase script that reads a plist file using the following command:
defaults read "/full/path/to/plist/file" CFBundleExecutable
...but it fails with the following error message:
The domain/default pair of (/full/path/to/plist/file.plist, CFBundleExecutable) does not exist
The full path of the file is correct and I double checked that the file indeed contains the key CFBundleExecutable. I also tried with other keys such as CFBundleName. Running the command both with and without .plist at the end of the full path fails.
I also ran the command in Terminal to see if it works generally, but the command fails there as well.
It turns out that macOS (or the defaults command line tool) seems to have a bug. Folders that are "special" such as Documents and Desktop act differently within the command line environment and as such I observed the following:
If Info.plist is located in a subfolder of Desktop or Documents the defaults read command will fail
As soon as you place Info.plist in any other folder (such as a Developer folder) the same defaults read command will succeed
I am not sure if this is due to the fact that both of these folders require special permissions (macOS asks if an app requests access to either of these) or if it is because they are part of iCloud Drive and perhaps there is some weird symlinking in the background.
Either way, if you run into a similar error, just try to place your project in a subfolder of ~/Developer (or any other non-default, non-special folder).
I use the command cordova serve to test the app in browser. But when I issue the command, I find all the code changes I made to the app has been disappeared include newly added js files etc. The app just got a complete reset. How can I avoid this and still use cordova serve command to test in browser? Thanks.
I got the issue resolved. It took sometime to figure out what is happening under the hood. As I was making changes directly in platform IOS directory, the cordova prepare or serve statement just replaces the code from the parent www folder.
To conclude, I have to make changes in root www folder and then issue the prepare/serve command that copies the code to the platform to test it out.
I'm currently building an app for jailbroken device, and I need root privileges for my app so that I can perform some tasks ask root. I found a related question : Gaining root permissions on iOS for NSFileManager (Jailbreak). But I am really new to iOS, I don't understand and unable to complete task from step 4. Can anyone make it more detail please?
What step 4 is telling you:
Open the original executable file and delete its contents (the contents are now stored in the previously copied and renamed binary).
is simply that you have moved the executable file for your app to a new filename, and you should replace it with a script with the name of the original executable.
Example
If you build an app named HelloWorld, Xcode will create a HelloWorld.app directory, with a file named HelloWorld inside it, which is executable.
The answer you link to suggests basically renaming the executable to something like MobileHelloWorld.
Once you've done that, create a new file in the HelloWorld.app directory called HelloWorld, and edit it with a text editor to give it this content:
#!/bin/bash
dir=$(dirname "$0")
exec "${dir}"/MobileHelloWorld "$#"
That script will then be run when you tap the app's icon, because in the app's Info.plist file, the name of the executable is
<key>CFBundleExecutable</key>
<string>HelloWorld</string>
and HelloWorld is now a shell script, which invokes MobileHelloWorld, the renamed binary executable file.
I'd like to know if there is any way to develop continuously with Trigger.io and avoid the forge build step with every file change I want to test in my browser or simulator.
I was faced with the same problem and I've got a working solution that uses watchr and watch to automatically rebuild each time I make a change to a source file. If you are running a "web" version of your app you can make a change to a source file and go directly to your browser and see the effect of your changes fairly quickly depending on how long the build takes.
Prerequisites: Ruby, watchr, Unix 'watch', and a terminal.
gem install watchr.
create a new ruby file for watchr to know what files to monitor and what to do when it sees a change. I named my file 'my_watch.rb': https://gist.github.com/3153167
open two terminals. Terminal 1 will run watchr and Terminal two will run 'forge build ...'.
In terminal 1 run 'watchr my_watch.rb' making sure the path to my_watch.rb is correct and make sure you've edited my_watch.rb according to your setup so that the path inside watch(...) reflects the files to be watched. My example watches all files in the same directory (and beneath) as the my_watch.rb script. You can place my_watch.rb in the 'src' folder of your Trigger.io app if you want to match my example and run watchr my_watch.rb directly from the src folder. Also not the shell command and path in the block need to be updated to reflect your environment. Again, in my example 'my_watch.rb' is inside 'src/' so when a change is detected we go up one directory and call 'forge build'.
I tend to develop actively with the 'web' version of my app so I can just open terminal 2 to my forge project directory and 'forge run web'. When I am testing in simulators and on devices, yes I have to run forge build every time I want to see a change. However, I typically don't have to wait for forge build to finish because watchr kicked off the build as soon as I made a change and it happens pretty quickly.
I know this is not an ideal solution but so far developing new features in the 'web' version first and then implementing in mobile versions has been very smooth for me. I've never needed to kill the 'web' version after a build but I maybe just lucky. As for running build each time you want to test the mobile versions if you are good with your keyboard shortcuts it really isn't bad at all. XCode makes you build and run after changes are made to source code when creating native iOS apps so I don't think Trigger is unique in requiring this build step.
I hope this helps and that my answer isn't too specific to me and my setup.
The build phase makes some changes to your source to enable the forge.* APIs - therefore, trying to just use the raw files in your src directory won't work.
You may be tempted to change files directly in the development directory, but this is a pretty bad idea: we delete those files with impunity when we need to!
We have plans on our medium-term roadmap to add a file-system watcher to start builds automatically when changes have occurred.
In the meantime, I just use forge build && forge run PLATFORM which tends to only take a few seconds...
while not perfect... this works for me.
go into development/web
rm src
link to your root src, ie ln -s ../../src src
copy the all.js from the web/forge and add to your index.html
ie
start nodemon web.js
open in browser.
note you will need to comment out the all.js script tag for non web builds.