After porting from NAOqi ver. 2.8.5.10 to 2.8.6.23 I have found that:
std::string ALVideoDeviceProxy::subscribe()
is missing, which is not so suspicious, because it was already deprecated and could be replaced with:
std::string ALVideoDeviceProxy::subscribeCamera()
but also:
AL::ALValue ALVideoDeviceProxy::getDirectRawImageRemote()
is missing, and has to be replaced with:
AL::ALValue ALVideoDeviceProxy::getImageRemote()
Is it correct and does it have any impact on the performance?
Some API have been removed and the documentation will be updated accordingly.
Yes, you can use getImageRemote instead of getDirectRawImageRemote.
There is no performance impact if there is only one subscriber or multiple subscribers using same resolution natively supported and colour space (kYUV422ColorSpace). In this case there no resizing or colour space conversion.
Related
For the last few weeks, I have been trying to deal with an intermittent problem on a camel route using XSLT processing following aggregation. It is intermittent in the sence that while it frequently raises this exception, I can re-run the data extract and processing that failed a few seconds later and it usually succeeds. I have yet to find any data that fails consistently.
I am assuming that the aggregation is causing the problem, but I can't for the life of me understand why. I thought it might be the custom aggregation bean I was using, so I replaced it with XSLTAggreationStrategy, but it still intermittently gives this issue, either when further transforming the aggregated XML, or when just writing it out to the a file.
This is executing in an Apache-Karaf environment, and I have Camel-Saxon 2.21.2 and Apache ServiceMix Saxon-HE 9.8.0.8_1 bundles loaded.
Thanks for looking.
The abridged stack trace is:
...
Caused by: [java.lang.NullPointerException -
null]java.lang.NullPointerException
at net.sf.saxon.dom.DOMNodeWrapper$ChildEnumeration.skipFollowingTextNodes(DOMNodeWrapper.java:1149)
at net.sf.saxon.dom.DOMNodeWrapper$ChildEnumeration.next(DOMNodeWrapper.java:1178)
at net.sf.saxon.tree.util.Navigator$EmptyTextFilter.next(Navigator.java:1078)
at net.sf.saxon.tree.util.Navigator$AxisFilter.next(Navigator.java:1039)
at net.sf.saxon.tree.util.Navigator$AxisFilter.next(Navigator.java:1017)
at net.sf.saxon.expr.parser.ExpressionTool.effectiveBooleanValue(ExpressionTool.java:643)
at net.sf.saxon.expr.Expression.effectiveBooleanValue(Expression.java:532)
at net.sf.saxon.pattern.PatternWithPredicate.matches(PatternWithPredicate.java:141)
at net.sf.saxon.trans.Mode.searchRuleChain(Mode.java:570)
at net.sf.saxon.trans.Mode.getRule(Mode.java:476)
at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1041)
at net.sf.saxon.expr.instruct.ApplyTemplates.apply(ApplyTemplates.java:281)
at net.sf.saxon.expr.instruct.ApplyTemplates.processLeavingTail(ApplyTemplates.java:241)
at net.sf.saxon.expr.instruct.Template.applyLeavingTail(Template.java:239)
at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1057)
at net.sf.saxon.expr.instruct.ApplyTemplates.apply(ApplyTemplates.java:281)
at net.sf.saxon.expr.instruct.ApplyTemplates.process(ApplyTemplates.java:237)
at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:431)
at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:373)
at net.sf.saxon.expr.instruct.Template.applyLeavingTail(Template.java:239)
at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1057)
at net.sf.saxon.Controller.transformDocument(Controller.java:2080)
at net.sf.saxon.Controller.transform(Controller.java:1903)
at org.apache.camel.builder.xml.XsltBuilder.process(XsltBuilder.java:141)
at org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:103)
at org.apache.camel.component.xslt.XsltEndpoint.onExchange(XsltEndpoint.java:138) ...
In 9.8.0.8, the class net.sf.saxon.dom.DOMNodeWrapper has only 1144 lines, so a stacktrace showing line 1178 suggests there's some kind of versioning problem.
The class DOMNodeWrapper was first introduced in 9.5 (previously it was called NodeWrapper), and the line numbers are just one off from those in the current 9.5 source, so I suspect what you have loaded is some sub-release of the 9.5 branch. Other line numbers in the stack trace are also consistent with this being 9.5.
That of course doesn't explain the problem, but it might give a clue.
My immediate instinct was that over the years since 9.5 we might have fixed a multi-threading bug. DOM is not thread-safe, so Saxon takes considerable care to synchronize its access. Saxon bug https://saxonica.plan.io/issues/2376 addresses this problem. On the 9.5 branch this was first fixed in maintenance release 9.5.1.11, so it's possible you don't have that patch. I think it would be useful to investigate why you are loading an old version of Saxon, and another useful angle would be to discover exactly which version it is (the static method net.sf.saxon.Version.getProductVersion() will give you this information.)
Incidentally, if you are using multi-threaded access to a DOM tree then you should ask yourself whether this is a good idea. Saxon access to DOM is slow at the best of times (compared to JDOM and XOM, let alone to Saxon's native tree model), and the lack of thread safety and the need for synchronisation makes it a pretty poor choice in a multi-threaded application.
Also, note that Saxon can synchronize its own access to the DOM, but it can't synchronize with third-party code that might also be using the DOM.
I've got a native interface with two reasons I need to have the device's SDK level. The first is that some methods were deprecated and so I need to determine if the device has a high enough version for the new API, and the second is that a new permission is required for SDK level 23 but adding that permission on devices with
I've tried statements like this below, but I don't think it's working:
if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.JELLY_BEAN_MR2)
I've also tried the above with just the integer representing the level, such as 18 for JELLY_BEAN_MR2. Is there an AndroidNativeUtil for this? I can't find any documentation about what classes are in AndroidNativeUtil.
The reason I don't think it's working is that when I add these statements to control which API is used, the app works OK on a newer device with the higher API level, but hangs on a device with the older API level. I'm assuming that it must always think the API > 18.
The String Build.VERSION.RELEASE will give you the user-visible version string (i.e 1.5, 1.6, 2.0), while Build.VERSION.SDK_INT will give you a value from Build.VERSION_CODES that would be better to use if you want to compare against it programmatically.
Note that Build.VERSION.SDK_INT is only available on Android 1.6 and newer. Build.VERSION.SDK will work on all Android releases, including 1.5. However, once you elect to drop 1.5 support, switching to SDK_INT is a good idea.
EDIT:
StringBuffer buf = new StringBuffer();
buf.append("VERSION.RELEASE {"+Build.VERSION.RELEASE+"}");
buf.append("\\nVERSION.INCREMENTAL {"+Build.VERSION.INCREMENTAL+"}");
buf.append("\\nVERSION.SDK {"+Build.VERSION.SDK+"}");
buf.append("\\nBOARD {"+Build.BOARD+"}");
buf.append("\\nBRAND {"+Build.BRAND+"}");
buf.append("\\nDEVICE {"+Build.DEVICE+"}");
buf.append("\\nFINGERPRINT {"+Build.FINGERPRINT+"}");
buf.append("\\nHOST {"+Build.HOST+"}");
buf.append("\\nID {"+Build.ID+"}");
Log.d("build",buf.toString());
From Angular.js change log:
... After this CL, ng-trim no longer affects input[type=password], and will never trim the password value.
This is from one of the commit messages, so presumably it means the patch. What does it stand for? Change log?
It means Change List.
Create a change list (CL)
Creating a change in git is really just creating a branch.
http://www.chromium.org/developers/contributing-code
And the code review system there are using: https://code.google.com/p/rietveld/
It seems to be Google-speak. I don't work for Google so I can only guess, but I'd guess it means "changelog", in the meaning of "a small set of commits being considered as a single unit for merging", much like a Github PR (pull request). It shows up here and here (search in the page for "CL created") with that same usage, and it shows up all over the place in the Angular issues.
If you're more familiar with Github-speak than Google-speak, mentally substitute "PR" for "CL" and I think you'll have the right idea. :-)
CL: Stands for “changelist,” which means one self-contained change that has been submitted to version control or which is undergoing code review. Other organizations often call this a “change” or a “patch.”
*from the Terminology of the Google Engineering Practices Documentation that can be found here: https://google.github.io/eng-practices/
I'm currently using django haystack with xapian. I couldn't find any documentation on how to perform geospatial queries on xapian. But there seems to be some momentum on Solr. So i'm currently experimenting with that.
I couldn't get spatialSolr to work properly on local, but for now working with spatial-solr-light, which seems to work fine. It accepts queries like
http://127.0.0.1:8080/solr/select/?q=blahblah&spatial={!radius=1.0%20sort=true}lat:10.0,lng:-10.0
Can anyony point me to a patch for haystack that allows me to pass custom queries like that. I could use raw_search(), but i can't chain the resuts. In any case i would like to find a cleaner way to do something like
sqs.spatial(....)
There are some patches from other people mentioned on the google group(links below), but most of them are unreachable.
References:
https://github.com/fizx/solr-spatial-light
http://groups.google.com/group/django-haystack/browse_thread/thread/d0e23d45c0baa300/2298b6cf43389e18?lnk=gst&q=Spatial#2298b6cf43389e18
http://groups.google.com/group/django-haystack/browse_thread/thread/f88d625679941d77/420892adac151a64
http://groups.google.com/group/django-haystack/browse_thread/thread/e3a70112ce944b00/33bd673fbaaed0a7?lnk=gst&q=jteam#33bd673fbaaed0a7
If you're not tied to Xapian, look at Django, Sphinx and search by distance. I had a similar problem when I ran across this question and this seems to solve it. Thanks to django-sphinx, it's about as easy to set up as Haystack. Sphinx also seems to offer more flexibility.
Here's a fork of django haystack that adds in support for :
https://github.com/sidmitra/django-haystack-spatialsolrplugin
And corresponding notes are here:
https://github.com/sidmitra/django-haystack-spatialsolrplugin/wiki/_pages
Sidmitra, I made port of your solution using haystack 1.2.X and solr 3.4. With some limitations to be frank - no support for schema generation at the moment, only LatLong geo type supported, sorting by distance is not perfect (but works)
https://github.com/frutik/django-haystack/tree/1.2.X
I agree with https://github.com/sidmitra/django-haystack-spatialsolrplugin .
It seems to be out-of-date, but I could beat it into shape with some work. Issues I had:
Hard to find the java SSP and when I found it it was the wrong version. http://www.dutchworks.nl/en/home/download.html was the link that worked for me.
The classpaths in the example xml files I found on the net were all wrong; I had to remove .solrext. from all of them.
The plugin was very picky about which directory it lived in; it couldn't talk to anything else until it was happily in solr/lib
solr_backend.py required the following patch (around line 505):
if self.spatial_query:
final_query = '{{!spatial circles={lat},{long},{radius} }}{0}'.format(final_query,**self.spatial_query)
I had further issues with making the solrconfig.xml so that GeoDistanceComponent never loaded before the query had a valid rsp.
In other words, you can certainly make it work, but you have to be able to deal with a number of error messages in both python and java before you get there.
Does someone know a library that I can use to read MP3 tags in Silverlight 3?
In WPF I was using taglib, but obviously I cannot reference it in Silverlight projects.
Taglib doesn't contain any unsafe code. Perhaps you can recompile it (with a few minor alterations maybe) to work in silverlight.
Have you tried just using Taglib's code? There's a decent chance it'll work without too much hassle.
Edit: Yes, I mean TagLib#. I just tried, and there are a few minor issues which were fixable in 15min. (You'll need to define ICloneable, remove a bunch of unnecessary Serialization constructors for exceptions, remove the last parameter on string.Split(char[],int) calls, that's about it.)
Note that unless someone else has fixed it, there's a minor bug in Taglib#'s Id3v2 unsynchronization code. You can ignore it and fail to parse a few id3v2 tags, or you can use the same workaround I did: https://bugzilla.gnome.org/show_bug.cgi?id=593138#c4 - I know, I should submit a patch, but time and all...