Skip to main content

Wing IDE 3, Wing IDE 101 released

Wing IDE version 3 has been released.

The list of new features is a little underwhelming. Multi-threaded debugging and the unit testing tool (only supporting unittest -- does anyone still use that old module anymore?) are nice but I don't see myself paying to upgrade from 2.1 yet. Now if they could get the GUI to keep up with my typing in Windows, I'd pay for that... I guess this is a sign that Python IDEs are nearing maturity; Komodo 4 didn't have any earth-shaking new features either, at least as far as Python was concerned.

(Personally I think someone should start supporting django/genshi/mako templates already. Maybe in 3.1, guys?)

Following ActiveState's lead, Wingware has also released a completely free version, Wing IDE 101. The main difference is that where the most essential feature Komodo Edit leaves out as an incentive to upgrade is debugging, Wing IDE 101 includes the debugger but omits code completion. Wingware also continues to offer the low-cost Personal edition.

But the really big difference between Wing IDE 101 and Komodo Edit is that you can freely use Komodo Edit for paying work. Wing IDE 101, like Wing IDE Personal has a no-commercial-use clause. (Komodo versions compared; Wing versions compared.) I'm still of the opinion that at $180, Wing Professional will pay for itself in short order, but for the hobbyist, Komodo Edit is very compelling. I've been using it myself for TCL and XML editing for several months now and it's a nice little IDE.

Too bad Komodo's emacs bindings continue to suck balls -- I mean, it's one thing to not implement fancy things like a minibuffer or kill ring, but if you can't even get C-W (cut) right, there's not much hope. Users contributed much-improved Emacs bindings to the ActiveState bug tracker way back in the version 3 timeframe. I guess ActiveState just doesn't care.

Comments

Doug Napoleone said…
Don't forget about the probe debugger.

This is a python interactive session which dynamically switches context. Select the stack level in the debugger, and you can do anything in the session as if you were at that point in the code. Not exactly what I would call underwhelming.

Stephen gave out the reason for the slowness during a talk (audio).

Now if komodo would just stop locking up in the svn integration for no good reason, and failing to 'repaint' when you have many large files open.
7:10 PM
Jonathan Ellis said…
Since my toughest bugs have been impossible to reproduce in a debugger context, I just tend to be underwhelmed by debuggers in general. :)
7:35 PM
Jonathan Ellis said…
I found the audio in your link to be mostly unintelligible. So, do tell, what was the reason?
7:44 PM
Doug Napoleone said…
sorry about that. There is no difference in implementation of wing between windows, linux and mac osx. The issue appears to be latency in the main even loop in GTK. The Wing folks are active in the GTK community and are hoping to find the root problem, but it has been a long standing issue. This is second hand and partially paraphrased, so my apologies if I got anything wrong.
9:49 PM
Doug Napoleone said…
NOTE: the #1 reason I use an IDE is for the graphical debugging. If I don't have a need for a debugger, I just use emacs or vi equivalent as they have everything else, and are on all systems (even windows these days). Though I agree the toughest bugs can never be reproduced in a debugger. If they could, they wouldn't be that tough.
9:58 PM
Unknown said…
FWIW: Slowness on Windows sometimes seems like a result of a breakdown of using hardware acceleration for display, which we've seen with nVidia cards, and in particular with the nVidia display manager. That's usually a pretty severe slowdown, however, and may not be what you're seeing. But turning off any such display managers for Wing is worth a try.

Another thing to try is to change away from the default Display Theme to something w/o any pixmap eye candy.

Somewhat ironic, really, that our performance issues aren't in Python code. ;-)

Also, sometimes using a conditional breakpoint is a good way to get the Debug Probe to point at the particular case that's failing. At times, I've set one to catch a rare case I couldn't figure out, and suddenly days later hit it. Of course there's no guarantee we can bring out all your threading bugs, or anything where timing and luck play a role. ;-)

Thanks, in any case for writing about Wing and your impressions of the new release.
8:10 AM
Brandon Corfman said…
Regarding Komodo 4.2 improvements, the Python autocomplete took a big leap forward, although it's not completely perfect yet (grrr). I think ActiveState's resources get burned up supporting too many different languages under the one IDE.

However, Komodo now supports Firefox-style extensions in 4.x. So there are new Python extensions like kNose, which does unit testing with the nose library. (Shameless plug alert.)
6:54 AM
Post a Comment

Popular posts from this blog

The Missing Piece in AI Coding: Automated Context Discovery

I recently switched tasks from writing the ColBERT Live! library and related benchmarking tools to authoring BM25 search for Cassandra . I was able to implement the former almost entirely with "coding in English" via Aider . That is: I gave the LLM tasks, in English, and it generated diffs for me that Aider applied to my source files. This made me easily 5x more productive vs writing code by hand, even with AI autocomplete like Copilot. It felt amazing! (Take a minute to check out this short thread on a real-life session with Aider , if you've never tried it.) Coming back to Cassandra, by contrast, felt like swimming through molasses. Doing everything by hand is tedious when you know that an LLM could do it faster if you could just structure the problem correctly for it. It felt like writing assembly without a compiler -- a useful skill in narrow situations, but mostly not a good use of human intelligence today. The key difference in these two sce...
Post a Comment
Read more

Why PHP sucks

(July 8 2005) Apparently I got linked by some PHP sites, and while there were a few well-reasoned comments here I mostly just got people who only knew PHP reacting like I told them their firstborn was ugly. These people tended to give variants on one or more themes: All environments have warts, so PHP is no worse than anything else in this respect I can work around PHP's problems, ergo they are not really problems You aren't experienced enough in PHP to judge it yet As to the first, it is true that PHP is not alone in having warts. However, the lack of qualitative difference does not mean that the quantitative difference is insignificant. Similarly, problems can be worked around, but languages/environments designed by people with more foresight and, to put it bluntly, clue, simply don't make the kind of really boneheaded architecture mistakes that you can't help but run into on a daily baisis in PHP. Finally, as I noted in my original introduction, with PHP, ...
30 comments
Read more

A week of Windows Subsystem for Linux

I first experimented with WSL2 as a daily development environment two years ago. Things were still pretty rough around the edges, especially with JetBrains' IDEs, and I ended up buying a dedicated Linux workstation so I wouldn't have to deal with the pain.  Unfortunately, the Linux box developed a heat management problem, and simultaneously I found myself needing a beefier GPU than it had for working on multi-vector encoding , so I decided to give WSL2 another try. Here's some of the highlights and lowlights. TLDR, it's working well enough that I'm probably going to continue using it as my primary development machine going forward. The Good NVIDIA CUDA drivers just work. I was blown away that I ran conda install cuda -c nvidia and it worked the first try. No farting around with Linux kernel header versions or arcane errors from nvidia-smi. It just worked, including with PyTorch. JetBrains products work a lot better now in remote development mod...
Post a Comment
Read more