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
Related
So I've recently started using Typescript. Both for the back end (nodejs) and front end, and I'm started to feel an urge to chew on my own arm every time I have to add a new import.
Coming from the .NET world the last 15 years I've come to appreciate the more or less automatic type resolving. Especially with a background in C/C++, which whenever I return to, remind me of the #include hell that ever so often becomes the case. Given what I am now facing, I get a feeling of "those were the days".
I typically prefer to keep my code as one class -> one file (with some obv exceptions for smaller stuff). This results in a lot of files and even more imports. I recently discovered some tools that help out creating the imports but it is still really annoying.
I get it that the underlying JS needs these imports (in various ways depending on module system) But given how easy these tools resolves the imports. Would it not be possible for the compiler to simply generate them? In the rare case of ambiguity the compiler would simple give an error and the user needs to resolve it manually.
Typescript seems to be a great language otherwise but this is really close to a deal breaker for me. Or am I missing something? Can this be done in a better way?
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
As you know if you've read some of my other questions, I'm writing a programming language. One of my big concerns is that many languages have troubles with backwards compatibility, and I wish to avoid such issues. On one hand, I've seen a lot of pain and agony in the Python community over the switch to Python 3000 because it breaks backwards compatibility. On the other hand, I've seen C++, which started off shackled to C syntax and has never really recovered; i.e. the syntax of C is a poor fit for many C++ constructs.
My solution is to allow programmers to add a compiler directive to the file which will tell the compiler which version of the language to use when compiling. But my question is, how do other languages handle this problem? Are there any other solutions that have been tried, and how successful were those solutions?
When something is broken, the courageous language designer must not be afraid to break backward compatibility. I know of two good ways to do it:
The Glasgow Haskell Compiler typically deprecates unwanted features and then drops support after two versions.
The Lua team have a policy that each major release (there have been 5 since 1993) may break backward compatibility, but they typically provide a compatibility layer that helps users migrate to the latest version. (Plus they are scrupulous about keeping everything available; the current version is 5.1 but I have Lua 2.5 code that I still maintain, and if I find a bug in Lua 2.5, they will fix it.)
Easy : Deprecation
When new methods or functions are available, they don't simply eliminate the old ones. They just deprecated them. So, developers working on new compilers know that at some point they will need to use the new versions of those functions or in the future their program won't compile. In that way they are 'backward compatible' but at the same time enforcing the usage of the new functionality.
I think you're on the right track with a compiler directive. It's may be better to package that as a command-line argument to your compiler though.
No matter what, in your compiler logic you can test against the version something like this:
if ( language_major_version > 2 ) // 2.00.00 and above
... normal processing ...
else
... emit compatibility/deprecation error ...
VoiceXML, an XML-based language for specifying voice dialogs, is one example of putting the directive in the source code:
<?xml version="1.0"?>
<vxml version="2.1">
...
</vxml>
Since the syntax is always well-formed XML, this is really easy to implement, almost cheating,
I'm going to be the really harsh sobering voice and say: You're never going to have enough users for it to matter. Sorry, but the statistics are against you.
In the unlikely event that it does become a problem, these are the strategies I've seen used for this problem
Don't worry about it and just break backward compatibility
Keep old versions of the interpreter packaged in with the new versions and switch using some directive, or other kind of metadata
Make new versions a strict superset of old versions. That way, all old programs compile in the new version of the compiler/interpreter
Provide a converter to convert old style programs to new style programs.
Base the language on a virtual machine that accepts bytecode compiled from any version of the language. Ensure that there are facilities for different versions to "talk" to eachother.
Compromise and end up pissing everyone off instead of just half of your audience
New versions have a loose mode by default and a "strict" mode, the former being strictly backwards compatible, the latter removing old and busted features for those who opt in.
The good news is that none of these strategies work extremely well, so you have the opportunity to be creative and mess up in a novel new way.
Generally speaking you continue to support all the old features for at least one new version though preferably two versions into the future. Then the feature is depreciated and it is up to the user of your language to update their applications prior to the feature being dropped from your language.
I forgot one other way that languages have dealt with backward compatibility: Stubbornly insist on never updating the language. See Donald Knuth's TEX for an example of this.
So, I got this idea that I'd try to prototype an experimental user interface using OpenGL and some physics. I know little about either of the topics, but am pretty experienced with programming languages such as C++, Java and C#. After some initial research, I decided on using Python (with Eclipse/PyDev) and Qt, both new to me, and now have four different topics to learn more or less simultaneously.
I've gotten quite far with both OpenGL and Python, but while Python and its ecosystem initially seemed perfect for the task, I've now discovered some serious drawbacks. Bad API documentation and lacking code completion (due to dynamic typing), having to import every module I use in every other module gets tedious when having one class per module, having to select the correct module to run the program, and having to wait 30 seconds for the program to start and obscure the IDE before being notified of many obvious typos and other mistakes. It gets really annoying really fast. Quite frankly, i don't get what all the fuzz is about. Lambda functions, list comprehensions etc. are nice and all, but there's certainly more important things.
So, unless anyone can resolve at least some of these annoyances, Python is out. C++ is out as well, for obvious reasons, and C# is out, mainly for lack of portability. This leaves Java and JOGL as an attractive option, but I'm also curious about Ruby and Groovy. I'd like your opinion on these and others though, to keep my from making the same mistake again.
The requirements are:
Keeping the hell out of my way.
Good code completion. Complete method signatures, including data types and parameter names.
Good OpenGL support.
Qt support is preferable.
Object Oriented
Suitable for RAD, prototyping
Cross-platform
Preferably Open-Source, but at least free.
It seems you aren't mainly having a problem with Python itself, but instead with the IDE.
"Bad API documentation"
To what API? Python itself, Qt or some other library you are using?
"lacking code completion (due to dynamic typing)"
As long as you are not doing anything magic, I find that PyDev is pretty darn good at figuring these things out. If it gets lost, you can always typehint by doing:
assert isinstance(myObj, MyClass)
Then, PyDev will provide you with code completion even if myObj comes from a dynamic context.
"having to import every module I use in every other module gets tedious when having one class per module"
Install PyDev Extensions, it has auto-import on the fly. Or collect all your imports in a separate module and do:
from mymodulewithallimports import *
"having to select the correct module to run the program"
In Eclipse, you can set up a default startup file, or just check "use last run configuration". Then you never have to select it again.
"before being notified of many obvious typos and other mistakes"
Install PyDev Extensions, it has more advanced syntax checking and will happily notify you about unused imports/variables, uninitialized variables etc.
Looking just at your list I'd recommend C++; especially because Code Completion is so important to you.
About Python: Although I have few experience with OpenGL programming with Python (used C++ for that), the Python community offers a number of interesting modules for OpenGL development: pyopengl, pyglew, pygpu; just to name a few.
BTW, your import issue can be resolved easily by importing the modules in the __init__.py files of the directory the modules are contained in and then just importing the "parent" module. This is not recommended but nonetheless possible.
I don't understand why nobody has heard of the D programing language?
THIS IS THE PERFECT SOLUTION!!!!
The only real alternative if you desire all those things is to use Java, but honestly you're being a bit picky about features. Is code completion really that important a trait? Everything else you've listed is traditionally very well regarded with Python, so I don't see the issue.
The text editor (not even an IDE) which I use lets you import API function definitions. Code completion is not a language feature, especially with OpenGL. Just type gl[Ctrl+I] and you'd get the options.
I tried using Java3D and java once. I realized Java3D is a typical Java API... lots of objects to do simple things, and because it's Java, that translates to a lot of code. I then moved to Jython in Eclipse to which cleaned up the code, leaving me with only the complexity of Java3D.
So in the end, I went in the opposite direction. One advantage this has over pure python is I can use Java with all of Eclipse's benefits like autocomplete and move it over to python when parts get unwieldy in Java.
It seems like Pydev can offer code completion for you in Eclipse.
I started off doing OpenGL programming with GL4Java, which got migrated to JOGL and you should definately give it (JOGL) a try. Java offers most of the features you require (plus Eclipse gives you the code completion) and especially for JOGL there are a lot of tutorials out there to get you started.
Consider Boo -- it has many of Python's advantages while adopting features from elsewhere as well, and its compile-time type inference (when variables are neither explicitly given a specific type or explicitly duck typed) allows the kind of autocompletion support you're asking about.
The Tao.OpenGL library exposes OpenGL to .NET apps (such as those Boo compiles), with explicit support for Mono.
(Personally, I'm mostly a Python developer when not doing C or Java, but couldn't care less about autocompletion... but hey, it's your question; also, the one-class-per-module convention seems like a ridiculous amount of pain you're putting yourself through needlessly).
So my company uses a delightfully buggy program called Rational Purify (as a plugin to Microsoft Visual Developer Studio) to manage memory leaks. The program is deigned to let you click on a memory leak after you have encountered it, and then jump to the line that the leak occurs on.
Unfortunately Purify is malfunctioning and Purify will not jump to the place that the leak occurred it only mentions the class and method that the leak occurs in. Unfortunately, sometimes this is about as useful as hiring a guide to help you hunt bears and having him point to the forest and tell you there are bears there.
Does anyone with Purify experience have any idea how I might fix this problem or have a good manual to look though?
Generally you have two options, one exclude modules DLL's from instrumentation in Purify, it helps some times. Second is get BoundsChecker, this does compile time instrumentation much slower but the level of detail is an order of magnitude better.
We generally use Purify on check-in, sanity checking, and BoundsChecker when we know a bug/crash exists.
BoundsChecker has some nice features like only instrument files A.cpp & B.cpp, excluding all the rest.
Be aware neither of these two applications function on 64 bit operating systems, and BoundsChecker will not install on 64 bit OS. Most frustrating if you make the switch to native 64 bit development with 32 bit back port!
Purify is like a swiss knife. If you know how to use it, you will get some results, not the best but still results. If you don't, it will crash, because it is just another program running on Windows.
In the end you will need a lot of patience, rebuilds and a bit of luck.
Purify comes with a script called ScanVSSolutionForPurifyPlus.pl which will ensure that your project files have all the right settings for Purify to work properly. If you haven't run it, give it a go.
(I've personally used ScanVSSolutionForPurifyPlus.pl on a large solution, and it worked like a charm. One caveat: when you give it the name of your .sln file, you might need to give it the full pathname.)
Are you sure you have debug build? Or rather you have all PDB's enabled? Try WindDbg on your executable and check with !lmi command what is visible.
Is whole code properly instrumented?
Also consider using something else like free Visual Leak Detector or Microsoft's tool LeakDiag.
I used Purify about 5 years ago. It was really flaky then. They kept promising to fix all the bugs in the 'next release'. We gave up on it in the end. One can only wonder if they used their own QA tools on their products. Oh the irony...