I have a class/model called AdditionalTime and ran the migration for creating it in the DB, however I can't create instances of AdditionalTime objects.
I get this NameError: uninitialized constant AdditionalTime whenever I try.
I initially discovered the problem when I tried to have another model's method create some of these objects, but I got the same error when testing it on the console. I can create instance of my other models, just not AdditionalTime.
What might cause this to happen?
Edit: I'm using rails 4 and ruby 1.9.3
Thanks!
Related
In a rails app using sorbet, when you have a method that expects an instance of a type, say Foo. And you need to initialize an instance of Foo in an initializer for the app that persists in memory between requests. And then you make any change to the source code of Foo or any file that Foo uses. Then sorbet believes that this instance is no longer an instance of Foo, and you need to restart your app in order for it to stop erroring.
This seems like a rare case, but in our app, we use a bit of dependency injection, and it's a large team. So sorbet is making us restart our app almost every time we do a git update, and many, many times throughout the day as we write code. We have a large app which takes a while to restart, and it's quite frustrating to have to do this.
Any ideas on how to fix this? If helpful, I could make a sample rails app to demonstrate this behavior.
I ran into a similar issue myself when I was referencing a model in a Rails initializer. I was advised that there are 2 solutions:
Refactor the code so that you don't have this issue
Add checked(:tests) or checked(:never) to the sigs of methods that are having this problem. This would preserve the runtime and test time checks, but eliminate the errors in development. See the link below for documentation
https://sorbet.org/docs/runtime#checked-whether-to-check-in-the-first-place
I'm new to PLC programming and we need to create a library for a project. We need dynamically created function block instances during the runtime. There is a concept described on the codesys homepage:
https://help.codesys.com/webapp/fb_factory;product=LibDevSummary;version=3.5.15.0
We tried to implement the example but without success. Unfortunately, there is no further information about the concept on the codesys homepage.
Has anybody some advice how to dynamically create fb instances during the runtime on a plc?
When you want to create an instance of an FB dynamically you need first to put the following attribute above the FB-Declaration:
{attribute 'enable_dynamic_creation'}
Then you must make sure you are not calling __NEW(FB_NAME) cyclically.
Then you assign the result of __NEW(FB_NAME) to a pointer:
//Put this is the declaration section
pfbName : POINTER TO FB_NAME;
//Your call to create a dynamic instance
pfbName := __NEW(FB_NAME);
If your pointer = 0 after __NEW returns, it means __NEW failed to allocate memory.
I made a simple classic OOP Person, Teacher, Student example here.
Basically, changing the value of numberOfTeachers inside PLC_PRG will cause the reinitializarion of the array people with the first numberOfTeachers entries being Teachers, and the rest being Students. You can look at the Device Logs where I write messages for creation/destruction of Teacher/Studemt.
PS. I am myself still exploring the possibilities of the Factory Design in CODESYS, so excuse me if I made any mistakes!
I am adding Kotlin native linuxX64 target support to some existing library. Library is compiled successfuly but while running the test cases, I am getting following runtime error:
kotlin.native.concurrent.InvalidMutabilityException: mutation attempt of frozen kotlin.Array#1249428
at kfun:kotlin.Exception.<init>(kotlin.String?)kotlin.Exception (0x271205)
at kfun:kotlin.RuntimeException.<init>(kotlin.String?)kotlin.RuntimeException (0x2711c5)
at kfun:kotlin.native.concurrent.InvalidMutabilityException.<init>(kotlin.String)kotlin.native.concurrent.InvalidMutabilityException (0x272595)
at ThrowInvalidMutabilityException (0x3b0b53)
at (0x3b5733)
Even the Object example given in Kotlin language tutorial is not working on giving the similar runtime exception.
I know the problem is due to the frozen objects. But I could not find the proper way to modify the frozen members of singleton object.
After searching a bit I got the answer. We can update the frozen object using the Atomic Reference.
I've just upgraded from Rails 5.0.0 to 5.1.1 and started getting a ton of deprecation warnings like this:
DEPRECATION WARNING: The behavior of changed_attributes inside of
after callbacks will be changing in the next version of Rails. The new
return value will reflect the behavior of calling the method after
save returned (e.g. the opposite of what it returns now). To
maintain the current behavior, use
saved_changes.transform_values(&:first) instead.
and this:
DEPRECATION WARNING: The behavior of attribute_changed? inside of
after callbacks will be changing in the next version of Rails. The new
return value will reflect the behavior of calling the method after
save returned (e.g. the opposite of what it returns now). To
maintain the current behavior, use saved_change_to_attribute?
instead.
I don't use those methods explicitely anywhere in my project and the warnings are pointing mostly at create and update calls on my models.
I believe it has something to do with my validations and after_update and after_create callbacks where I use confitions like if: { author_id_changed? } but I have no idea what to do with them.
I also believe the warning is related to this massive update to ActiveRecord.
Would appreciate any hand you can give with this.
UPD
This article helped alot!
Well, got around everything by running bundle update and updating the gems and also following this article and changing attribute_changed? calls in after_ callbacks (but not in before_ callbacks and validations) and switching from attribute_was to attribute_before_last_save.
For After callbacks, you can use saved_change_to_attribute?
For Before callbacks and validations, you can use will_save_change_to_attribute?
I hope this information will help!
I've done an upgrade to Rails 5.1.6 and have the same DEPRECATION warnings. If ever anyone still wants to solve this warning. Here are the steps I took:
Search all of your*_changed?
Changed this:
if name_changed?
...
if user_id_changed?
To this if it is inside after_* (after_save, after_commit, after_update, etc.) blocks:
if saved_change_to_name?
...
if saved_change_to_user_id?
AND to this if it is inside before_* (before_save, before_commit, before_update, etc.) blocks:
if will_save_change_to_name?
...
if will_save_change_to_user_id?
On my own opinion, this is quite tricky thing to change since we've been used to attribute_changed?. But change is good. The syntax also made more sense now.
You can change author_id_changed? to saved_change_to_author_id?
I had both namespaced controllers and models like this:
controller: Modules::Insurances
model: Modules::Insurances
This worked fine, but I want to remove the namespaced model back to normal, but keep the namespaced controller. I have removed all the references to "Modules::" in the models and also in all the activerecord queries in the controller to the model. When I visit the page, it returns this error:
Expected /***/app/models/modules/ins_insurance.rb to define Modules::InsInsurance
What should I do more to remove the namespaced model?
The root cause of the error is that rails is expecting the name of the class declared inside the file modules/ins_insurance.rb to be Modules::InsInsurance -- the filename must match the class name (after a little conversion thanks to the Inflector's underscore and classify methods: http://apidock.com/rails/ActiveSupport/Inflector/underscore). So name the file back to insurance.rb and you should be OK.
On a broader topic, I can only think you'll run into problems sooner or later by using a sub-directory called modules -- at the very least it's confusing between the Ruby keyword Module. If you're looking for a place to put general purpose code, use app/lib then require the file as needed. Namespacing is a fine thing to do, but you'll end up fighting with Rails unless you go with the flow. (Lesson learned the hard way ;-)