All the server stack traces are printed on one line. It looks like they are stringified and only then printed.
Example:
I20151215-23:18:57.623(0)? Exception while invoking method 'adminCheckAdmin' { stack: 'Error: When the modifier option is true, validation object must have at least one operator\n at checkModifier (packages/aldeed_simple-schema/simple-schema-validation.js:271:1)\n at doValidation1 (packages/aldeed_simple-schema/simple-schema-validation.js:321:1)\n at [...]
I20151215-23:18:57.623(0)? source: 'method' }
I am not sure how to debug and fix this.
The problem was kadira:debug package.
After uninstalling all stack traces are properly formatted.
Related
If I use a built-in Sass function that returns an error, it will display the path of where it is used.
Using a built-in Sass function:
Code from _test.scss.
.foo {
color: darken(blue, s);
}
Will result in:
error _test.scss (Line 2: $amount: "s" is not a number for `darken')
Now, if I use a custom function that returns an error, it will display the path of where it is defined instead of where it is used.
Using a custom function:
Code from _test.scss.
.foo {
color: example(string);
}
Code from _functions.scss.
#function example($string) {
#error 'error message';
}
Will result in:
error core/utils/_functions.scss (Line 2: error message)
Is there any solution for solving this "issue"?
Your examples are similar only visually, underlying logic is completely different:
For built-in function Sass throws error by itself because code is not valid from Sass point of view.
Into second example you're throwing error because code is not valid from your point of view. Code itself if valid from Sass point of view in this case.
In both cases Sass displays same information about error location - a point into your codebase where error occurs. But in a case of your own, intentional error throwing actual point where error occurs actually matches a place where you're generating this error - exactly at a place where you have your #error directive. So there is no mistake into Sass behavior because it knows nothing about reasons why did you decide to throw an error.
You can always analyze stack trace that is displayed (at least by node-sass) along with error message to decide where did you get to point of error from. You can also use #debug to display context that may be useful for error analysis.
I'm trying to get started with OpenCL but came across weird behavior of the OpenCL compiler with respect to white-space and can't seem to find any documentation about that.
C-style single-line comments (// foo) immediately cause a meaningless build error: At end of source: error: expected a "}". Multi-line comments (/* bar */) seem to work fine.
Line breaks seem to get stripped without adding whitespace which can cause errors. This example will not compile because of that:
__kernel
void TestKernel() {}
line 1: error: identifier "__kernelvoid" is undefined
This may totally depend on my machine and/or configuration but can somebody confirm that these things should not be this way?
I am using OpenCL via Cloo from .net/C#. The driver is from AMD OpenCL 2.0 AMD-APP (1642.5)
I think I figured it out. I was doing this:
var program = new ComputeProgram(context, File.ReadAllLines(filename));
File.ReadAllLines() returns an array of strings without the line-break characters which is the root of the errors I was getting.
Using File.ReadAllTest() instead fixed all the problems:
var program = new ComputeProgram(context, File.ReadAllText(filename));
But in my opinion some of the blame goes to either Cloo or the OpenCL API for accepting a string array but just concatenating it together..
Under what circumstances the IMFMediaSourceTopologyProvider::GetMediaSourceTopology() does not fail? It always fails with code 0xc00d36e6 (MF_E_ATTRIBUTENOTFOUND).
Please do not answer with a link to MSDN.
Here is the solution after pissing blood for hours.
You have to call QueryInterface() on IMFSequencerSource object to get the IMFMediaSource like this:
hr = pMFSequencerSrc->QueryInterface( __uuidof( IMFMediaSource ), (void**)&pMediaSource );
Now on pMediaSource object call CreatePresentationDescriptor() to get the presentation descriptor required for the GetMediaSourceTopology() call.
voila...
P.S.
That MF_E_ATTRIBUTENOTFOUND error... nice work M$
I am using / fixing collective.logbook to save errors on the site. Currently logbook fails on my site on some exceptions:
File "/srv/plone/xxx/src/collective.logbook/collective/logbook/events.py", line 101, in hand
transaction.commit()
File "/srv/plone/buildout-cache/eggs/transaction-1.1.1-py2.6.egg/transaction/_manager.py", line 8
return self.get().commit()
File "/srv/plone/buildout-cache/eggs/transaction-1.1.1-py2.6.egg/transaction/_transaction.py", li
self._commitResources()
File "/srv/plone/buildout-cache/eggs/transaction-1.1.1-py2.6.egg/transaction/_transaction.py", li
rm.commit(self)
File "/srv/plone/buildout-cache/eggs/ZODB3-3.10.5-py2.6-linux-x86_64.egg/ZODB/Connection.py", lin
self._commit(transaction)
File "/srv/plone/buildout-cache/eggs/ZODB3-3.10.5-py2.6-linux-x86_64.egg/ZODB/Connection.py", lin
self._store_objects(ObjectWriter(obj), transaction)
File "/srv/plone/buildout-cache/eggs/ZODB3-3.10.5-py2.6-linux-x86_64.egg/ZODB/Connection.py", lin
p = writer.serialize(obj) # This calls __getstate__ of obj
File "/srv/plone/buildout-cache/eggs/ZODB3-3.10.5-py2.6-linux-x86_64.egg/ZODB/serialize.py", line
return self._dump(meta, obj.__getstate__())
File "/srv/plone/buildout-cache/eggs/ZODB3-3.10.5-py2.6-linux-x86_64.egg/ZODB/serialize.py", line
self._p.dump(state)
TypeError: Can't pickle objects in acquisition wrappers.
This is obviously because logbook tries to write a record of the error which refers to an acquired object. I assume that the solution is to clean the error from these kind of objects.
However, how can I figure out what is the bad object, how it ends up to the transaction manager and what are the Python object references causing this issue? Or anything which could help me to debug this issue?
If you can reproduce this reliably, you can put in a print statement or pdb.set_trace() in the ZODB connection _register method (in ZODB/connection.py inside the ZODB egg):
def _register(self, obj=None):
# ... skipped lines ...
if obj is not None:
self._registered_objects.append(obj)
# Insert print statement here.
Now whenever any object has been marked as changed or is added to the connection as a new object, it'll be printed to the console. That should help you with the debugging process. Good luck!
Im using google Closure Compiler to compress my js, anyhow I get the following error message:
JSC_TRAILING_COMMA: Parse error. Internet Explorer has a non-standard intepretation of trailing commas. Arrays will have the wrong length and objects will not parse at all. at line 8698 character 5 in post-login.js
];
The error is in the first line of this code, but I could not figure out whats wrong with it...
var plot = $.jqplot('usst_points_last_10_days', [data], {
title: '<h3 class="startGrafHeadline">' + global_language['discriptive']['usst']['visits_in_detail'] + '</h3>',
seriesColors: ["#00FF00"],
series: [{renderer:$.jqplot.BarRenderer}],
axesDefaults: {
tickRenderer: $.jqplot.CanvasAxisTickRenderer ,
tickOptions: {
angle: -30,
fontSize: '10pt'
}
},
axes: {
xaxis: {
renderer: $.jqplot.CategoryAxisRenderer
}
}
});
Try looking at the line just before the line that the compiler is complaining about. This will be the last line is some other file, perhaps.
If you examine your command line or build script, that will lead you to the answer. It seems likely that you are compiling multiple files or are pre-concatenating many files before compilation. What closure compiler is telling you is to look at line 8698.
If you have some logical explanation about why you think the error is contained in this code, please let us know your reasoning.
If you post more information, I may be able to improve this answer.
There is a handy tool for using closure-compiler through a web UI that may help you convince yourself that you have not found the offending line:
http://closure-compiler.appspot.com