I’ve been using TaskJuggler on an off-and-on basis over the past nine months or so; it’s a reasonably full-featured project scheduling tool, written in Ruby and using a plain-text input file to define all aspects of the project (resources, tasks, task dependencies, etc.). The syntax for the input files is reasonably straightforward, but I’d been wishing for a bit of syntax-highlighting support in working with those input files. Enter ActiveState’s Komodo v7 and the Komodo team’s focus on making it a little simpler to throw together support for additional languages in Komodo… the result is basic (at this early juncture) support for TaskJuggler input files.
Syntax highlighting for TaskJuggler project files in ActiveState’s Komodo editor/IDE
I recognize there is a very limited audience for this particular language in Komodo: supporting TaskJuggler input files is probably not going to be what sways people looking for a text editor toward Komodo. That being said, with Komodo being my primary editor for most tasks, having support for TaskJuggler made sense at least for my own use. And who knows? Maybe it will be of use to one or two other TaskJuggler users.
This early version (tagged as v0.1.0) provides basic language syntax highlighting, a bit of language intelligence, and some basic macros to
- provide language help,
- check the syntax of TaskJuggler files, and
- implement Komodo abbreviations for the two most common TaskJuggler commands (“resource”, “task”)
Download it, install it as you would any other Komodo extension, and have at it.
I still have a fair amount of work ahead refine some of the subtleties of how the TaskJuggler language is parsed to be a little more context-aware as it tokenizes the language. I’m also very open to suggestions as to what sorts of additional macros and abbreviations would add value to be bundled with the “TaskJuggler Tools” installed with the extension.
Feedback definitely welcome; leave comments below…
I’ve just pushed a couple of minor updates to Komodo-CFML:
- Better highlighting for numerical HTML character entities to address some goofiness based on their inclusion of the “#” character (e.g., #)
- Fix to the DTD for ACF10 to address an error in the Adobe tag documentation for the CFIMAGE tag
I’ve also updated the example configuration file for HTMLTidy that I use to let Komodo know which CFML tags are considered valid tags to include the new tags brought to the table by ACF10.
Both of these updates are available on the Komodo-CFML page.
I’m currently working on building a DTD specific to the Railo CFML engines, and hope to provide support for both their current v3.3.x and preliminary v4.x products at some point in the next couple weeks.
I have updated Komodo-CFML to provide preliminary support for Adobe’s ColdFusion 10 (ACF10) CFML language changes in ActiveState‘s Komodo IDE and Edit editors. I’m calling it “preliminary” at this time because ACF10 is in beta and because I have manually harvested these language changes from Adobe’s “ColdFusion 10 Beta New Features Notes” document (available here). I expect there to be some tuning of these changes by the time ACF10 becomes real. I also have a couple questions open on the ACF10 beta forums asking for clarification on items I see in the Adobe notes document that appear to be omissions or inconsistencies.
This version also includes a handful of minor fixes to errors and inconsistencies in the ACF9.01 tags and attributes that I noticed in assembling the changes to support ACF10, so even if you are not yet interested in playing with the ACF10 beta I’d recommend updating to this version of the editor extension.
To switch to the ACF10 tags and attributes, change the “Default HTML Document Type” selection in Komodo’s preferences at Preferences > Languages > HTML to refer to the entry toward the bottom of the provided list identified as “-//WE3GEEKS//DTD HTML 5 + CFML (Adobe ColdFusion 10)//EN”.
And, as always, feedback is welcome.
Another update to my Solarized color schemes for ActiveState’s Komodo IDE and Komodo Edit. Based on feedback from a user, the coloring for Perl is much better in both the light and dark variants. Downloads are available here:
As always, feedback is welcome.
This is another in my series of short posts covering my efforts to stand up a Tomcat/ACF10 development environment. For background, see the first post in the series.
In my previous post, I revisited allowing access to pages served up by Tomcat to just requests originating from the local system. In that post, we looked at use of Tomcat’s Remote Address Filter in order to have any denied requests be provided with a custom error page. As I noted, however, when I tried to access my Tomcat server via an IPv6-based URI (e.g.,
http://[::1]:8501/test.cfm), my request was being denied even though I had configured the filter to allow access to requests from the following addresses (specified via regex):
Given the second and third of those address specifications, I would have expected my request to have been allowed. This is where having access logs configured comes in handy. Those logs showed these requests coming from
0:0:0:0:0:0:0:1%0 and being denied. OK… what’s with that trailing “%0″?
A bit of digging and I had my answer: the IPv6 address specification includes something called “scopes” that may be present. That “%0″ is the default scope and (as the default) is optional. The RFC for these scopes is pretty fuzzy, so for now will allow for an optional non-negative decimal integer for the scope (per the RFC) and if we ever end up with something else (which the RFC indicates is possible) we will revisit this. We will update our regexes to account for the possible presence of the scope:
Update the list of address regexes in the filter definition, bounce the server, and Tomcat should now allow requests when invoked with an IPv6-based URI. Now we can get back to looking at the extent to which ACF10 supports IPv6.
A final thought on this: you may or may not encounter this, as I have the distinct impression this behavior is a function of the environment (at least the OS and/or the JDK under Tomcat). I’ve blogged it simply because I tripped over it.