Is this a joke? I hope it is because I hear VBO is the way to go and I want to use it from now on.
As Reto Koradi explained, 2.2 has VBO support but no Java bindings. To use VBO on 2.2 you can use GLES20Fix bridge from official GDC11 demo: https://code.google.com/p/gdc2011-android-opengl/
However, 2.2 is almost completely extinct now so you can just use minimum API level 9. Stats of currently used Android versions: http://developer.android.com/about/dashboards/index.html
That's sort of true, at least if you're using the Java APIs. OpenGL ES 2.0, which includes VBO support, was added with API level 8, which corresponds to 2.2 (Froyo).
But they initially forgot to include a proper Java binding for the key entry point needed for VBO support. It ended up getting added in API level 9, which corresponds to 2.3 (Gingerbread). So in Froyo, you can use VBOs from native code with the NDK, but not with the Java bindings. The native bindings for ES 2.0 were actually there even before Froyo, I remember using them in Éclair.
You can see this by looking at the GLES20 documentation, it says "Added in API level 8".
But if you look at the small print next to the glVertexAttribPointer() call that takes an int as its last argument, it says that it was introduced with API level 9 (direct documentation link).
Related
Hi I have wanted to learn Scrapy and use it to scrape dynamic data off of webpages, and use it in a website backend.
When I went to the official docs, I go to know that V.2.0 just came out.
Given that I'm new to scrappy, and plan to develop an autonomous hosted application, I was wondering whether I should choose v 1.8 over v 2.0 because bugs would've been worked out better and there'll be more tutorials etc. But on the other hand, I'll end up learning 2.0 anyway in the future, so maybe I should start with 2.0 itself.
So I have two questions:
Are there any major changes from v1.8 to v.2.0 (I am aware that there are release notes that accompany each version, but the only thing that I can really understand is that Python 2 support was removed; everything else uses terminology that I don't understand.)
I'd be grateful for your advice on which one I should opt for.
I have worked with Selenium & BeatifulSoup4 on 1 project before hand, which involved scraping stock price and relative strength index, and using that as a part of Flask backed web app.
Always use the latest Scrapy release for a new project, unless you cannot for some reason.
There are no major changes in how Scrapy works between 1.8 and 2.0; upgrading from 1.8 to 2.0 should be as easy as upgrading from 1.7 to 1.8.
I see that Appdynamics 4.2 claims to support Java 8 lambda instrumenting, but this support was removed in 4.3.
I cannot find anything in 4.3 release notes that mentions removing support for lambdas.
What's happened? Is it somehow related to JDK-8145964?
See 4.3.x Documentation⇒POJO Entry Points⇒Monitor Java Interface Static and Default Methods:
Note that another Java language feature introduced in Java 8, lambda method interfaces, are not supported by the AppDynamics Java Agent.
It’s possible that this is due to technical difficulties with JDK-8145964 as you suspect. But I’d also point out that this kind of Instrumentation would be questionable. It’s not this JRE generated class that implements any specific behavior, it’s the invoked target method.
Support for Lambda expressions has been in the product since 4.1 which shipped in 2015 I believe. That being said we are always enhancing support. These do have some limitations after initialization of the classes using them (dynamic instrumentation limits). The product should support them, we have added some additional capabilities and features for Lambda expressions in our next major release. Have you tried to contact help # appdynamics.com
Looks like it was not mentioned in release notes, but instead Support Advisory 56039 was raised. They indeed mention JDK-8145964 as a reason for removing the support.
I'm using OpenTK with rendering through a GLControl. However, I cannot find any examples on the internet or figure out how to use OpenGL 3.x features (Disregarding the short mention in the OpenTK FAQ, which wasn't overly helpful).
By OpenGL 3.x features, I'm meaning that the whole 'glTranslate' model is unaccessible, and the only rendering or translation, etc, is used through shaders and passing around model/view/projection matrices.
GLControl by default creates a compatibility context with the maximum version supported by your drivers. For example, if you have a recent Nvidia card with up-to-date drivers, GLControl will give you an OpenGL 4.5 compatibility context.
Note that on Linux and Mac OS X, compatibility contexts are limited to OpenGL 2.1. To access higher versions you need to create a core context instead:
var glControl = new GLControl(GraphicsMode.Default, 4, 0, GraphicsContextFlags.ForwardCompatible);
Deprecated functions, such as glTranslate, are not available on core contexts.
If you are using the WinForms UI designer, you can achieve the same result by deriving a custom control from GLControl and specifying the desired (minimum) version in its constructor:
class CoreGLControl : GLControl
{
public CoreGLControl() : base(GraphicsMode.Default, 3, 0, GraphicsContextFlags.ForwardCompatible)
{ }
}
You can then drag and drop this onto your form.
I'm writing a Windows Phone framework with Windows 8 in mind. That means I'm creating a Portable Class Library (PCL) to be used in both platforms.
Right now my PCL is targeting .NET 4.5, Windows Phone 8 and Windows Store apps, as you can see in the project properties.
In that project I need to use Path.DirectorySeparatorChar but I get the following error from the compiler:
System.IO.Path' does not contain a definition for 'DirectorySeparatorChar'
I understand that that particular char might be different in the different targeted OS (I really don't know if they are) but why is the compiler complaining about it? I mean, the property help doc says it is supported by .net framework 4.5, am I targeting the right framework? Is the PCL really targeting the full .net framework 4.5?
With respect to Path.DirectorySeparatorChar:
As far as I remember we've removed it from Windows Store in order to discourage manual parsing of paths. In general you should use Path.Combine() for assembling paths and Path.GetDirectoryName() for splitting them up. In order to check for invalid chars, there is another method that allows retrieving those.
So practically speaking, what do you need the property for?
Update: To answer your original question around understanding profiles: The profiles represent API intersections between the platforms you've selected in the PCL dialog. Generally speaking, the fewer platforms you target and the more recent the versions, the more APIs you get. Checking all platforms in the oldest version basically gives you the lowest common denominator.
Since you've targeted .NET 4.5 and .NET Windows Store, you can't access Path.DirectorySeparatorChar because that property isn't included in Windows Store.
So, here's the actual answer to this question taken from the MSDN forum.
When you are creating a PCL, you can only have a subset of API-s that are defined in that particular profile. A profile is a list of API-s visible in all platforms.
Now, even if some API exists in both individiual platforms, this doesn't mean that it will automatically be in the PCL profile. Why is it missing is anyone's guess, but you cannot infer those reasons yourself.
If you take a look at the official documentation on MSDN (Cross-Platform Development with the .NET Framework), you'll notice that there are several constraints on what can be shared. I guess that that particular property doesn't satisfy those constraints.
And a good way of knowing is a particular method is supported relies on the icons of the documentation
Your PCL can use .NET methods which are available to all of its targets. Since PathDirectorySeparator isn't available to Windows Store apps it isn't available in PCLs targeting Windows Store apps. You can see that it doesn't have the green shopping bag marker for store support at http://msdn.microsoft.com/en-us/library/system.io.path.aspx
When you read the Class Reference of every object of iOS, you will find:
Available in iOS 2.0 and later.
There are a program or a way to list all function and the minimum iOS system?
How can I know if the iPhone with iOS 3.0 will run all iOS function? I can check it in runtime with respondToSelector, but can be more easy with source code?
Set your project's base SDK to iOS 3, and see if it builds.
AFAIK there is no way to list all the APIs you use in your app into one list and check that you are building past the minimum for all those APIs. You will just have to check each one, one by one. Highlight the API in Xcode, and then click escape and it will tell you very easily.
But also I have to mention that this won't be extremely necessary since you should test on the minimum OS you are building for and if it crashes at any point then you have your issue for that certain API.