On the ANTLR download page it states that the latest version of ANTLR is 4.4. From the C# Target section on the same page, clicking "ANTLR 4 C# Target (Latest Release)" brings me to the 4.3 Target Release GitHub page that has a link for Readme.md, which when clicked, results in a 404.
Question 1: Although the download page states that the latest version for C# 4.4, the version I get via NuGet is 4.3. Does this mean 4.4 isn't available for C#?
Question 2: Where do I find the tools for code generation that correspond to the version I got from NuGet (that is, Antlr 4.3)?
We attempted using antlr-4.4-complete.jar for code generation - we substituted that jar for the previous (antlr4-csharp-4.0.1-SNAPSHOT-complete.jar) in our build script and now we get: "error(31): ANTLR cannot generate CSharp_v4_5 code as of version 4.4" (which we didn't get previously). We also tried antlr-4.3-complete.jar and got similar results.
What do we need to take advantage of the latest release?
First of all, I corrected the link to the Readme.md in the release notes. Thanks for pointing it out, although a more reliable way to notify the maintainer is to file an issue directly for the project.
Second, the C# target is not based on the version of ANTLR posted on antlr.org, but instead on a fork of the project I created to optimize performance and (especially) memory overhead associated with parsing highly complex grammars. The tools use different serialization formats and are not interchangeable.
The C# code generator is distributed via NuGet, as described in the readme file.
ANTLR 4.4's primary differences over ANTLR 4.3 are the following:
Inclusion of additional targets (irrelevant for the C# target, since the runtime libraries are not C# and also use the other serialization format)
A bug-fix in the tool that has minimal effect on users (it throws an exception instead of reporting an error at code generation time for a specific type of grammar error)
Fixes a bug that occurs when an unknown target is specified (also not applicable to the C# target, since the MSBuild integration automatically selects the correct target language)
Based on this, the 4.3 release of the C# target is functionally equivalent to 4.4. I'm waiting to release a "4.4" version until I can address other performance concerns and functionality which doesn't apply to the reference version. In particular, I'm working on the following:
Improving concurrency by reducing contention (sharwell/antlr4#13)
Supporting indirect left recursion (currently a work-in-progress in the indirect-lr and java8-grammar branches)
Supporting a new baseContext option, shown here for a Java 8 grammar
Related
I'm playing around with the Xcode 10 beta, and I noticed while doing compile-time checks of the Swift version number that projects with the Swift Language Version set to Swift 4 in their Build Settings are reporting as Swift 4.1.50 (betas 2, 3, and 4 do this; I didn't get a chance to test beta 1). This strikes me as... bizarre, to say the least. The current AppStore version of Xcode, Xcode 9.4.1, reports its version as Swift 4.1.2.
So... What happened to Swift 4.1.3 through 4.1.49? Or is this a bug that I should file? Or is the 50 significant in some way?
You can test this yourself with my test file, Swift Version Checker
According to Jordan Rose on the Swift bug tracker:
This is the least bad answer we could come up with, given that we may still release more 4.1.x versions if there's, say, a bad security vulnerability in one of them. (This has happened before.) We needed a version number that was greater than any existing 4.1 version, but still less than 4.2.
We did consider other ideas, but this is the one we went with for maximum compatibility. We at least won't have this problem in the future thanks to SE-0212.
So, what I take from this is that there might still have to be an actual 4.1 release sometime in the future, but that would just be a security patch atop 4.1.2, so the logical number for that would be 4.1.3. Meanwhile, the pseudo-4.1 Swift that the Swift 4.2 compiler can digest needs its own number that also reflects it's a dialect of 4.1, and their conclusion was 4.1.50, which is safely far enough away from 4.1.2 to allow for as many security patches as they want.
Groovy added the --indy option in version 2.0, back in 2012. It wasn't the default at the time because invoke dynamic required Java 7, and many people at the time used Java 6.
Now even the forthcoming Groovy 3.0 still requires the --indy option in order to force it to use invoke dynamic. That's in spite of the fact Groovy 3.0 requires Java 8 or later.
Is there any technical advantage in still having the default be non-indy compilation, and the default run-time libraries being non-indy? I would have thought there's no need to even have a non-indy option nowadays.
Having --indy by default is on the roadmap for Groovy 3.0 (currently in alpha). The team wanted feedback on the new parser so didn't wait for all features to be available before releasing alpha versions.
The Groovy 3.0 compiler will likely keep a non-indy option of some kind available for a version or two to assist people wanting to recompile old libraries and produce like-for-like bytecode.
Currently, there are some primitive handling optimisations in play when producing non-indy bytecode. Very early benchmarks (on quite old JVMs now) showed some performance regressions since the indy bytecode didn't have those same optimisations. Also on the roadmap for 3.0 is to re-look at performance in those specific cases with a view to considering possible optimisations if still needed.
Exact specifics of whether some non-indy jars will be required for a version or two depend on some other parallel changes to remove some legacy classes that aren't really needed for the indy case but which would be required for all existing libraries written in Groovy to run. That will be detailed in the documentation and release notes once finalised.
There are some more details in [1].
[1] http://groovy.markmail.org/thread/yxeflplf5sr2wfqp
According to swift.org/migration-guide, dispatch and related functions have a great new swift interface (e.g. dispatch_async -> DispatchQueue.async). Also other foundation types have been added like Data and Date value types instead of NSData and NSDate.
However, on the open source version of swift3 (developer preview 1) on linux, ubuntu15.10 the compiler rejects all of these changes. In fact, looking at the open source version of swift and swift-corelibs on github, I don't actually see any of these changes. Since it will compile on XCode developer preview, this has lead me to believe either: I am doing something wrong on Linux or these changes have been made in the Apple branch and not the open source branch. Can anyone verify this and if the latter is the case, and if so, how do we know what changes will be in the Apple branch vs the open source branch?
As of Swift 3.0 release version GCD is available on Linux with simple import Dispatch, which is slightly confusing as it's not needed on iOS/macOS, where Dispatch module is imported by default.
Thanks to Brad Larson for finding the Foundation and Dispatch overlays in the source. According to swift.org:
SDK Overlays: Specific to Apple platforms, the SDK overlays
(implemented in stdlib/public/SDK) provide Swift-specific additions
and modifications to existing Objective-C frameworks to improve their
mapping into Swift. In particular, the Foundation overlay provides
additional support for interoperability with Objective-C code.
tl;dr anything in these folders are Apple platforms only. Still not sure why they restricted the Dispatch overlays to Apple Platforms since libdispatch is also open source and targeting linux, but this answers my initial question.
Edit: was able to confirm via swift mailing lists that the dispatch overlays do have some reliance on objective-c runtime. There is work to get them implemented for non-Darwin platforms but no guarantees on timing.
Check out the Swift 3 Evolution Github page. They list all the proposed changes to the language, and separate them by those that have been implemented and those that have not. Proposal SE-0088: Modernize libdispatch for Swift 3 naming is on the "yet to be implemented list" as are many other changes.
As far as Data and Date are concerned, I cannot say, since I believe that is part of the upcoming Core Libraries, and I have not yet been able to look at those in great detail yet. Perhaps you might check the Swift Core-Libs Github page as well, though the status page references work done on NSData and NSDate, no mention of the newer data types.
Currently I need to resort in a sparse solver for a project. However I use an old version of Eigen3 on Ubuntu 12.04 (during the thesis I avoid unnecessary updates/upgrades), which means that all the information that I find online cannot be used at the moment because of my outdated version, while the few unsupported tools of my version are very hard to use (weird compilation errors - e.g. with unsupported/Eigen/SparseExtra)
I think that I should upgrade to the last stable version, however it is very critical that I will be able to replicate the numbers of all the experiments that I got with the current outdated version. Is Eigen safe when it comes to backwards compatibility?
Eigen is also a dependency for PCL that I'm using, so I'm not sure if this complicates things. Everything is installed with apt-get. Linking to a new version of Eigen locally for experimentation is not possible, because PCL complains and expects to find Eigen installed globally (i.e. in /usr/local/include).
Eigen is source (API) and binary (ABI) backward compatible (of course, except for unsupported/*). However, the numerical results might be slightly different due to different rounding errors, but that's already the case when, e.g., enabling/disabling SSE or OpenMP.
Since Eigen is header only, it is very easy to try the newest version.
I've been playing around with Direct3D 11 a little bit lately and have been frustrated by the lack of documentation on the basics of the API (such as simple geometry rendering). One of the points of confusion brought on by the sparse documentation is the (apparent) move away from the use of effects for shaders.
In D3D11 all of the effect (.fx) support has been removed from the D3DX libraries and buried away in a hard to find (sparsely documented, of course) shared source library. None of the included examples use it, preferring instead to compile HLSL files directly. All of this says to me that Microsoft is trying to get people to stop using the effect file format. Is that true? Is there any documentation of any kind that states that? I'm fine doing it either way, but for years now they've been promoting the .fx format so it seems odd that they would suddenly decide to drop it.
Many professional game and graphics developers don't use the effects interfaces in Direct3D, and many of the leading game engines do not use them either. Instead, custom material/effects subsystems are built on top of the lower-level shader and graphics state state management facilities. This allows developers to do things like target both Direct3D and OpenGL through a common asset management pipeline.
The main issue is that the fx_5_0 profile which is needed to compile Effects 11 shaders with the required metadata is deprecated by the HLSL compiler team. The runtime is shared-source, but the compiler is not. In the latest D3DCompiler (#47) it emits a warning about this. fx_5_0 was never updated for some newer language aspects in DirectX 11.1 and 11.2, but works "as is" for Direct3D 11.
The second issue is that you need D3DCompile APIs at runtime to make use of Effects 11. Since D3DCompile was 'development only' for Windows Store apps for Windows 8.0 and Windows phone 8.0, it wasn't an option there. It is technically possible to use Effects 11 today with Windows Store apps for Windows 8.1 and Windows phone 8.1 since D3DCompile #47 is part of the OS and includes the 'deprecated/as-is' compiler support for fx_5_0, but this use is not encouraged.
The bulk of the DirectX SDK samples and all the Windows Store samples avoid use of Effects 11. I did post a few Win32 desktop samples that use it to GitHub.
UPDATE: With the release of the legacy Microsoft.DXSDK.D3DX NuGet repacking of the original D3DX #43, I was able to update the rest of the legacy DirectX SDK samples so they can build with the modern Windows SDK and not require the legacy DirectX SDK to be installed. Most of the Direct3D 9 and Direct3D 10 samples, and a few Direct3D 11 samples, all use legacy Effects. See GitHub.
So in short, yes you are discouraged from using it but you still can at the moment if you can live with the disclaimers.
I'm in the exact same position, and after Googling like crazy for even the simplest sample that uses D3DX11CreateEffectFromMemory, I've too come to the conclusion that .fx file support isn't their highest prio. Although it is strange that they've added the EffectGroup concept, which is new to 11, if they don't want us to use it.
I've played a little with the new reflection API, so it looks like it will be pretty easy to hack together your own functions for setting variables etc, in essence creating your own Effect-class, and the next step is going to be to see what support their is for creating render state blocks via the API. Being able to edit those directly in the .fx file was very nice, so hopefully something like that still exists (or, at worst, I can rip that part from the Effect11 code).
There is an effect runtime provided as a sample in the DirectX SDK that should be able to help you to use .fx files.
Check out the directory: %DXSDK_DIR%\Samples\C++\Effects11
http://msdn.microsoft.com/en-us/library/ff476261(v=VS.85).aspx
This suggests that it can take a shader or an effect.
http://msdn.microsoft.com/en-us/library/ff476190(v=VS.85).aspx
Also, what is the difference between a shader and an effect?