I am trying to run my ruby on rails project with version 6 but it does not leave me, I updated it from version 5.2.3 to the most recent one and it sent me that error
This is happening because of an internal change in Rails https://github.com/rails/rails/pull/32065
Please check what gem are you using that is causing this error? Gems like rspec-rails, haml-rails have released updated versions which fix this issue. Rails codebase will also get a fix for this based on this comment: https://github.com/rails/rails/issues/36313#issuecomment-496842892
Related
I have updated mac to 11.6 and xcode to 13.0. Realm could not compile so I updated it with carthage to v10.15.1. Now I get this runtime error just after the app launch:
Library not loaded: #rpath/Realm.framework/Realm
Referenced from: /Users/username/Library/Developer/Xcode/DerivedData/appname/Build/Products/Debug-iphonesimulator/RealmSwift.framework/RealmSwift
Reason: tried: '/Users/username/Library/Developer/Xcode/DerivedData/appname/Build/Products/Debug-iphonesimulator/Realm.framework/Realm' (file does not start with MH_MAGIC[_64], file does not start with MH_MAGIC[_64], fat file, but missing compatible architecture (have 'x86_64,i386', need 'x86_64')), '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/Realm.framework/Realm' (no such file), '/usr/lib/swift/Realm.framework/Realm' (no such file), '/Users/username/Library/Developer/CoreSimulator/Devices/33E61712-D8A9-4D7E-A260-5C096BE08A82/data/Containers/Bundle/Application/AC700919-F431-446F-8BEF-FF8D8E5F5BF9/appname.a
I guess the key part here is file does not start with MH_MAGIC[_64], but I could not find anything useful about the error.
I tried embedding the library and turning off the embedding, does not affect anything.
Realm has 3 targets configured to be built with Carthage (Realm, Realm iOS Static and RealmSwift)
XCode 13 deprecated a setting for building targets in a manually set order which leads the first 2 targets to be built in a non deterministic order (the 3rd one is always last as it depends on the 1st one). The order and the frequency of it changing seems to be random (it might depend on the specific XCode version)
When 'Realm' is build before 'Realm iOS Static', the fat framework replaces the one in the xcframework which leads to that error. In the other case, it's the correct one that's built second and overrides the wrong one.
I guess the solution (apart from upgrading Realm) would be to remove the target 'Realm iOS Static' from the project but it's not straightforward to do with Carthage except by forking Realm
The latest version of realm is v10.32.0. xcode 14.1 is also out.
You need to update your toolset.
The latest upgrade realm version 10.32.0 is compatible with XCode 13.1 and above. If you use the legacy build system, migrate it to the latest one and clean the derivable folder before rebuilding the code. Most of the time derivable keeps track of the older version files and makes conflicts once you update the project tools. Hope this will help
I upgraded to Rails 6.1, which broke my Cloudinary.
Whenever I go to an instance that has a photo attached, I now get this:
undefined method `service_name' for #<ActiveStorage::Blob:0x00007fb4b1c6de88>
Did you mean? service
Any idea how to fix it?
Running rails active_storage:update solved my problem.
I had already run rails app:update, which created the following migration: AddForeignKeyConstraintToActiveStorageAttachmentsForBlobId
But after running rails active_storage:update I got two extra migrations:
AddServiceNameToActiveStorageBlobs & CreateActiveStorageVariantRecords.
I think this is similar to the issue in another SO topic.
The accepted answer was to run
rails active_storage:update
rails db:migrate
Today, my Android build failed in the ProGuard optimization phase with a weird java.lang.ArrayIndexOutOfBoundsException error message.
Since my last successful build I hardly changed a thing. I tracked the problem to the version of the com.google.firebase:firebase-messaging api. Version 17.3.3 still works fine, version 17.3.4 is problematic.
I don't know if it is related, but note that the api com.google.firebase:firebase-core is not part of my project.
The issue seems fixed when using grade plugin 3.3 or later
When I try to add a web-service-client from a WSDL, I get an error, and to get past this error I have to delete a file called "javax.xml.soap_1.3.0.v201105210645" from the 'plugins' folder.
Here's an original post:
http://forum.spring.io/forum/spring-projects/springsource-tool-suite/91609-sts-2-5-1-java-io-filenotfoundexception-lib-saaj-jar
Isn't there a way to fix this permanently?
I tried this again with the latest STS 3.6.3 version and it seems to work just fine. The Eclipse bug at https://bugs.eclipse.org/bugs/show_bug.cgi?id=364026 is fixed since quite some time. Please make sure you are using STS on top of the latest Eclipse 4.4 release. The bug in Eclipse Webtools got fixed for Eclipse Luna (4.2), so if you are running STS 3.6.3 on an older Eclipse version, this bug is still there, I would guess. Hope this helps!
After upgrading the Flex SDK from 3.1 to any newer version of the SDK and trying to compile an existing project, the following error appears in the Problems pane:
Description: { expected
Resource: (shows project name, not a specific file)
Location: line 15
Any ideas how to solve this or where to start the bug hunt?
It looks like the problem is in the ...sdks/3.3.0/frameworks/libs/player/10/playerglobal.swc file, but I'm certainly not sure.
I've had this happen (among others). Never got to the bottom of it. In the end I migrated my code files to a new project. There are some pretty nasty bugs in FlexBuilder, especially when working on 64bit windows.
Have you tried to do a clean on the project? You didn't mention this but I assume that the project compiles fine under 3.1? If you create a new project does it compile cleanly (if not, it may mean that you have a bad download of the SDK and need to get a new copy.)
The problem was solved by removing halo.swc from libraries. Copying halo.swc to the project was suggested by an online tutorial (which I cannot find right now).