Coworkers have a lot of old-fashion gnuplot scripts working fine with gnuplot 4.1. It would be neat to update to 4.6 to get the for-loop functionality and the beauty of new terminals.
Have you ever faced compatibility issue while updating gnuplot ?
Is there something to add to ~/.gnuplot to ensure backward compatibility ?
Thank's for your help, I have to convince coworkers that this is a safe transition.
Note :
A change of behavior is described in (gnuplot script fails - has there been a change in defaults from 4.4 to 4.6) column header. This is an examples of troubles you may have encountered, that kind of glitch I have to take into account and warn people about.
The amount of effort to update the scripts really depends on how many tricks your coworkers use which exploit bugs that were later patched in gnuplot. In my experience (almost) anything that works in gnuplot 4.0 works in 4.6/4.7, just not the other way around.
Related
I have a code running in Node 9.8
Node 9 will reach End-of-life soon.
If I switch to node 10, how can I check if my code will run in node 10 without having to execute all paths of the code ?
Or if I go down to 8.11, how can I check if my code will run in node 8.11 ?
There is no test cases written on the code.
This is a good example of why solid unit/integration tests are critical to long-term maintainability. That said, there are a few steps you can take to reduce the risk of breaking things:
Take a look at the change logs pertaining to the versions you're moving to/from. The NodeJS team kindly includes a Notable Changes section in each change log, though I wouldn't rely on that alone as being 100% inclusive of the potentially breaking changes you may be up against.
Consider writing unit/integration tests, both as part of your assurance that things won't break from this version change, as well as that things won't break from later version changes (or everyday changes for that matter).
As much as I hate to say it, Googling around for guides on upgrading (or downgrading?) NodeJS versions may help you identify potential danger zones.
Generally, I'd consider it safer and better practice to upgrade the version than downgrade. For one, you're moving forward to the newer and greater experience the NodeJS team wants you work with, and secondly, future versions are probably more likely to be backwards compatible, whereas the old version may be missing features you're using.
I think it's not recognizing the fat arrow function. It complains like this:
Only when I modify my code from (err, stats) => { to function(err, stats){ then the error disappears.
Is there a way to fix this or my only option is to supress this type of errors?
Didn't know that people still use Netbeans, but Netbeans doesn't support ES6 syntax yet, but it might be close according to one of the comments:
Guys, I have to apologise. The parser based on Antlr doesn't suffer from performance problems like a month ago, but the memory consumption is still high. We run in problems in ANTLR 4 runtime itself and we are working with antlr authors to solving these issues. I can not guess what time it will take.
In parallel I have taken a close source parser and currently I'm
trying to work with this one. Unfortunately it's close source and we
have to go through licensing process, where I don't have any doubts
how it long it can take. When I get the permission to put the parser
to our hg, then there will be available build and hopefully with a few
implemented ECMA 6 features.
Netbeans 8.2 now supports ECMA6 syntax https://netbeans.org/community/releases/82/relnotes.html#new
I just disabled haskellmode-vim from my plugin configurations. Basically this was for three reasons:
I prefer neocomplcache for my auto completion needs.
Apparently it wasn't updated since 2010.
It doesn't seem to be compatible with cabal
I hope that someone jumps in the pit and points out that I just have misconfigured the whole thing (as in I configured the most basic thing in the readme). To make this a question:
Is it possible to setup haskellmode such that ...
... it gets its configuration from cabal?
... it doesn't set `completefunc' so that neocomplcache still works?
Author here. I haven't had much chance to work with Haskell since 2010, so haskellmode for Vim has not been developed since then, either.
I used to think someone must have written something better since, or that my old code probably doesn't work with newer releases, but every few months, someone mails me telling that they are still using this plugin and it still works for them (which is a mix of pleasant surprise and uncomfortable reminder of the lack of development/maintenance).
Some of them have created clones on github (last time I checked, there were about a dozen), usually to accomodate the latest fashion in Vim plugin management (there may have been small hacks to make it build via cabal, but I recall no complete integration). Vim gives you a lot of control over the order of plugin loading, if you want someone else to override the completefunc.
I still expect haskellmode-vim to drop out of usage sooner or later. However, if someone were to step forward willing to take on maintenance for one of the github clones, that would be fine, too.
As long as credit is given, and modified plugins are marked as such, I'm also happy to see ideas from haskellmode-vim used in other plugins (there used to be a happy exchange of such ideas between vim and emacs haskell plugins), so more modern and active plugins could absorb any missing features from haskellmode-vim.
I tried the following code which works fine in the Windows CLR:
System.Diagnostics.Process.GetCurrentProcess().Threads.Count
... resulting in something > 0.
However under Mono on OS X or Linux it always results in 0
Is this a bug in Mono or do I need another approach because of platform differences?
Going straight to the source, it appears that it's not exactly a bug, but is instead completely unimplemented (note the [MonoTODO] attribute on this method).
Your best course of action would be to open a bug against Mono on Xamarin's bug tracker. It's probably not terribly hard to build this, and it seems like someone on the project may be ashamed enough that this isn't done that they'll fix it quickly.
If you need this to work in the meanwhile, I've got a branch on github that implements a fix for this. I'll work with the Mono folks to see whether/how they want to integrate it.
Update: It has been pulled into the master branch of Mono.
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?