I'm working with a large json file.
This json has been parsed by myself using Python, and (as a result) there are some json validation errors at different points in the file. I want to identify these errors in order to improve my Python parser.
Sublime text (2) helpfully highlights in pink formatting errors in the json, however working my way through 70,000,000 lines of json to find these errors is somewhat challenging.
Is there any way to skip to pink highlighted errors in the json?
(Note: the json file is sufficiently large that trying to use an online validator for example is not possible)
Thanks!
This can be done in a fancy way using a plugin, but for your purposes probably the best way is to just enter a command into the console. Open your JSON file with errors in it, then open the console with Ctrl`. Paste in the following code and hit Enter:
view.show_at_center(view.find_by_selector("invalid.illegal")[0])
and the view will scroll to show the first error in the file. Fix that error, click back on the console entry line, hit the up arrow to bring back the command you just ran, and hit Enter again, and it should scroll to the next error, and so on. When there are no more errors, you'll get IndexError: list index out of range printed to the console, and the view won't scroll any more.
While this will work in both Sublime Text 2 and 3, I strongly urge you to upgrade to ST3 if at all possible. ST2 has been shelved and deprecated, and there will be no more bug fixes released. Development is now focused solely on ST3 (as well as being in the planning stages for ST4!). "I don't know of any good reason to not use Sublime Text 3" - Will Bond, ST core developer.
There are a ton of new features and bug fixes in the new version, even if you're just using the public beta. (BTW, don't let the word "beta" fool you - the program is rock solid, and has been for years.) If you want more cutting-edge features, and are a registered user (which you should be if you are using the program long-term or for commercial purposes), you can download the dev builds which are updated more frequently, but run the slight chance of having an undetected bug or two.
One of the major advantages of ST3 is that it now supports a new, YAML-based sublime-syntax highlighting engine, which allows for much greater flexibility than the old .tmLanguage highlighting files (which are still supported). Related to that, the syntax files have all been open-sourced and development is proceeding very rapidly on them, even though it's been a few months since the last build was released.
Probably the biggest reason to upgrade is the plugin community. The internal Python API has been updated to Python 3 (3.3.6, to be precise), which had the side effect of making many old plugins incompatible. Except in a few rare cases, most plugins now support ST3, and many are dropping ST2 support by the wayside as it becomes too difficult to maintain two codebases, as well as trying to develop with the much more limited API ST2 provides. So, unless you absolutely depend on an old ST2-only plugin that can't be ported, upgrading is definitely the best path to take.
I am trying to install this VHDL highlighting package for my Sublime Text 2.
I already installed the elusive Package Control following the instructions here.
But when I search for the package within Ctrl + Shift + P, the package doesn't show up!
What do I do? According to the plugin's page, it should work for Sublime Text 2.
The plugin's description is out of date. If you look again at the plugin's Package Control page, you'll see an ST3 icon at the top, just to the right of the author's name. So, you'll need to upgrade to ST3 to use it, and I strongly suggest upgrading anyway. Even though ST3 is still labeled as a "beta", it's rock-solid and a great improvement over ST2 in a number of ways, not the least of which is an improved API that allows for all these great ST3-specific plugins. I've been using it exclusively for well over two years now without major issues.
Cocos2d-x 3.0 alpha was released for some time now. What was improved over cocos2dx-2?
The features list is quite important, but in terms of performance are there new limitations/improvements?
Have you noticed real improvements in performance, development patterns, APIs and support?
I've been using it recently and from what I've noticed the main differences are that everything is namespaced now, so you don't have to deal with the prefixed names that came from the objective c patterns, so cocos2d::Point instead of CCPoint (especially for enums, (Texture2D::PixelFormat::RGBA8888 instead of kCCTexture2DPixelFormat_RGBA8888)).
Also some of the event stuff now has support for c++11 lambdas.
A more complete list of the changes can be found here: http://www.cocos2d-x.org/wiki/Release_Notes_for_Cocos2d-x_v300
but for the most part of using it myself, it's just made to feel more like C++, instead of like objective-c.
I have switched and am finding it pretty stable. The main advantages so far ...
Real buttons, instead of menus
Real-time spritesheets
SpriteBatchNodes are no longer recommended and I did see a drop in draw calls where I not optimized
less objective C patterns.
more modern. namespaced instead of 'CC'. C++11.
more platforms supported
Main disadvantages for me:
EventListener pattern. I can't figure out how to get touch input to affect any objects other than the Node that triggered the event.
We use a lot of text-only buttons for debugging and they are hard to lay out :)
Lack of documentation and example code. For example, I could not find any documentation of how to use the Layout class anywhere.
It is a lot of work porting, but for us we had to decided to risk it since we would end up maintaining an out-of-date code base. It took about 5 person-days to port our game over. The game is now stable and we did not run into a single bug in cocos.
I think its C++11
auto
lambda
And it has no unnecessary use of prefix CC
One of the changes that happened between Cocos2d-x 2.1.5 and 2.2 was the removal of templates for projects in XCode (I do not know if project templates existed in VS, etc).
The new build system creates projects under the Cocos2d-x installation (at least on Mac) and that is where the project files appear to reference them. This makes it very difficult to move the project without hand tweaking. It also makes configuration management more painful, depending on how you set up your system (e.g. a root/tree like svn or a "drop it anywhere" like git).
Also, the Cocos2d-x library is built as that, a library. In previous incarnations, it was placed directly into the project. On one hand, if you don't alter the root library code, this makes good sense. On the other hand, if you occasionally tweak things for a specific project, you have altered all your projects that depend on it. Yin/Yang.
I'm still very positive on Cocos2d-x. I have not upgraded to 3.0 or 2.2 yet. When it matures a little more, I will switch over, regardless the changes. For what I need, I'm pretty sure it will still get the job done (well).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What tweaks / addins / themes do you have rigged up to make your IDE awesome? For example, in Visual Studio I color themes, CodeRush draws lines between braces, I always install and use the Consolas font and I have it setup to sync my settings across computers for when I change hotkeys and whatnot with the help of FolderShare.
Also, this isn't Visual Studio specific, please feel free to mention what you do with Emacs or Eclipse or whatnot as many of us use a few.
ReSharper 4.1 for Visual Studio 2008. It's a beautiful thing. It looks for all kinds of code errors, optimizations, etc. My code is cleaner thanks to this handy Visual Studio plugin.
Optimizing the IDE will be the first step. Resharper helps a lot but sometimes some simple macros are more than enough.
First things first. Change the font from the default crappy one. Then start fiddling with the 'Options' dialog box.
At the recommendation of a friend, I installed Visual Assist for Visual Studio 2008 -- it is awesome. I swear it can read my mind.
[Note: I have no affiliation with them -- just a very happy customer]
I've done a lot, but I really shouldn't have. So in the last few years, I've toned down the number of macros, custom key mappings, custom toolbars, etc. For the most part, I'm of the opinion that developers should get used to the default behavior and appearance of their IDE. Then when you need to work on your colleague's machine, you still know how to get around and manage to help them out. Not to mention that a whole slew of customizations will get broken or rearranged or otherwise reset when an update comes out.
That said, there are a few things that I still do every time I set up an IDE to work on... for example, setting the number of concurrent builds in Visual Studio to be 1, because that feature is so broken that nothing will compile correctly with any greater setting. Apart from that, being an ace with the default behavior will ultimately make you more efficient than spending hours tweaking the software to make it just a little more fluid.
I like CodeSmart VB6 and CodeSmart VS.NET from Axtools http://www.axtools.com/
for advanced syntax highlighting, drawing lines between parts of If..then..else..endif, Do While ... loop and all other constructs. It also has great code auditors and many add-in functions.
Vi plugin!!
I use Emacs. My .emacs file is only a few hundred lines long, but does customize settings based on my machine's hostname and operating system, so that I can use the same config file pretty much anywhere.
Colorization - Custom - White Text on GreyishBlack, Consolas Font
HotKeys - CTRL+SHIFT+ALT+Z (Attach to Process) probably some others too...
Addins - DPack, Coderush, GhostDoc.
Toolbars Off
All Windows set to collapsed
I am not doing presentations with this machine - If I was it would be barebones.
eclipse plugins make my ide exactly the way I want it of course.
eclipse plugin central
I kinda like the default setup of VS, I only make sure about Consolas as the editor font, and tabsize 2 (tabs to spaces), and change the color of numbers (red).
For Java development using Eclipse I have a few plugins that are indispensable. The MyEclipse Workbench adds a lot of functionality to most of the built-in modules. It makes it very easy to deploy an application to multiple application servers, and enhances a lot of the built-in editors. The PMD plugin is great for searching for potential code issues. As mentioned in a previous post today, the Ganymede plugin really helps to highlight log entries.
I dont care much for fancy visual addons, so I left my IDE (Visiual Studio) in the standard look (other than MS Reference Sans Serif font).
I usually change the color scheme to have a black background instead of white.
I use the Zenburn color scheme with Proggy Clean for a font. It's like a comfy chair for my eyes.
Nothing. I hate dealing with all the breakages that inevitably result from updates, etc. So, I adapt myself to my IDE instead.
I've using a combination of ViEmu and ReSharper with a dark theme.
Oh, and I also hide most of the toolbars and turn off the animations to try to speed things up.
Silver background, 8pt Consolas, disable all toolbars and set tab spacing to 3 spaces. :)
For Visual Studio
Most important - Resharper - I bought my own copy so I don't have to badger my employer about it.
Change the colourisation/font - choose whatever suits you
Optimisation (vote up Gulzar's post with the link in it)
Don't try and make the IDE do everything, just because you can. (Kind of ironic seeing I use emacs as well). I personally really dislike integrated source code management.
Change some defaut file associations so double clicking certain file types doesn't kick off Visual Studio
Aside from Resharper I've actually found most other beneficial thing is not customising the IDE, but customising yourself to learn the keyboard shortcuts. Start with the big gains like Ctrl -, Ctrl Shift -, Ctrl Shift V, Ctrl Alt L etc. etc. and then gradually learn the rest of the shortcuts in order of how often you'd use them
Rather than customizing the IDE, I customized my error messages. I have a macro that expands to a #pragma warning statement that generates a compile-time message in the same format as MSVC++. Visual Studio can parse the resulting warning, so a double-click on the message opens the offending file in the IDE and takes me right to the line in question.
I've used the macro:
To "bookmark" a section of code, so developers will be nagged to fix it each time they build.
Within #if blocks to test for various compile-time conditions.
In headers, to see who #includes them, and where.
From vim you can set the makeprg (make program) variable to a command that will build your project, and the errorformat variable to a scanf-style string that describes the format of the build errors. From there:
:make will build your project
:cl lists all of the errors that match errorformat
:cc takes to you the current error
:cn takes you to the next error
:cp takes you to the previous error.
Out of the box, vim sets makeprg and errorformat to work with make and gcc, and all of the commands are documented within vim's built-in help.
I do Java development in Eclipse. Here are some of the plug ins I find useful:
Mylyn - hides project elements not relevant to the current context.
eUML2 - UML editor.
FindBugs - Static analysis tool to find common bugs in Java.
Crap4J - Another static analysis tool.
EclEmma - Code coverage plug-in for unit tests.
Edit: I forgot one:
Disable the spellchecker. :)
In visual studio 2005 I do these:
Bind F11 to fullscreen mode
Enable a vertical line at 80 characters: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\Text Editor\Guides = "RGB(196,196,196) 80" (Guides won't be present in the registry.)
Add the "Start Debugging", "Break All" and "Stop Debugging" buttons after the "Help" menu.
I am using Vim Cscope plugin.
Cscope is like 'ctags' on steroids and makes traversing code much easier.
I usually use it along with tags to find where a function is declared and then go directly to whatever code is calling this function.
I also use Vim's Rgrep plugin (recursive search) to search for files in the code hierarchy.
Create some basic macro such as printing bug fix code comments:
Public Sub WriteBugFix()
Dim TS As TextSelection = DTE.ActiveDocument.Selection
TS.Text = "'Edited for Bug Fixed By JK - " & Date.Now.ToShortDateString
End Sub
(This answer assumes the workstation is a GNU/Linux computer.)
Emacs makes an excellent IDE specifically because it can be greatly customized.
You customize Emacs by editing the .emacs file in your home directory. My .emacs is a symbolic link:
$ ln -s /home/bzimmerly/bin/emacs/emacs24/wbz.emacs.el .emacs
Since Emacs offers a variety of specialized major modes for program development and debugging, you can easily "roll your own" IDE design that works best for you. For example, when I'm programming in C or assembler, I like to have the left side running GDB mode, with the right side displaying the source being traced.
A little bit of LISP skill goes a long way to turning Emacs into a very powerful IDE. It is well worth the investment of time to learn how to use this powerful tool!
Finally, tools like Youtube are valuable places for learning how to do this. Just entering "Emacs as an IDE" on the Youtube search form will show videos of how people have modified Emacs for just such a purpose. There are videos on editing Python code, Javascript, Java, C, etc.
I am currently working on automating/improving the release process for packaging my shop's entire product. Currently the product is a combination of:
Java server-side codebase
XML configuration and application files
Shell and batch scripts for administrators
Statically served HTML pages
and some other stuff, but that's most of it
All or most of which have various versioning information contained in them, used for varying purposes. Part of the release packaging process involves doing a lot of finding, grep'ing and sed'ing (in scripts) to update the information. This glue that packages the product seems to have been cobbled together in an organic, just-in-time manner, and is pretty horrible to maintain. For example, some Java methods create Date objects for the time of release, the arguments for which are updated by a textual replacement, without compiler validation... just, urgh.
I'm trying avoid giving examples of actual software used (i.e. CVS, SVN, ant, etc.) because I'd like to avoid the "use xyz's feature to do this" and concentrate more on general practices. I'd like to blame shoddy design for the problem, but if I had to start again, still using varying technologies, I'd be unsure how best to go about handling this, beyond laying down conventions.
My questions is, are there any best practices or hints and tips for maintaining and updating versioning information across different technologies, filetypes, platforms and version control systems?
Create a properties file that contains the version number and have all of the different components reference the properties file
Java files can reference the properties through
XML can use includes?
HTML can use a JavaScript to write the version number from the properties in the HTML
Shell scripts can read in the file
Indeed, to complete Craig Angus's answer, the rule of thumb here should be to not include any meta-informations in your normal delivery files, but to report those meta-data (version number, release date, and so on) into one special file -- included in the release --.
That helps when you use one VCS (Version Control System) tool from the development to homologation to pre-production.
That means whenever you load a workspace (either for developing, or for testing or for preparing a release into production), it is the versionning tool which gives you all the details.
When you prepare a delivery (a set of packaged files), you should ask that VCS tool about every meta-information you want to keep, and write them in a special file itself included into the said set of files.
That delivery should be packaged in an external directory (outside any workspace) and:
copied to a shared directory (or a maven repository) if it is a non-official release (but just a quick packaging for helping the team next door who is waiting for your delivery). That way you can make 10 or 20 delivers a day, it does not matter: they are easily disposable.
imported into the VCS in order to serve as official deliveries, and in order to be deployed easily since all you need is to ask the versionning tool for the right version of the right deliver, and you can begin to deploy it.
Note: I just described a release management process mostly used for many inter-dependant projects. For one small single project, you can skip the import in the VCS tool and store your deliveries elsewhere.
In addition to Craig Angus' ones include the version of tools used.