It seems your latest release version 1.8.5, albeit a maintenance release, is forcing exceptions on undefined options. The group and map operators don't work on undefined objects any longer.
Can you let me know if this is intentional?
If so, can you let me know if any simple null checks have been implemented, rather using coalescing operator?
Thank you.
Related
When I build u-boot-spl for our board, I see these link errors. (u-boot version v2021.10, commit 50c84208ad, Tom Rini, Oct 4 2021)
u-boot/common/spl/spl.c:669: undefined reference to `memcpy'
u-boot/common/spl/spl.c:684: undefined reference to `mem_malloc_init'
...
But arch/arm/Kconfig says (my board is ARM64)
config USE_ARCH_MEMCPY
bool "Use an assembly optimized implementation of memcpy"
default y if !ARM64
depends on !ARM64 || (ARM64 && (GCC_VERSION >= 90400))
help
Enable the generation of an optimized version of memcpy.
Such an implementation may be faster under some conditions
but may increase the binary size.
So if ARM64 and GCC version is later then 9.04, USE_ARCH_MEMCPY should be turned on.
And in my case, I can check in include/config/auto.conf the two condition is true.
CONFIG_ARM64=y
CONFIG_GCC_VERSION=100201
But USE_ARCH_MEMCPY doesn't appare in include/cofig/auto.conf (is this normal?).
Anyway, I think this CONFIG_USE_ARCH_MEMCPY should be y. Why does it give me this memcpy undefined error?
I checked in lib/Makefile, I see
obj-y += string.o
which is unconditional and this string.c contains memcpy function. But of course this function is enclosed by #ifndef __HAVE_ARCH_MEMCPY, so it's not what I want anyway.
Is there any option I should turn on to make use of this hardware assisted memcpy?
ADD : I tried adding CONFIG_LTO but it didn't work.
I searched the Kconfig files and found there are CONFIG_USE_ARCH_MEMCPY, CONFIG_SPL_USE_ARCH_MEMCPY, CONFIG_USE_ARCH_MEMSET, CONFIG_SPL_USE_ARCH_MEMSET, etc. So I made those configs to be selected for my board. And those errors are gone (with CONFIG_LTO-link time optimization is set so that stdlib is not used). I still have some more 'undefined' errors for strncmp, timer_init, puts, hang, mem_malloc_init etc. I'm not sure I can fix the errors using similar methods or this approach is the correct, advisable method. And if I prefer software routine, what should I do?
Waiting for a better answer.
ADD (2021. 11. 29) :
Ovidiu Panait from u-boot email list told me I can remove some 'undefined symbol' error by setting CONFIG_SPL_LIBGENERIC_SUPPORT and CONFIG_SPL_LIBCOMMON_SUPPORT to 'y'. After setting this I found those memcpy, memset link errors are also gone without setting USE_ARCH_xxx or USE_SPL_ARCH_xxx configs.
I am upgrading a repository from Ruby version 2.3.3 to 2.5.1. A test is failing, and I have narrowed down the cause to the following behaviour:
In version 2.3.3
1.34875.round(4)
=> 1.3487
In version 2.5.1
1.34875.round(4)
=> 1.3488
Now, I'm aware of this change, but I don't think it's relevant because a) the default behaviour was left alone, and b) the observed change is opposite to the proposed change in the default. I'm also aware that floating point numbers are not a good way to accurately store finite decimals, and that some change in precision might explain why this change has occurred. But I don't know, and I don't know how to find out.
The behaviour you're describing sounds like https://bugs.ruby-lang.org/issues/13138, which was considered a bugfix and backported to 2.3.5. (I haven't confirmed which 2.4.x it was backported to, if any, but it was in trunk before 2.5.0.)
As you surmised, it is a precision issue. 1.34875's float representation is slightly less than 1.34875, so 2.3.3 does the overly-technically-correct thing and rounds down; newer versions recognise that rounding up is more consistent given that the float actually represents a range of values [including 1.34875].
The default behavior was not "left alone" as you suggest. There's new strategy to round to nearest even number: https://github.com/ruby/ruby/blob/8d7c380216809ba5bd4a3eec41d7dda61f825ffa/NEWS#core-classes-updates-outstanding-ones-only (search for round).
You can use
> 1.34875.round(4, half: :down)
=> 1.3487
To preserve what seems to be the behavior in 2.3.3.
We recently ran into a bug in our code where someone had used .equals() to compare enums. One of the fields had been changed to a different enum - but we got no compiler error due to the use of .equals() instead of ==.
Can you look at this specification and tell if this is matching the problem you want to catch? (assuming you are talking about Java)
https://jira.sonarsource.com/browse/RSPEC-4551
I've just gone back to a project I started ages ago and the compiler is throwing out hundreds of errors about objects not being convertible (to objects which subclass them), and suggesting I use as! instead of as, to force the cast.
Is this a bug in the latest X-Code beta, or has the down-casting syntax changed?
The syntax has changed for Swift 1.2. See Apple's blog post about it.
Here's a summary from their article:
Swift 1.2 separates the notions of guaranteed conversion and forced
conversion into two distinct operators. Guaranteed conversion is still
performed with the as operator, but forced conversion now uses the as!
operator. The ! is meant to indicate that the conversion may fail.
This way, you know at a glance which conversions may cause the program
to crash.
Most of the code I write is in Ruby, and every once in a while, I make some typo which only gets caught after a while. This is irritating when I have my scripts running long tasks, and return to find I had a typo.
Is there an actively developed lint tool for Ruby that could help me overcome this? Would it be possible to use it across a system that works with a lot of source files, some of them loaded dynamically?
Take this snippet as an example:
a = 20
b = 30
puts c
To win bounty, show me a tool that will detect the c variable as not created/undefined.
ruby -c myfile.rb will check for correct Ruby syntax.
Reek checks Ruby code for common code smells.
Roodi checks Ruby code for common object-oriented design issues.
Flog can warn you about unusually complex code.
[Plug] If your project is in a public Github repository, Caliper can run the latter three tools and others on your code every time you commit. (Disclaimer: I work on Caliper)
You could give Diamondback Ruby a try. It does a static typecheck of Ruby code, and will thus blame you for using an undefined variable.
While DRuby is an ongoing research project, it already works quite well for small, self-contained Ruby scripts. Currently, it is unable to analyze much of the Ruby standard library “out-of-the-box”. Currently they are working toward typing Ruby on Rails (see their most recent papers).
RubyMine (http://www.jetbrains.com/ruby) does the trick:
alt text http://img707.imageshack.us/img707/5688/31911448.png
None of the below will do all the analysis that RubyMine does.
NetBeans Ruby pack
Aptana RadRails
gVIM (with syntastic plugin by scrooloose)
Each of these has the capacity to identify syntax errors such as wrong number of parentheses, too many defs, ends, braces, etc. But none will identify invalid method calls the way RubyMine does.
Here's why: it's difficult.
Since Ruby is extremely dynamic (and methods like 'c' could easily be generated on the fly), any editor that tries to identify non-existent variables/methods would need to have a large part of the entire evironment loaded and multiple program flow paths constantly tested in order to get accurate 'validity' results. This is much more difficult than in Java where almost all programming is static (at least it was when I dropped that hat).
This ability to easily generate methods on the fly is one of the reasons the community holds testing to such high esteem. I really do reccomend you try testing as well.
Have a look at RuboCop. It is a Ruby code style checker based on the Ruby Style Guide. It's maintained pretty actively and supports all major Ruby implementations. It works well with Ruby 1.9 and 2.0 and has great Emacs integration.
Yes. Test::Unit
Ok, I know you already know this and that in some sense this is a non-helpful answer, but you do bring up the negative consequence of duck typing, that there kind of is (at this time) no way around just writing more tests than something like Java might need.
So, for the record, see Test::Unit in the Ruby Standard Library or one of the other test frameworks.
Having unit tests that you can run and rerun is the best way to catch errors, and you do need more of them (tests, not errors :-) in dynamic languages like Ruby...
nitpick might be what you're lookng for.
With this code:
class MyString < String
def awesome
self.gsub("e", "3").gsub("l", "1").uppercase
end
end
puts MyString.new("leet").awesome
... it outputs:
$ nitpick misspelling.rb
*** Nitpick had trouble loading "misspelling.rb":
NoMethodError undefined method `uppercase' for "133t":MyString
Nothing to report boss! He's clean!
Have not used it yet, but sounds promising (will update when I've tested this).
https://github.com/michaeledgar/laser
Static analysis and style linter for Ruby code.
Pelusa is nice, but is working in rubinius only. This shouln't be a proplem for people familar with RVM though.
avdi#lazarus:~$ irb
>> a = 20
=> 20
>> b = 30
=> 30
>> puts c
NameError: undefined local variable or method `c' for main:Object
from (irb):3
>>
There ya go, the tool is called "IRB". Do I get the bounty?
I'm only half joking. I wrote this second answer to hopefully drive home the point that in Ruby, if you want to know that something is defined or not, you have to run the code.