Am looking at rubocop but want to start with warnings and errors - we'll get to convention-related alerts later. My question is: how do I invoke rubocop where it will ignore convention-related alerts and only report on Warning, error & fatal messages.
Thanks
Michael.
Guess you need to disable them one by one. Generally speaking, I'd suggest enforce all the rules.
For your convenience, here is my .rubocop.yml I frequently used. This should suppress many non-critical warnings.
AllCops:
Excludes:
- Berksfile
- recipes/basic.rb
- attributes/*.rb
# Customize rules
Metrics/LineLength:
Max: 95
MethodLength:
Max: 35
Metrics/AbcSize:
Enabled: false
BlockLength:
Max: 70
I constantly bump by rubocop errors and warning. Thus I've published this post.
Common Rubocop Errors: Improve Your Ruby Code Quality
rubocop --only Syntax,Lint
From https://github.com/bbatsov/rubocop/issues/2337#issuecomment-150477553
If you don't have any custom severity levels in your configuration, it's quite simple. The Synax cop reports on fatal and error level, Lint cops on warning level and all other cops on convention level.
So for only fatal and error, it's rubocop --only Syntax (which is only supported on master, not released yet), and for warningand above it's rubocop --only Lint.
Related
Error:
The style compilation failed, see the error below. Your recent actions may be the cause, please try reverting the changes you made.
Could not get content for /web_dialog_size/static/src/css/web_dialog_size.css defined in bundle 'web.assets_backend'.
When you get given error then follow the below steps:
Apps -> web_dialog_size -> uninstall module
If you need this module then again install it
I just changed two lines of code in the Google cloud functions source code using inline statement, the two lines of code involve parsing date string using datetime library, no updates to anything else. This same deployment has been working for more than a year now.
All of a sudden I get two errors -
Error 1 -
(gcloud.functions.deploy) OperationError: code=3, message=Build
failed: {"error": {"canonicalCode": "INTERNAL", "errorMessage":
"pip_install_from_wheels had stderr
output:\n/opt/python3.7/bin/python3.7: No module named pip\n\nerror:
pip_install_from_wheels returned code: 1", "errorType":
"InternalError", "errorId": "ECB5F712"}}
Resolved that by removing pip from requirements.txt (again not sure why this is a problem now and not for over a year)
If I address 1, I get the following error -
Error 2 -
(gcloud.functions.deploy) OperationError: code=3, message=Build
failed: {"error": {"canonicalCode": "INTERNAL", "errorMessage":
"gzip_tar_runtime_package gzip /tmp/tmpGLHQx9.tar -1\nexited with
error [Errno 12] Cannot allocate memory\ngzip_tar_runtime_package is
likely not on the path", "errorType": "InternalError", "errorId":
"2A1581FF"}}
Memory is already at 2048 and nothing changed other than the two lines of code above.
Let me know if this has been happening and what is the resolution.
It looks like this has to do with packages than anything else. I deployed a dummy function and added each package from requirements.txt until it failed. It turns out the problem packages were
a. gpflow
b. tensorflow
Last deployment with these packages was successful as of Feb 20. Not sure why I can't install them without those errors anymore. regardless, tried using the versions that would have been consistent with Feb 20 timeline with no luck. So refactored my code and removed all the functionality that was using that and deployed successfully.
Request to Google Cloud Folks : Why this behavior ? Also "Invalid ARGUMENT" in logs (Stackdriver or google cloud logging whatever you call it) is misleading.
The first error, as explained in this post, is due to pip being defined in your requirements.txt file. Specifying pip as a dependency for the function causes message to appear. You did the right thing by removing it from the requirements.txt file.
The second error usually appears if the number of files or the size of the content that is being uploaded is too big and the instance used to deploy your code runs out of memory. You perhaps were using too many dependencies or static files, as explained here.
I compiled the sourceforge tcl executable, it passes all the tests supplied, and it runs with the same segfault I see in my downloaded executable, 8.6.9. I'm running on Ubuntu 16.04 (for legacy reasons) on an AMD processor. ( I have run on ubuntu 18.04 on my laptop, it has the same failure. )
So, next I recompiled with "--enable-symbols=mem" turned on to see if a memory leak is causing the segfault, and now it fails immediately with:
Trying to decr ref count of Tcl_Obj allocated in another thread
./runMeg.sh: line 3: 29972 Aborted (core dumped) ../source/main_megatron.
I'm not seeing any answer on what to do with this response, can someone advise on what this means I need to fix?
All my threads are of the form:
set graphDisplayThread [ thread::create {
after [expr {int(1000) }]
.....
puts "...Initialized graphDisplayUpdate_02 ID $c update."
thread::wait
}]
and:
thread::send $::graphDisplayThread {
incr b
graphDisplayUpdate .c
}
All shared variables are referenced AFTER mutex is captured, and through TSV variables. There are 5 threads in the application, which has no C-code in it at all. Around 2000 lines of code, in total.
The app runs thousands of cycles and then segfaults at random points with a prior ActiveState 8.6.9 pre-compiled version. So, now I'm trying to isolate the failure point with compiled SourceForge 8.6.9 memory checks as a first step, but the issue above is the first one I encounter - and it occurs immediately after starting.
Update (5/16/19 8:28 EST): New Detail to answer comments below.... This application has no C-code in it, and the Tcl_Obj error ONLY appears in the sourceForge-based, 8.6.9 compiles (2) I did myself, not the ActiveState 8.6.9 pre-built download. And the error in the sourceForge code occurs in both the twin "MEM_DEBUG" and NO-"MEM_DEBUG" builds I made in tandem and tested. Both passed all install tests.
To summarize:
sourceForge 8.6.9 compile w/MEM_DEBUG option: Tcl_Obj Abort error
sourceForge 8.6.9 compile w/o MEM_DEBUG option: Tcl_Obj Abort error
ActiveState 8.6.9 build: does not Abort, random seg fault
Why should I trust the sourceForge build I made myself, more than the ActiveState pre-built executable which does not exhibit the problem? And if we do trust the sourceForge compiled version, how do I isolate where the TclObject error is created by the offending TCL code?
Update 5/16/19#13:34EST: The same segfault appears with ActiveState 8.6.9 on Ubuntu 18.04. Haven't checked my builds of SourceForge yet to see how they behave.
By methodically hacking out code blocks and watching to see if the Tcl_Obj error dissappeared or not, I found 2 errors:
I had re-declared my mutex and cond variables more than once. Now it is declared once and referenced in all other places.
A code remnant removing a TSV was found in a place I no longer wanted it.
This also fixed the segfault.
Thanks for all the help and hints, mrcalvin.
I'm trying to install insoshi on my linux OS. However, I continue to get this error message that prevents me from installing it:
LoadError: cannot load such file -- rake/rdoctask
/home/james/insoshi/Rakefile:8:in `<top (required)>'
How do I fix this error in order to install this application?
Here's part of the Rakefile throwing that error:
# inoshi/Rakefile
require 'rake'
require 'rake/testtask'
require 'rake/rdoctask'
According to this answer:
ERROR: 'rake/rdoctask' is obsolete and no longer supported. Use 'rdoc/task' (available in RDoc 2.4.2+) instead
'rake/rdoctask' is deprecated; try 'rdoc/task'.
FWIW, that project (https://github.com/insoshi/insoshi) has not been updated in six years. Just a suggestion that you might want to consider another tool. There may be a lot of error messages like this ahead.
I'm migrating my WebAPP from Smarty2 to Smarty3. Every step is easy except one. When i display a Smarty Template ( tpl ) an Exception is thrown.
This line
Source: /path_to_file/smarty/libs/sysplugins/smarty_resource.php (773)
(this is the source coude $compiled->timestamp = #filemtime($compiled->filepath); )
raise this Exception when the file doesn't exists
filemtime() [function.filemtime]: stat failed for /path_to_templates/smarty/templates_c/219dfe732aae7bd7c0edab091e3c53f3ce86b058.file.index.tpl.php
Folder permissions:
Smarty template folder Permission : 775
Smarty Cache folder permission: 775
Folder Owners:
both ftp_user:webserver_user
I'm trying to implement different solutions but it seems not possibile to solve this issue whitout changhing Php Error Reporting or disabling my Error Handler .
How can i solve this problem without hacks ?
What you should do is not to downgrade to 3.1.1 but rather try to upgrade to 3.1.19 version. Many bugs are removed all the time so maybe in this version you won't have it.
The other thing is that you can use muteExpectedErrors method to hide file system warnings from Smarty (documentation for this function is not very clear but it affects file system warnings what is explained in error_reporting documentation). You can read at error_reporting documentation page:
Smarty 3.1.2 introduced the muteExpectedErrors() function. Calling
Smarty::muteExpectedErrors(); after setting up custom error handling
will ensure that warnings and notices (deliberately) produced by
Smarty will not be passed to other custom error handlers. If your
error logs are filling up with warnings regarding filemtime() or
unlink() calls, please enable Smarty's error muting.
Check the filesystem permission on /path_to_templates/smarty/templates_c/219dfe732aae7bd7c0edab091e3c53f3ce86b058.file.index.tpl.php
PHP does not seam to have read/write permission on that file.
Also check the permission in the /path_to_templates/smarty/templates_c/ folder. Is the PHP allowed to read list and write in there as well?