I have native android code that i bundle with my app. This has always been working for many months. But today, the same code is failing with warnings. I think the last successful build was two days ago:
--
Note: there were 5 references to unknown classes.
You should check your configuration for typos.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unknownclass)
Note: there were 1927 unkept descriptor classes in kept class members.
You should consider explicitly keeping the mentioned classes
(using '-keep').
(http://proguard.sourceforge.net/manual/troubleshooting.html#descriptorclass)
Note: there were 2 unresolved dynamic references to classes or interfaces.
You should check if you need to specify additional program jars.
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclass)
Note: there were 4 class casts of dynamically created class instances.
You might consider explicitly keeping the mentioned classes and/or
their implementations (using '-keep').
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclasscast)
Warning: there were 23 unresolved references to program class members.
Your input classes appear to be inconsistent.
You may need to recompile the code.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedprogramclassmember)
Exception while processing task
java.io.IOException: Please correct the above warnings first.
at proguard.Initializer.execute(Initializer.java:473)
at proguard.ProGuard.initialize(ProGuard.java:233)
at proguard.ProGuard.execute(ProGuard.java:98)
at proguard.gradle.ProGuardTask.proguard(ProGuardTask.java:1074)
at com.android.build.gradle.tasks.AndroidProGuardTask.doMinification(AndroidProGuardTask.java:139)
at com.android.build.gradle.tasks.AndroidProGuardTask$1.run(AndroidProGuardTask.java:115)
at com.android.builder.tasks.Job.runTask(Job.java:48)
at com.android.build.gradle.tasks.SimpleWorkQueue$EmptyThreadContext.runTask(SimpleWorkQueue.java:41)
at com.android.builder.tasks.WorkQueue.run(WorkQueue.java:227)
at java.lang.Thread.run(Thread.java:745)
:proguardRelease (Thread[Daemon worker,5,main]) completed. Took 6.197 secs.
:dexRelease (Thread[Daemon worker,5,main]) started.
:dexRelease
Executing task ':dexRelease' (up-to-date check took 0.058 secs) due to:
---
So, i have found out, proguard task will halt execution if there are warnings. While searching the net reveals various ways of dealing with these,the bottom line is to make sure you fix the warnings.
Related
I'm attempting to make a Lisp package with uiop/package:define-package. I'm using SBCL, and have confirmed that package-local nicknaming ought to be supported:
* *features*
(:QUICKLISP :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX
:NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :X86-64 :GENCGC :64-BIT :ANSI-CL
:COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN
:PACKAGE-LOCAL-NICKNAMES :SB-CORE-COMPRESSION :SB-LDB :SB-PACKAGE-LOCKS
:SB-THREAD :SB-UNICODE :SBCL :UNIX)
* (uiop:featurep :package-local-nicknames)
T
Nevertheless, when I try to define a package that has local nicknames, it doesn't work:
(uiop/package:define-package #:foo
(:use #:cl)
(:local-nicknames (#:b #:binparse)))
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {1001878103}>:
unrecognized define-package keyword :LOCAL-NICKNAMES
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(UIOP/PACKAGE:PARSE-DEFINE-PACKAGE-FORM #:FOO ((:USE #:CL) (:LOCAL-NICKNAMES (#:B #:BINPARSE))))
source: (ERROR "unrecognized define-package keyword ~S" KW)
0] 0
(binparse being another package I've made, which worked fine, but which did not happen to use local nicknaming).
What I've found of the uiop/package source seems to indicate that this shouldn't happen? Going by that, it should either work, or have a specific error message indicating the non-supported-ness of local nicknames (if somehow uiop:featurep is inaccurate or changing), but it shouldn't give a generic unknown-keyword error. At this point I'm not sure what I could be getting wrong.
The version of asdf that's included in releases of sbcl is based on asdf version 3.3.1 (November 2017), except bundled into only two (larger) lisp files (one for asdf and one for uiop) rather than breaking them up by purpose as is done in official releases of asdf. asdf added #+sbcl support for package-local nicknames in 3.3.3.2 (August 2019), and switched to the more general #+package-local-nicknames in 3.3.4.1 (April 2020) (the latest release version is 3.3.4, though, so that wouldn't be in yet anyway). So it's "just" a delay in pulling from upstream. Following the instructions on upgrading ASDF did the trick – extract the latest release tarball into ~/common-lisp/asdf and run (load (compile-file #P"~/common-lisp/asdf/build/asdf.lisp")) once, and future shells will use the updated version.
I working on a version bump on the cc65 and encountered a problem with the linuxdoc-tools. Since I can't fix the linuxdoc-tools and there is a simple workaround possible I decided to add an if statement to inform the user together with the workaround:
if {! [file exists ${prefix}/bin/perl] } {
ui_error "
«${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.
Please create an appropriate symbolic link for linuxdoc-tools to work.
"
exit 1
}
Crude but the best I can do since I'm neither the perl5 nor the linuxdoc-tools maintainer and I don't want to spend to much time on a version bump.
However, the MacPorts doesn't understand exit 1 and ui_error won't stop execution on its own.
How do I stop the execution so not to waste the users time on a build which will otherwise fail right at the end.
Use return -code error "error message", or the shorthand for the same thing, error "error message".
Note that you should use ui_error before that to print a human-readable message for the user – while the error message is also being printed, it can sometimes get lost in the output.
Additionally, note that $prefix/bin/perl is a build dependency of linuxdoc-tools. If it is also needed at runtime, you should submit a pull request that adds depends_run path:bin/perl:perl5 to the port rather than attempting to fix this bug in your port.
Tests ignored: 14, passed: 0
Whenever I run any test class I get this type of messages:
Test ignored.
Test method AccountAddressHelperTest.testInvalidBillingCountry was
never reported as completed. Trigger.AllOppLineItemTriggers: line 188,
column 31: Method does not exist or incorrect signature: void
updateMISROnOpportunity(Map<Id,OpportunityLineItem>,
Map<Id,OpportunityLineItem>) from the type OppLineItemHelper
You have compilation failures. What happens if you hit Setup -> Classes -> Compile all?
You or your colleague edited something, probably in file OppLineItemHelper. Or some other file this file reuses. And now not everything compiles, dependencies aren't met. So best thing SF can do is skip these tests.
You can edit like that in sandboxes, SF will not always block you. But compile errors will prevent deployment to prod even before any tests are run
We are analyzing sequencing data while filtering and trimming fastq files encountered following error. Is the following error due to unavailability of core for processing commands?
Error in colnames<-(*tmp*, value = c("cs103_R1_dada.fastq", "cs110_R1_dada.fastq", : attempt to set 'colnames' on an object with less than two dimensions In addition: Warning message: In mclapply(seq_len(n), do_one, mc.preschedule = mc.preschedule, : all scheduled cores encountered errors in user code >
As pengchy suggested there may be something wrong with function.
try the same call by using lapply and error message will be more informative.
To clarify on what #f2003596 and #HelloWorld said: This just means that a crash occurred within the function you called, i.e. while it was executing that function. But this does not necessarily mean that your function is incorrect. For example, you get the same error when a variable has not been found.
That would mean your R function has a crash.
Note: If you include an unexpected argument in mclapply you also can get this error message. I put mC.cores instead of mc.cores by mistake and I got it.
I'm running into a very peculiar and undocumented issue with a GAE Managed VM and Task Queues. I understand that the Managed VM service is in beta, so this question may not be relevant forever, but it's definitely causing me lots of headache now.
The main symptom of the issue is that, in certain (not completely known to me) circumstances, I'm seeing the following error/traceback:
File "/home/vmagent/my_app/some_file.py", line 265, in some_ndb_tasklet
res = yield some_task.add_async('some-task-queue-name')
File "/home/vmagent/python_vm_runtime/google/appengine/ext/ndb/tasklets.py", line 472, in _on_rpc_completion
result = rpc.get_result()
File "/home/vmagent/python_vm_runtime/google/appengine/api/apiproxy_stub_map.py", line 613, in get_result
return self.__get_result_hook(self)
File "/home/vmagent/python_vm_runtime/google/appengine/api/taskqueue/taskqueue.py", line 1948, in ResultHook
rpc.check_success()
File "/home/vmagent/python_vm_runtime/google/appengine/api/apiproxy_stub_map.py", line 579, in check_success
self.__rpc.CheckSuccess()
File "/home/vmagent/python_vm_runtime/google/appengine/ext/vmruntime/vmstub.py", line 312, in _WaitImpl
raise self._ErrorException(*_DEFAULT_EXCEPTION)
RPCFailedError: The remote RPC to the application server failed for call taskqueue.BulkAdd().
I've gone through my local App Engine SDK to trace this through, and I can get up to the last line of the trace, but google/appengine/ext/vmruntime/ doesn't exist on my machine at all, so I have no idea what's happening in vmstub.py. From looking at the local code, some_task.add_async('the-queue') is spinning up an RPC and waiting for it to finish, but this error is not what the except apiproxy_errors.ApplicationError, e: at line 1949 of taskqueue.py is expecting...
The code that's generating the error looks something like this:
#ndb.tasklet
def kickoff_tasks(batch_of_payloads):
for task_payload in batch_of_payloads:
# task_payload is a dict
task = taskqueue.Task(
url='/the/handler/url',
params=payload)
res = yield task.add_async('some-valid-task-queue-name')
Other things worth noting:
this code itself is running in a task handler kicked off by another task.
I first saw this error before implementing this sort of batching, and assumed the issue was because I had added too many tasks from within a task handler.
In some cases, I can run this successfully with a batch size of 100, but in others, it fails consistently (depending on the data in the payloads) at 100, and sometimes succeeds at batch sizes of 50.
The task payloads themselves include batches of items, and are tuned to be just small enough to fit in a task. App Engine advertises a maximum task size of 100KB, so I'm keeping the payloads to under 90,000 bytes right now. Lowering the size even more doesn't seem to help any.
I've also tried implementing an exponential backoff to retry the kickoff_tasks method when this error appears, but it seems that once the error is raised, I can't add any other tasks at all from within the same handler (i.e. I can't kickoff a "continue from where you left off" task, I just have to let this one fail and restart itself)
So, my question is, what is actually causing this error? How can I avoid it, or fix this so that I'm handling it correctly?
This is a known issue that is being worked on. There are actually two issues - the RPC failure itself and the lack of handling of the RPCFailedError exception by the SDK.
There is some public discussion of the issue here.
If you're using App Engine Flexible and the python-compat-multicore image, a new bug popped up related to App Engine using a newer version of the requests library that broke the communication between App Engine Flexible and the datastore. You can fix this error by monkey patching the library in your appengine_config.py file.
Add the following code to appengine_config.py:
try:
import appengine.ext.vmruntime.vmstub as vmstub
except ImportError:
pass
else:
if isinstance(vmstub.DEFAULT_TIMEOUT, (int, long)):
# Newer requests libraries do not accept integers as header values.
# Be sure to convert the header value before sending.
# See Support Case ID 11235929.
vmstub.DEFAULT_TIMEOUT = bytes(vmstub.DEFAULT_TIMEOUT)
Note that if you do not have an appengine_config.py file, you can just create it in your base project directory (wherever you put your app.yaml file). This file gets run during App Engine startup..