Sorry for such broad question, but after some attempts I'm not sure how to use python bindings. I tried to just import "request.py" or "capi.py" but all I got were errors. After adding missing libraries to my search path, I ended with missing symbol "_dispatch queue_attr_concurrent" (which suggest wrong library version?).
My question isn't about that particular error, but rather correct way of interacting with python bindings (and SourceKit itself). I have tried to use precompiled version, and compile it myself (https://stackoverflow.com/a/40033117/1117854), but result was all the same.
Is there something obvious that I'm missing? Or maybe someone with similar experience succeed and have some tips? It's not well documented and I'll probably find solution sooner or later, but I believe I'm not the only one who felt lost after first contact with SourceKit.
Related
When I run composer updates I'll occasionally get messages that packages are abandoned and I should use a different one instead, like Package webflo/drupal-core-require-dev is abandoned, you should avoid using it. Use drupal/core-dev instead. I don't have experience with Composer so I'm curious as to what is seen as the best practice for replacing outdated packages.
Where do these messages come from? I'm unsure if the source is always reliable.
I think the best practice is quite clear from the message "you should avoid using it". How/When to do this is not as clear. Abandoned packages will not receive updates, but composer will not be able to tell you how difficult it will be to transition to the recommended alternative. It might be that all you have to do is replace the package, because it was only a name change or having to modify your code as well.
In your case webflo/drupal-core-require-dev only contains a composer.json and the required packages match with what the alternative drupal/core-dev provides. That means replacing the package should be as easy as changing the name in your composer.json and then do a composer update drupal/core-dev.
For packages where the answer is not as straightforward, you have to rely on automated/manual tests to see if everything still works. Static code analysis tools might help as well. You will have to set them up before you do the change, so that you can see how their output differs and fix the new issues that come up.
You should do the switch to the new dependency as early as possible. Leaving it in will likely cause more work in the future when replacing it and might pose a security risk (if it is outdated and insecure). I understand that this is not always possible and using something like roave/security-advisories to tell you when there are known security issues in a package might help postponing it and giving some sense of security.
Is the SideDrawer not working in NativeScript? If so, I can leave it and look for another solution.
I'm testing out NativeScript to see if it is something for my project. Doing this tutorial http://docs.nativescript.org/angular/tutorial/ng-chapter-1 it felt really promising.
But then I tried to add a sideDrawer and everything just became extremely confusing. It seems like there are a lot of different versions on how to use the SideDrawer and the tags are different: RadSideDrawer, SideDrawer etc.
I tested these (and others):
https://www.nativescript.org/blog/using-cross-platform-native-sidedrawer-component-in-nativescript
http://www.techumber.com/navigation-drawer-side-drawer-for-nativescript/
All of the attempts I've made have resulted in different kind of errors from segmentation fault when starting up or null pointer exception when not being able to call openDrawer on the RadSideDrawer (or whatever it is supposed to be called).
I just want to have a sidedrawer in my app... Had no idea that it could be so complex.
A good sample (also listed in nativescript-snacks and tweeted by nativescript) ist the sidedrawer-template from shripalsoni04:
https://github.com/shripalsoni04/nativescript-angular-drawer-template
It worked well for me on Android (just make sure you download everything, including the icons from App_Resources! Otherwise, the sidedrawer won't display!). Also good to know: It actually uses the nativescript-telerik-ui sidedrawer (so make sure everything is installed correctly there as well => also check package.json for right dependencies).
While doing some analysis on the usage details for the SquishIt framework, I came across a link as mentioned below:
https://danielsaidi.wordpress.com/tag/squishit/
which describes that SquishIt is having some problems with getting to work with JavaScript closures.
I am currently using the latest version :0.9.3.0 of SquishIt.Mvc. Can anyone help me to know whether this version has still the issues while working with JavaScript closures.
I am not aware of any issues at this time (was not aware of any in 2010 either however). It seems like any issues with closures are probably really issues with the minification library used, or files incorrectly terminated. At some point in the last couple years I think we did start adding semicolons between concatenated files if not present to deal with the latter. If you do find any I would love to hear about them.
This question is specifically about MooseX::Traits. The method apply_traits has been deprecated and it gives a warning message as follows:
apply_traits is deprecated due to being fundamentally broken.
disable this warning with "no warnings 'MooseX::Traits'"
Can anyone explain why it is 'fundamentally broken'?
It passes its own tests on that method, and it works for what I'm trying to do. Is it because it uses Moose::Meta::Role::apply()?
I cannot tell you what you want to know, but I would advise you to find another way of doing
what you want to do, just to save you a lot of work further down the road.
I attempted to use it in production, and it kept causing problems with other parts of Moose until I ripped it out again. I have forgotten specifics, but ended up talking to one of the main guys behind Moose at that time, and he was unable to help.
Apparently, the situation has not improved. I would heed the warning.
Just a bit of advice, sorry I could not answer your question.
Im working with Oracle WebLogic, Netbeans 6.9.1.
I have the following lines of code:
Query query=entityManager.createNamedQuery("Items.findById").setParameter("id", Integer.parseInt((String) request.getParameter("id")));
Items it=(Items) query.getSingleResult();
and they throw an exception:
java.lang.ClassCastException: entity.Items cannot be cast to entity.Items
Even if that seem impossible, i saw similar question on SO: here
Author havent published the solution but one of participants made a good asumption about different class loaders.
Meanwhile if i use getResultList and then work with it in JSP, it works fine. But i cant make casting work in servlet code.
How can i fix this in weblogic?
It doesn't solve your problem specifically, but if you're using WebLogic Server 10.3.x or thereabouts, there is a web application provided as part of that distribution that you can use to troubleshooting classloading issues.
You can read more about it here: http://download.oracle.com/docs/cd/E17904_01/web.1111/e13706/classloading.htm#WLPRG495
It should be compatible with earlier versions of WebLogic Server, so you could use that in conjunction with the proposed workarounds to get to a solution.
See this similiar question with a proposed workaround.
This indeed looks like a classloading problem.
This earlier answer of mine explains how to verify this assumption.
Unfortunately, classloading problems are difficult and painful. There is no easy fix, only to try to understand what classloaders are loading what classes in which order, and trying to play around with your classloaders, classes and jars to eliminate the problem. Also, analyse the most recent changes in your app before this error appeared - these can provide the key to understanding the root cause.
I am not familiar with the classloading scheme in WebLogic, so unfortunately I can't give you any more specific advice.