2008-07-03 22:21:34 +0100 / mad / revision 2606
native/Mingw/cygwin-launcher/cygwin-launcher.cpp: Lee Hope Mcc confirms my previous suspicion that we need this error message to more constructively cover the case where Cygwin isn't installed.
2008-06-25 17:24:08 +0100 / mad / revision 2605
lib/build/package-for-distribution.rb: In what way did I think I'd fixed the bug introduced by my replacing of a (non-atomic) cp with mv in the terminfo generation rule? Before the change here, we installed /usr/share/terminfo/terminator - with no /t/. My prior comment about "not running into the 74 issue" was wrong too - "?/*" wouldn't ever match "74/terminator" - although I was (probably) right that this isn't run on Mac OS anyway.
Don Satow ran into this.
2008-06-24 00:40:04 +0100 / mad / revision 2604
bin/invoke-java.rb: The code to act on RUBY_LAUNCHER_INVOKING can never have worked. The only reason it can have given the impression of working is that in the in-app client hasn't been working for Windows for ages.
bin/show-alert.rb: If I put it here, then it does work, although this code isn't anything to do with reporting exceptions. "launch" was a better name for its home. "launch" and "launch0" give the impression that the intention was for eg Terminator to sub-class invoke-java.rb's Java class. Perhaps that would be the cleaner solution, though I'm not a fan of derivation except for interface implementation.
2008-06-23 22:05:53 +0100 / mad / revision 2603
src/e/util/InAppServer.java: On Linux, Ruby seems able to connect(2) to 0.0.0.0, which was what we were writing into edit-server-port. On Windows, it throws EADDRNOTAVAIL, perhaps not unreasonably. The intention of this code, in the case where we're binding to INADDR_ANY, was to write the host name into the file, so you could run bin/evergreen from another machine and have it throw the file into the Evergreen running on your primary desktop. That obviously hasn't been working on any platform for quite some time.
This code has two callers and only one passes in null. We could move this code into that caller. I don't want to do that because INADDR_ANY would be a better address to listen on for a multi-homed host, even if we don't choose to write all of its addresses into the server-port file.
2008-06-23 20:15:22 +0100 / mad / revision 2602
native/Mingw/cygwin-launcher/cygwin-launcher.cpp: Expand a comment that caused some discussion.
2008-06-23 20:13:09 +0100 / mad / revision 2601
lib/build/file-list-to-wxi.rb: Here's the working code to create an advertised shortcut... but effectively commented-out because...
lib/build/installer.wxs: ... the thread at the URL here suggests that an advertised shortcut can't be made optional. That plus the desire to let end users tinker with the shortcuts is sufficient to make me lean towards keeping the gruesome HKCU hack which, as well as being the code we've used for a long time, is also the suggestion at the end of that thread.
2008-06-23 20:08:29 +0100 / mad / revision 2600
TODO: Elliott made me think about "Edit with Evergreen" and realize that perhaps there is a practical way. I'm sure, though, that it won't be a straightforward extension of what's there for "Open Terminator Here".
2008-06-23 20:03:06 +0100 / mad / revision 2599
lib/build/universal.make: It's mildly irksome to claim to still be "Creating Windows installer" when we're actually running it.
2008-06-23 19:10:22 +0100 / mad / revision 2598
lib/build/installer.wxs: Don't install any "Open Evergreen Here" context menu hooks.
2008-06-23 18:38:28 +0100 / mad / revision 2597
lib/build/installer.wxs: Removing the conditions requires removing one of the copies of the shortcut code, so I may as well go the whole hog in this check-in and remove all that hard-won, duplicated, registry and directory searching code. Finally, paydirt - the code for doing this, which has caused so many problems, is now under our control, not to mention comprehension. It's more complicated now, but I'm not actually sure it's any longer and it sure as hell was easier to write and debug.
lib/build/universal.make: Now we only need to take one GUID into the shower for the shortcut.
2008-06-23 18:23:13 +0100 / mad / revision 2596
lib/build/installer.wxs: We haven't needed the desktop shortcuts to start in the Cygwin bin directory since we started using a Mingw launcher. It looks like Orca is happy without any value in the registry entries that we have to create to stop it from whining about non-advertised shortcuts.
This change removes the last users of these properties apart from the installation conditions.
2008-06-23 18:11:34 +0100 / mad / revision 2595
native/Mingw/cygwin-launcher/cygwin-launcher.cpp: Teach this program to find Cygwin by itself. I output a much more detailed error message than the installer used to. I'm not sure whether that's a feature but it certainly seems a good idea until this beds in.
native/Headers/WindowsError.h: The registry functions are unusual in that they return an error code rather than using the GetLastError idiom.
native/all/java-launcher/java-launcher.cpp: Fix a comment that pointed a misleading finger at Cygwin. I suspected it was Windows all along.
lib/build/installer.wxs: cygwin-launcher no longer takes the Cygwin bin as its first argument, fixing open-here for per-user installations and removing some comment-worthy confusion that tripped me up twice.
2008-06-23 17:50:15 +0100 / mad / revision 2594
lib/build/universal.make: Actually, while I'm there, cp isn't atomic and is therefore not ever fit for use in writing to $@. Rename-over-existing isn't atomic on Windows but the only possible non-atomic failure mode leaves the target file missing, which make will cope with just fine. This also removes a window of opportunity where we could be killed while the target file was writeable.
2008-06-23 17:45:27 +0100 / mad / revision 2593
lib/build/universal.make: I can't think of a sane way of getting throwback to work on Windows but I can at least make it much harder for me to edit the generated copy of the file, thus inevitably losing my changes.
2008-06-23 07:13:04 +0100 / enh / revision 2592
lib/build/patch-to-html-email.rb: set executable bit in Subversion, which is too "clever" to pay attention to chmod(1).
2008-06-23 07:02:02 +0100 / enh / revision 2591
lib/build/escaping.rb: this script isn't executable, so shouldn't start with a #! line.
2008-06-23 06:54:14 +0100 / enh / revision 2590
lib/build/package-for-distribution.rb: add the new "Homepage" field.
2008-06-23 06:52:28 +0100 / enh / revision 2589
lib/build/package-for-distribution.rb: change the "Maintainer" field slightly to keep lintian(1) happy.
2008-06-22 22:54:09 +0100 / mad / revision 2588
native/Mingw/cygwin-launcher/cygwin-launcher.cpp: This function's getting too large and extra white space isn't a good solution.
2008-06-22 22:42:38 +0100 / mad / revision 2587
lib/build/installer.wxs: There's more detail on this in the Terminator TODO file but this will definitely seem like a bug to my future self, so it definitely deserves a code comment.
2008-06-22 22:02:02 +0100 / mad / revision 2586
lib/build/installer.wxs: I have to switch to another computer in a minute, so in this goes, only half-baked. There are three things wrong with this - the HKLM-specificity noted in the code comment, that we don't want this for Evergreen, and that it generates Orca warnings as noted in the TODO file. The HKLM issue could be worked around with duplication, as everywhere else in installer.wxs, but I'm hoping this will be the final straw in pushing me to write the registry searching code to find cygwin1.dll from cygwin-launcher. The Evergreen thing will want some more code, which should probably take into account that we might like to use something similar for CheckInTool but not for RevisionTool, which could conceivably make use of something not entirely unrelated but significantly different. The Orca warnings I think I will "address" by moving that part of the TODO note into a code comment here.
2008-06-19 09:32:13 +0100 / mad / revision 2585
native/Mingw/cygwin-launcher/cygwin-launcher.cpp: No, it *does* include a trailing backslash...
lib/build/installer.wxs: ... and because this is all just macro substitution, the backslash gets to escape the quote after it. What a nightmare. At least I know how to write XML comments now.
2008-06-19 09:23:58 +0100 / mad / revision 2584
native/Mingw/cygwin-launcher/cygwin-launcher.cpp: Ah, that wasn't an incorrectly escaped quote, it was a backslash. Still, it did look like a mistake and the code here that it was pandering to could easily play safer.
2008-06-19 09:01:56 +0100 / mad / revision 2583
lib/build/file-list-to-wxi.rb: Shortcuts and shell extensions are seemingly typically created immediately after the File to which they refer and must, in some cases, be inside the same Component. I used this hook several times this evening in various experiments and I expect I'll use it again.
lib/build/installer.wxs: Skeletal support for an open-here feature. I tried a couple of ways of filling in this Component this evening. I suspect I'll be back.
lib/build/universal.make: Open-here requires another random number.
You know, all this, and the non-maintainability of the HKLM and HKCU variants of the code in that .wxs file make me think that I should have one Ruby script that generates the whole thing. I suspect it'd be more readable and it'd certainly be better commented.
I'm also about to check-in the Terminator TODO file with some related .wxs snippets for revisiting on another evening...
2008-06-18 04:20:40 +0100 / mad / revision 2582
www/cygwin-problems.html: While looking at my previous changes, I see we were claiming that NT 3.5x and NT 4 used UTF-16, when they actually used UCS-2. UTF-16 came in with Windows 2000. Yes, UTF-16 and UCS-2 are closely related but we shouldn't give out misinformation.
2008-06-18 04:15:48 +0100 / mad / revision 2581
www/cygwin-problems.html: Adam Jones and Ron Pagani recently reminded us of the reason we note in our Cygwin Setup page that inetutils is the package containing telnet. I don't know why Microsoft telnet doesn't like being started from a Cygwin terminal, but it's not a Terminator-specific issue. It can be started (in a new window) via at least one Cygwin program - cygstart - but that looks to have special support in the Cygwin DLL for starting children in some kind of detached mode.
2008-06-18 00:59:12 +0100 / mad / revision 2580
native/all/salma-hayek/e_util_FileUtilities.cpp: The usual stanza, this time with a code-comment, so I don't have to trawl the glacially slow svn history to find out, and this time for sure, that the only reason for it is (at least arguably) a bug in one of Sun's JNI headers.
2008-06-17 16:46:14 +0100 / mad / revision 2579
native/all/salma-hayek/e_util_FileUtilities.cpp: The intention was clearly to stat the link itself, not the target. As well as actually working now(!), this is faster and doesn't produce a torrent of spurious errors when it sees dangling links (which was what first alerted me to the bug).
2008-06-17 05:15:46 +0100 / enh / revision 2578
bin/invoke-java.rb: add any salma-hayek native library directories to the library search path.
native/all/salma-hayek/e_util_FileUtilities.cpp: a new library implementing FileUtilities.nativeIsSymbolicLink until Java 7 gives us something with equivalent performance (as part of JSR-203).
src/e/util/FileUtilities.java: keep the slow heuristic code in case we can't load the JNI library, but prefer the JNI library.
2008-06-17 04:23:56 +0100 / enh / revision 2577
native/all/salma-hayek: add a directory.
2008-06-15 06:26:45 +0100 / enh / revision 2576
bin/download-latest-jdk.rb: this script no longer works; I'm still maintaining the Talc version, a fix for which I've just committed to the Talc repository, but hereby give up on the Ruby version.
2008-06-15 02:38:28 +0100 / enh / revision 2575
src/e/util/FileSearcher.java: add an intention-revealing "final" (unrelated to performance).
2008-06-15 02:31:49 +0100 / enh / revision 2574
src/e/util/FileSearcher.java: document a failed attempt at optimization.
2008-06-09 08:35:30 +0100 / mad / revision 2573
native/Mingw/cygwin-launcher/cygwin-launcher.cpp: SetDllDirectory was a nice idea but it only exists on recent versions of Windows. Then I ran into a piffling limit on the size of a shortcut target, the most expedient solution for which, distressingly, means that cygwin-launcher has to gain some knowledge about what it's launching. Given it needs to know something about ruby-launcher, I think it may as well know about rubyw too. As if that weren't enough, I then (re)discovered that the arguments containing spaces in the argument vector passed to execv and friends must, on Windows, be quoted by the application passing them.
native/all/ruby-launcher/ruby-launcher.cpp: Tracking that down required ruby-launcher to report which arguments it had been passed, which of course it can't do except via the GUI.
native/Headers/reportArgValuesViaGui.h: I used the same code in cygwin-launcher while debugging it, so a header file seems the right place.
native/Headers/checkReadableFile.h: Commented-out debugging code that we might need again is dubious at best, so let's try checking that ruby-launcher been passed a readable file as its argument. One day, perhaps we'll want more flexibility but we seem to see more problems where the Windows shortcut "doesn't do anything" than almost any other sort of problem, so perhaps some extra effort is due.
lib/build/installer.wxs: Tidy up some superfluous backslashes, some forward slashes that should (for consistency at least) be backslashes and an oddly indented XML tag that's irked me before. Quote the first argument we pass to the shortcut target as well as the second, as quoting seems to be our responsibility and there's no reason I know of why you couldn't install Cygwin under, say, "Program Files" - a directory whose name contains a space. Confusingly, this requires we add an extra backslash to avoid the quoting the closing quote.
2008-06-09 05:32:57 +0100 / enh / revision 2572
src/e/forms/FormDialog.java: move a possible FIXME here from Evergreen's to-do list.
2008-06-08 05:34:38 +0100 / enh / revision 2571
src/e/util/TimeUtilities.java: FindBugs complains of potential concurrent calls to a non-thread safe DateFormat. Add synchronization.
2008-06-08 02:34:04 +0100 / mad / revision 2570
lib/build/universal.make: Write quite a bit of extra code so we can do without the comment about the harmlessness of the duplication when we run findbugs in salma-hayek. Remove the $(addprefix) complexity in the findbugs rule, and where it was copied from. I presume the original reason was that the argument might be empty. It's not now and doesn't seem likely to be again.
The extra colon on the end of auxclasspath happens when EXTRA_JARS ends in a space, because the last wildcard to be appended evaluates empty. makeNativePath can strip trailing spaces and solve that more widely. Evaluate the wildcard immediately, as usual, so we minimize the file system chatter.
lib/build/filter-build-output.rb: I was going to ask what findbugs's output looks like, thinking that if it doesn't generate any warnings, we wouldn't want to see it. Well, there doesn't seem much danger of it not generating any warnings. They look easy enough to spot, especially the warning counter at the end. There are several other approaches we could use to solve this sort of problem but, while we're just generating things that really do look like compiler warnings, I think I'll stick to the existing mechanism. exit 1 was, though, a good (clean, simple) hack. I'm tempted to change the echo.% rule to work that way too.
2008-06-08 00:27:35 +0100 / enh / revision 2569
lib/build/universal.make: add FindBugs' -auxclasspath switch.
2008-06-07 07:13:14 +0100 / enh / revision 2568
lib/build/universal.make: add a half-baked rule for running findbugs, in the hope that the Make pixies will bake the more complicated half.
2008-06-07 06:53:00 +0100 / enh / revision 2567
lib/build/universal.make: minor changes to the GCJ hack I use for building a stand-alone Talc binary.
2008-06-07 05:19:15 +0100 / enh / revision 2566
src/e/util/SpellingChecker.java: FindBugs points out we're not checking readLine doesn't return null.
2008-06-07 04:58:34 +0100 / enh / revision 2565
src/e/gui/HelpMenu.java:
src/e/ptextarea/PTextAreaSpellingChecker.java:
src/e/ptextarea/PWrappedSegmentIterator.java:
src/e/toys/world/SolarProjector.java: FindBugs complains about inner classes that could be static but aren't.
2008-06-07 04:51:33 +0100 / enh / revision 2564
src/e/util/InAppServer.java: FindBugs complains about use of "new Long", suggesting Long.valueOf instead, but since we're actually just trying to convert a long into a String, it's really Long.toString we want.
2008-06-07 04:46:31 +0100 / enh / revision 2563
src/e/util/LazyStringSelection.java: FindBugs spots incorrect synchronization.
2008-06-07 04:44:37 +0100 / enh / revision 2562
src/e/forms/FormDialog.java: FindBugs dislikes the comparison with Boolean.TRUE (because Boolean, stupidly, has a public constructor). Our code is correct, but relying on auto-unboxing instead is correct in the presence of code using the Boolean constructor, and shorter.
2008-06-06 06:29:43 +0100 / enh / revision 2561
src/e/ptextarea/FileType.java: improve a method name and some documentation.
2008-06-06 06:23:03 +0100 / enh / revision 2560
src/e/ptextarea/FileType.java: another bit of tuning to the file-type heuristics so that (amongst other things) a Ruby script containing "#ifdef" won't be assumed to be C++.
2008-06-02 03:08:30 +0100 / mad / revision 2559
lib/build/package-for-distribution.rb: Fix the build breakage I introduced yesterday, which only affected builds of the Terminator installer from clean. I suppose looking for files to include in the installer can use a glob without picking up obsolete files, as the installer should be built from clean, although I didn't make clean before checking that make install still worked yesterday. But I think I only tried that on Cygwin anyway, where this code isn't run. We were installing the copy of terminator's terminfo from the "t" subdirectory. Everywhere else, we use the copy we make of it in the parent directory, to avoid having to know whether we should use "t" or, on Mac OS, "74". The code here only gets executed on Linux and Solaris, which is why we haven't run into the "74" issue. Let's use the copy from the parent directory here too. If we do the same as everyone else, then we won't be the only victim when someone changes what he thinks are just internal implementation details of that make rule. I can't be making this change twice (and then perhaps fixing it twice), so I'll have to collapse that part of the Solaris-induced duplication.
Fixes:
/usr/lib/ruby/1.8/fileutils.rb:1039:in `read': Is a directory - .generated/terminfo/t (Errno::EISDIR)
from /usr/lib/ruby/1.8/fileutils.rb:1039:in `fu_copy_stream0'
from /usr/lib/ruby/1.8/fileutils.rb:1247:in `copy_file'
from /usr/lib/ruby/1.8/fileutils.rb:1246:in `open'
from /usr/lib/ruby/1.8/fileutils.rb:1246:in `copy_file'
from /usr/lib/ruby/1.8/fileutils.rb:1245:in `open'
from /usr/lib/ruby/1.8/fileutils.rb:1245:in `copy_file'
from /usr/lib/ruby/1.8/fileutils.rb:459:in `copy_file'
from /usr/lib/ruby/1.8/fileutils.rb:383:in `cp'
from /usr/lib/ruby/1.8/fileutils.rb:1379:in `fu_each_src_dest'
from /usr/lib/ruby/1.8/fileutils.rb:1395:in `fu_each_src_dest0'
from /usr/lib/ruby/1.8/fileutils.rb:1377:in `fu_each_src_dest'
from /usr/lib/ruby/1.8/fileutils.rb:382:in `cp'
from /u1/home/mad/software.jessies.org/work/salma-hayek/lib/build/package-for-distribution.rb:215:in `copyTerminfoTo'
from /u1/home/mad/software.jessies.org/work/salma-hayek/lib/build/package-for-distribution.rb:208:in `each'
from /u1/home/mad/software.jessies.org/work/salma-hayek/lib/build/package-for-distribution.rb:208:in `copyTerminfoTo'
from /u1/home/mad/software.jessies.org/work/salma-hayek/lib/build/package-for-distribution.rb:306
make[1]: *** [terminator.app] Error 1
2008-06-01 22:27:44 +0100 / mad / revision 2558
native/Headers/WindowsError.h: Make the, as yet not fully implemented, Windows equivalent of unix_exception available to other programs, specifically cygwin-launcher with an eye to its need for calling SetDllDirectory. Providing a class with the same name in the case that we're not on Windows keeps the using code simpler and keeps the included headers as similar as possibly across platforms.
native/all/java-launcher/WindowsDirectoryChange.cpp: I've changed the macro guards in WindowsError's original location to refer to __MINGW32__ too, because I don't see any reason why it wouldn't compile for that target.
2008-06-01 22:02:17 +0100 / mad / revision 2557
native/Headers/reportFatalErrorViaGui.h: cygwin-launcher wasn't going down the MessageBox route because __CYGWIN__ isn't defined for Mingw builds.
native/Headers/WindowsDllErrorModeChange.h: This will also affecting cygwin-launcher (though I haven't tested it).
native/Mingw/cygwin-launcher/cygwin-launcher.cpp: A lengthy investigation of the history of this now obviously incomplete stanza for including windows.h leads me to conclude that if and when we really do need to include it first, we'll see a compilation error. I'll treat it as a normal #include here. I need no OS guard because this directory is for Windows-specific source. I will eventually need windows.h for the SetDllDirectory call.
2008-06-01 21:23:43 +0100 / mad / revision 2556
native/Mingw/cygwin-launcher/cygwin-launcher.cpp: A (blech) copy-and-paste of the parts of ruby-launcher.cpp that we want here, namely the WindowsDllErrorModeChange and the message box error handling for the case where we can't start the Cygwin program. The only changes are in boilerplate text, a removal of #include directives that we don't need here and the addition of a TODO for the one extra, motivating, thing that we want to do here.
When the previous check-in's change started running the compiler with the right flag, it became clear that the Microsoft runtime doesn't provide strerror_r. For the purposes of cygwin-launcher...
native/Headers/strerror_r.h: ... we can provide a trivial implementation in terms of strerror...
native/Headers/unix_exception.h: ... that does enough to satisfy the caller here.
2008-06-01 20:59:40 +0100 / mad / revision 2555
lib/build/universal.make: C_AND_CXX_FLAGS is only evaluated during the execution of the compilation rule. At that point, it's an error to refer to $(SOURCE_DIRECTORY). SOURCE_DIRECTORY should be treated just like a per-directory local variable. Think of it as the parameter to that scope - parameters are clearly local. Add SOURCE_DIRECTORY to the list of LOCAL_VARIABLES, so we get the benefit of a early failure with a half-decent error message.
That simple change caused a knock-on problem with BASE_NAME. We had a special hack allowing that local variable to be used outside the local scope for the benefit of the scoping violation error message. But BASE_NAME is, it seems, defined in terms of SOURCE_DIRECTORY, which is now a local variable. For those error messages, I think we only need to know the name of the immediately preceding scope. We know where we want the name of the immediately preceding scope and so there we can ask for it with a special name. That removes the possibility that someone will use BASE_NAME somewhere else and get misleading results with no protection. I clarified the error message while I was there, using more consistent quoting.
Now, elsewhere, we add components to C_AND_CXX_FLAGS which depend on $<. So I can follow that pattern and make the -mno-cygwin compilation flag dependent on that instead of SOURCE_DIRECTORY. That's fine, as far as it goes, but I can't use that for LDFLAGS because per-directory.make treats that variable quite differently. It's evaluated at the start of per-directory.make and then added to according to whether we find Cocoa source and so on. That seems to have lasted OK under maintenance too but, to fit in with it for Mingw, I'm going to have to move the LDFLAGS setting...
lib/build/per-directory.make: ... here. This smacks of distributed duplication and I'm not very happy about it but I don't want to bite off some large-scale reorganization while I'm in the middle of the cygwin-launcher feature.
Before this change, cygwin-launcher was linked with -mno-cygwin but compiled without that flag, despite there being (non-functioning) code to enable that flag for the compilation.
2008-05-31 17:24:10 +0100 / mad / revision 2554
lib/build/universal.make: Teach make to copy mingwm10.dll to the same directory it puts cygwin-launcher.exe in. Only do that when building for Cygwin and in a project with Mingw source. Do the copy atomically (with copy-then-rename), in case someone hits Ctrl-C while it's being copied. Make another copy similarly atomic. While in paranoid mode, more robustly test for when we need -mno-cygwin, in case someone were to try to build under a directory called "Mingw" on some other platform, presumably just to poke fun at the build system.
2008-05-28 00:15:27 +0100 / mad / revision 2553
native/Mingw/cygwin-launcher/cygwin-launcher.cpp: Yes, yes it is. This is (clearly) just a stub, but it's enough for me to objdump -p and show that my -mno-cygwin infrastructure is working.
2008-05-28 00:14:31 +0100 / mad / revision 2552
native/Mingw/cygwin-launcher: Tedious Subversion is going to make me add this tree one level at a time, isn't it?
2008-05-28 00:13:23 +0100 / mad / revision 2551
It's looking like Jim Lowe might be about to supply us with a second reason for wanting cygwin-launcher - in case ruby-launcher's dependencies on cygwin1.dll aren't satisfied.
lib/build/universal.make: So I've finally got round to the infrastructure for building with -mno-cygwin...
native/Mingw: ... when the source is in this directory and (at least currently) when the TARGET_OS is Cygwin.
2008-05-27 22:14:44 +0100 / mad / revision 2550
native/all/java-launcher/java-launcher.cpp: Pasting the comment into an email, I see a squiggly green underline.
2008-05-27 18:19:27 +0100 / mad / revision 2549
lib/build/universal.make: scp appears to copy directly to the target filename it's given, so that a network outage will leave you with a truncated file. That build will fail, noisily, but perhaps our Mac builder isn't checking his build mails religiously or perhaps he was (reasonably) hoping for the next day's build to put it right. I'm sure he doesn't use Outlook / Exchange which, despite its many faults, makes it trivial (if not indeed the default) to keep a couple of weeks' worth of deleted mails, so I doubt we can find out for sure what happened to cause the Mac build of terminator-5.147.2545.dmg to be zero-sized, as reported by Stefan Janecek. Oh well, let's see if we can stop it from recurring.
2008-05-27 04:54:41 +0100 / mad / revision 2548
native/Headers/reportFatalErrorViaGui.h: Well, that wasn't the platform I expected to have a problem on, but I suppose that's meta-expected. Interestingly, Linux did report the ex.what() before terminate()ing. (Which baffled me because I hadn't spotted that the old version hadn't been overwritten.)
2008-05-27 04:25:04 +0100 / mad / revision 2547
native/all/ruby-launcher/ruby-launcher.cpp: James Lowe reports that his desktop shortcut doesn't work and was kind enough to prove that it was ruby-launcher that was silently failing. We can't tell why, but at least we might be able to after this change. Clearly, I've been spoiled by Ruby, as even linking the previous code with the console subsystem produces nothing more informative than a coredump. We need to handle the exception and, more particularly, we need to inform the user of its message via a MessageBox. Hmm... don't we have code for that somewhere?
native/all/java-launcher/java-launcher.cpp: Yes we do, including an Apple variant, whose output I haven't ever had the misfortune to see. I'll have to provoke that shortly, as ...
native/Headers/reportFatalErrorViaGui.h: ... even three lines of Objective-C++ is enough to baffle me. The message we report on Windows for Terminator failures takes a turn for what will presumably be regarded as "the worse" under this change (the part about installing a decent Java now comes after the Ctrl-C hint). No biggie, methinks.
Outputting to std::cerr doesn't seem to cause us problems when started from a Windows shortcut, even when reporting a failure before ensuring that file descriptor 2 is open but, still, I'll do that after the MessageBox, just in case.
I don't exit(1) here, though I was tempted, because the java-launcher code didn't.
2008-05-27 01:20:07 +0100 / enh / revision 2546
src/e/ptextarea/PTalcTextStyler.java: catch up with recent language developments.
2008-05-20 06:42:31 +0100 / enh / revision 2545
src/e/ptextarea/PCppIndenter.java:
src/e/ptextarea/PJavaIndenter.java:
src/e/ptextarea/PPerlIndenter.java: no (deliberate) functional change here, just moving configuration from the subclasses...
src/e/ptextarea/PCFamilyIndenter.java: ...to the parent. My real interest is in moving the other stuff up (especially the misleadingly-named and vaguely-intentioned isLabel), but this is the easy bit, and all I have time for right now.
2008-05-19 06:00:30 +0100 / enh / revision 2544
src/e/ptextarea/PNewCppIndenter.java: I already fixed the "case" bug in PCppIndenter.
2008-05-19 04:35:55 +0100 / enh / revision 2543
src/e/ptextarea/PTalcTextStyler.java: add the "assert" keyword and, since we currently treat the other built-in types as keywords, "list" and "map" too.
2008-05-19 02:59:50 +0100 / enh / revision 2542
src/e/ptextarea/PCFamilyIndenter.java:
src/e/ptextarea/PCppIndenter.java:
src/e/ptextarea/PJavaIndenter.java:
src/e/ptextarea/PPerlIndenter.java: support more intelligent indenting of wrapped sequences of operator<<.
2008-05-18 20:54:23 +0100 / mad / revision 2541
bin/ithaki.sh: Some comments, which would help anyone trying to set up their own local jessies Debian repository, or us, if we had a disaster to recover from.
2008-05-05 00:10:59 +0100 / mad / revision 2540
lib/build/universal.make: Sounds like Ubuntu's gcc 4.3 configuration tells it to link stdc++ by default but Debian's prerelease version wasn't the first gcc platform for which I've had to do this manually (though it might be for the software.jessies.org stuff). In particular, I've seen it configured to not link stdc++ when invoked via gcc but to link it when invoked via g++. This seems unlikely to hurt, at least on Linux and possibly everywhere.
2008-05-04 19:43:41 +0100 / enh / revision 2539
src/e/gui/DebugMenu.java: add a "Mouse Event Tester" alongside the "Key Event Tester", sharing much of the code (and adding some improvements).
2008-05-02 07:16:55 +0100 / enh / revision 2538
native/Linux/gnome-startup/gnome-startup.cpp: a patch from Colin Walters, fixing GCC 4.3 builds by adding missing #includes.
2008-04-18 04:04:34 +0100 / enh / revision 2537
src/e/util/HtmlToPlainTextConverter.java: add a new class I've been using for some time elsewhere.
src/e/gui/HtmlPane.java: ...and a related DTD fix I've also been using for a while.
2008-04-15 05:24:25 +0100 / enh / revision 2536
src/e/ptextarea/PCFamilyIndenter.java: differentiating "case A: return foo;" from "case A:" followed by "return foo;" on the next line was definitely my intentional, and seems to have been caused by my usual confusion of "matches" and "find".
2008-04-14 03:17:03 +0100 / enh / revision 2535
bin/annotate-patch.rb: another day, another diff format.
2008-04-14 01:04:41 +0100 / enh / revision 2534
src/e/ptextarea/FileType.java: make it easy and non-invasive to use an arbitrary indenter or styler for a given FileType.
2008-04-08 16:38:01 +0100 / pcn / revision 2533
src/e/ptextarea/PCFamilyIndenter.java: Detect left- and right-shifts in the c-family indentation code. These are usually shifts and not brackets, and so we shouldn't treat them as indenting entities. One small step on the road to nice indentation.
2008-04-02 07:27:30 +0100 / enh / revision 2532
src/e/ptextarea/PNewCppIndenter.java: a first rough draft of a new C++ indenter. Not ready for general use, but everyone's welcome to try it out.
2008-04-02 06:28:18 +0100 / enh / revision 2531
src/e/ptextarea/PTalcTextStyler.java: track not-very-recent Talc language changes. I've had these changes for ages, but want to commit them now before I accidentally mix them up with other PTextArea changes.
2008-04-02 06:25:27 +0100 / enh / revision 2530
src/e/ptextarea/PCFamilyIndenter.java:
src/e/ptextarea/PSimpleIndenter.java: move the block comment/ASCII art handling up into the superclass because it's the best bit of code in PCFamilyIndenter, and useful in indenters that don't subclass PCFamilyIndenter.
2008-03-11 06:12:25 +0000 / mad / revision 2529
bin/invoke-java.rb: Chris correctly diagnoses that my leaving of this pollution in the environment means that checkintool doesn't work from Terminator or Evergreen on Windows. Oops.
2008-02-28 04:16:47 +0000 / mad / revision 2528
lib/build/universal.make: Chris's Sparc Solaris scp produces this output when we should upload a new pkg file:
scp: warning: stat: SJOevergreen_5.1.2527_sun4u.pkg (src): no such file (server msg: 'No such file')
The unfortunate use of "warning: " in that *error* message matches a regular expression in filter-build-output.rb, causing it to reason "looks like a Java warning - better output that and the preceding commands". We're already paying for an ssh connection to do a mkdir -p, so it's not much hassle to avoid the error. Or warning.
2008-02-27 04:45:50 +0000 / enh / revision 2527
src/e/gui/AboutBox.java:
src/e/gui/JFrameUtilities.java:
src/e/gui/MainFrame.java: mad points out that an old change of mine re-introduced a "VM doesn't exit" bug. Fix JFrameUtilities.makeSimpleWindow to use our major idiom for windows where we don't want to do anything clever (we just want them to go away when closed, however they're closed) and don't want to make assumptions about how they'll be used (which you're doing when you use DISPOSE_ON_CLOSE or EXIT_ON_CLOSE) because we hand the resulting JFrame out to arbitrary application code to do with as it sees fit. Also document in MainFrame why this is the best idiom for making windows dispose themselves (assuming you don't have anything more complicated to do).
2008-02-27 04:40:43 +0000 / enh / revision 2526
src/e/gui/AboutBox.java: some old changes I had lying around; defer to Log's idea of the application name rather than keeping a separate copy.
2008-02-26 00:25:12 +0000 / car / revision 2525
www/downloads.html: Make available Solaris sun4u packages rolled on Solaris 10.
2008-02-25 10:20:45 +0000 / mad / revision 2524
lib/build/installer.wxs: Braden Anderson has a repeatable problem with Terminator trying to install itself into C:\CFusionMX7\bin. A dump of his registry revealed that he had stub entries for the Cygwin registry keys under HKCU. A look in my registry revealed that so did I - a vestige of a per-user installation. A look at msiexec /l* install.log /i terminator.msi showed that the CYGWIN_HKCU_BIN property was being set even though CYGWIN_HKCU wasn't. It seems like it was just searching for the first "bin" directory that came to hand. Looking at the same log generated on my system showed that mine was setting CYGWIN_HKCU_BIN too, fortunately (or otherwise) to C:\cygwin\bin.
Fix that by not using "[property]" in Path attributes. Instead we'll have to duplicate the parent searches. I tried again to use DirectorySearchRef but you know you're on a hiding to nothing when the most useful of the top ten Google results you turn up is one of your own check-in comments berating the lack of examples and impenetrability of this feature.
We're now using the CYGWIN_HKLM_BIN property in only two places. One is in a Condition element, where it was added under r1705 with this check-in comment [
The difficult part was finding that this perturbed evaluation order of the CYGWIN and RUBYW properties such that, even though the RUBYW property uses the CYGWIN property, it was now evaluated first - and thus didn't work. What a half-baked little language.
]. As well as exhibiting even less understanding of the Windows installer structure than I now have, I can't see how that can still be true after the change I'm making here.
The other usage is in setting the working directory for the shortcut. That's something we could avoid the need for if I write the cygwin-launcher.exe I was mulling the other day (under the auspices of the "Terminator Here" RFE). Ah, but then I'd want to pass the Cygwin bin directory to the cygwin-launcher, so I won't be able to get rid of this duplication even then. Oh well.
This installs OK and passes Orca validation - and doesn't assign properties that it shouldn't. Whether it will work for Braden is another matter. I'm not sure it will because his installer log says it bound C:\CFusionMX7\bin to both CYGWIN_HKCU_BIN *and* CYGWIN_HKLM_BIN, though it bound CYGWIN_HKLM and RUBYW_HKLM correctly. Previously it was alleging a successful installation but starting the shortcut in the wrong directory.
2008-02-24 00:07:45 +0000 / enh / revision 2523
src/e/util/IndentationGuesser.java: comment a deficiency of the current implementation.
2008-02-23 23:53:42 +0000 / enh / revision 2522
src/e/ptextarea/PTextAreaSpellingChecker.java: convert this function to the usual early-return style to avoid an extra level of indentation for the majority of the method. Stop assuming that code-specific fixes (such as camelCase or underscored_identifiers) make sense in plain text. Work around a bug whereby we sometimes accidentally suggest "correcting" a word via the identity transformation, which doesn't get us anywhere. Add an upper bound of five items to the number of suggestions we'll show, because aspell(1) will happily provide 20-odd really unlikely suggestions in many cases. (We didn't have as much trouble with ispell(1), and this is one thing that's made this code significantly less useful since we switched.) Additionally, if we've offered camelCase and underscored_identifier corrections, give up. They're almost certainly what the user wants, and if they're not, the chances of any of our later guesses being right are pretty slim. Finally, move the "Accept" action back to the bottom where it belongs (on the assumption that you typically accept a bunch of new vocabulary at the beginning of a project but will be conservative thereafter).
2008-02-23 16:41:13 +0000 / mad / revision 2521
native/all/ruby-launcher/ruby-launcher.cpp: Leave an analog of CHERE_INVOKING in the environment when the user double clicks on one of our Windows shortcuts...
bin/invoke-java.rb: ... so we can reinstate the desired working directory - the user's home directory, like it would be on any other platform - before running any application-specific code, like Terminator's code for deciding which working directory to open a shell in.
ruby-launcher was motivated by our problems with Windows desktop shortcuts and only seems to be used there currently.
Other parts of bin/evergreen and bin/terminator depend on ENV["HOME"]. I'm not sure where Ruby's getting that variable from. Cygwin's /etc/profile has some complicated code for setting it but that won't have been invoked by the time we're implicitly sampling it here (by passing no argument to chdir).
2008-02-23 01:00:17 +0000 / mad / revision 2520
bin/invoke-java.rb: Gain the code from Evergreen to stop Cygwin's /etc/profile from scuppering the effect of Terminator's --working-directory parameter. We should set this variable here so that it takes effect when the user starts Terminator from the command line as well as when it's started from the desktop shortcut.
There's another piece to this puzzle - changing to the user's home directory when starting applications from the desktop shortcut. I'm not sure what's the best way to do that. While I prevaricate, double-clicking on Terminator in Windows will leave you in /usr/bin. At least that's obvious from the prompt. I've gotta dash, but checking in is a convenient way of getting the code from my MacBook to my Windows box - and will force me to finish this off rather than letting it slide.
2008-02-23 00:42:44 +0000 / mad / revision 2519
bin/invoke-java.rb: Avoid using single quotes when there's no reason to, to avoid the appearance that there might be something magic going on, particularly when using features as obscure as an argument hash (to Net::Telnet.new) and the Win32API interface. I've recently seen someone's first Ruby script and they're falling into all the bad old Perl practices that make the code write-only.
2008-02-22 07:11:27 +0000 / mad / revision 2518
www/cygwin-setup.html: This looks like quite a selective list, so perhaps I shouldn't be adding something of such minority interest to it, but it might make our Terminator support job easier if everyone who's religiously followed our suggestions has already installed infocmp.
2008-02-22 05:57:02 +0000 / enh / revision 2517
native/Headers/JniString.h: the fact that this was a class has never been useful, and it's made calling code unnecessarily verbose. Life is easier if it's just a function. (I also wonder whether segfaulting is the most useful behavior we can manage for a null Java string, but I'll leave that as it is for now.)
2008-02-19 17:45:09 +0000 / mad / revision 2516
src/e/ptextarea/PTextAreaSpellingChecker.java: Stephen Parker suggests a coping strategy for the spelling checker returning too many suggestions to fit on the screen. Elliott blessed the idea and having the pre-determined items at the top sounds like a good UI decision to me.
2008-02-17 04:46:25 +0000 / enh / revision 2515
src/e/ptextarea/PKeyHandler.java:
src/e/ptextarea/PTextArea.java: add support for Terminator-like hiding of the mouse when the user is typing.
2008-02-17 02:21:19 +0000 / enh / revision 2514
src/e/ptextarea/PTextArea.java: every time I see "getCoordinates", I'm sure it's the source of a bug or two, and disappointed that it doesn't appear to be what it sounds like, or what I'm looking for. Add a warning, if nothing else, and add getLogicalCoordinates, which is the method I'm usually looking for.
2008-02-16 20:56:08 +0000 / enh / revision 2513
src/e/gui/GnomeStockIcon.java: fix a broken link in the documentation.
2008-02-16 20:44:35 +0000 / enh / revision 2512
src/e/ptextarea/FileType.java: if we're to support user-defined FileTypes without requiring that users edit and rebuild this class, FileType can't be an enum. Rewrite it as an enum-like class.
2008-02-13 04:42:49 +0000 / enh / revision 2511
src/e/ptextarea/PPythonTextStyler.java: Python 2.5 adds the keywords "as" and "with".
2008-02-12 04:23:59 +0000 / enh / revision 2510
src/e/ptextarea/FileType.java: the new Python indenter has been working well for me so far, so let's make it the default.
2008-02-12 00:39:17 +0000 / mad / revision 2509
src/e/gui/AboutBox.java: It was probably the subject line than stuck in Stephen's eye but I've advocated "problem report" so I may as well use it in the source too.
src/e/gui/HelpMenu.java:
src/e/util/Log.java: And in the caller and callee.
2008-02-12 00:31:35 +0000 / mad / revision 2508
lib/DEBIAN-control-Build-Depends.txt:
lib/build/DEBIAN-control-Build-Depends.txt: Tidy away the other file that lives in salma-hayek/lib/.
lib/build/package-for-distribution.rb: And the one reference to it.
Mainly, though, I just want the change log regenerated after I added an executable copy of the pre-revprop-change.tmpl hook as pre-revprop-change and editing an earlier comment to remove email addresses.
2008-02-12 00:17:48 +0000 / mad / revision 2507
src/e/gui/HelpMenu.java:
www/bug-report.html:
www/navigation.html: That's twice in one day that I've heard mild-mannered criticism of pejorative terms for what gcc calls "problem reports" or PRs. "Bug" still seems like the right term to use in "Bug database", as it does in the advice on writing a good bug report. Many of the mails we get wouldn't end up in our hypothetical bug database, yet it would be incorrect to say that the reporting user doesn't have a problem, even if a substantial part of the problem is, as it often is, that they haven't thought to look at the FAQ.
2008-02-12 00:07:41 +0000 / mad / revision 2506
src/e/ptextarea/PCFamilyIndenter.java: I was mildly surprised that this commenting style didn't also trip up the newline inserter, but it doesn't seem to. Looks harmless and is clearly useful to some.
-----Original Message-----
From: Stephen Parker
Sent: Monday, February 11, 2008 15:56
Subject: Evergreen bug (1265/2505/1.6.0_03-b05/Windows Vista 6.0/x86 x2)
Not really a bug, but our coding standard requires boxed comments, like this:
/*
*****************************************************************************
* Function:
* Purpose:
* Returns: Nothing.
* Pre-condition: None.
* Post-condition: None.
* Notes:
*****************************************************************************
*/
which the current indentation rules make a nightmare to work with
(spaces get added after "/^ *" to give "^ * ***"etc. when cutting and
pasting).
This seems to fix it.
stephen parker (at home).
2008-02-11 19:56:58 +0000 / mad / revision 2505
lib/build/installer.wxs: When we move away from Subversion, I expect I'll find some nice things to say about it. I suppose that it did, at least, leave me with a file that shouldn't have been there, warning me that it hadn't bothered to merge yesterday's change with today's rename.
2008-02-11 19:46:14 +0000 / mad / revision 2504
lib/installer.wxs:
lib/build/installer.wxs: This clearly belongs in the build/ sub-directory.
lib/build/universal.make: From where we'll copy it under .generated/.
2008-02-11 06:31:22 +0000 / enh / revision 2503
src/e/ptextarea/PIndenter.java: extract another sliver of functionality so subclasses can get the indentation part of an arbitrary string.
src/e/ptextarea/PNewlineInserter.java: Vim's indentation code is written as if Vim itself has already copied the previous line's indentation. This does seem to make for a fairly comfortable style, shouldn't affect our existing PIndenter subclasses, and makes it easier to translate a Vim "indent file".
src/e/ptextarea/PPythonIndenter.java: rewrite the Python indenter in the style of Vim's Python indenter. There's some ugly duplication here, but that gives strong clues as to the kind of facilities we might want to provide. The main functionality not mentioned here would be the searchpair function.
2008-02-11 05:05:48 +0000 / mad / revision 2502
www/index.html: We don't compile with WiX v3. It's hard to know whether it would be a moving target while it's still in beta. The documentation doesn't seem to be there.
One problem that I encountered while trying WiX 3 was that my .NET framework wasn't up-to-date enough. That would have been no biggie except for the way Cygwin causes exec(2) to fail with silent "success" when an executable which requires an absent DLL is run. Perhaps we should run candle.exe via ruby-launcher, which already makes the necessary SetErrorMode invocation. It would be a perversion of the name but it might just do the trick. Sadly, of course, I can no longer easily test this. Perhaps I should try installing WiX 3 at work (but not over my WiX 2 installation) and see if it fails the same way there.
I would guess that we don't need MergeMod.dll since we stopped building salma-hayek as a WiX module. Maybe I should find out for sure but this machine is slow and Windows remains distressingly opaque, so it's probably easier to wait until someone needs to install WiX on a Windows box where it isn't already installed.
2008-02-11 04:50:47 +0000 / mad / revision 2501
lib/installer.wxs: WiX v3 won't even sniff at this file without a schema change. It doesn't compile it even then but WiX v2 doesn't seem to mind the changed schema, so this looks like a safe step in the right direction.
2008-02-10 22:08:02 +0000 / enh / revision 2500
src/e/ptextarea/PNewlineInserter.java: we need to test canOnlyAutoIndent before looking at fixIndentation if it's to have any effect.
2008-02-10 21:59:49 +0000 / enh / revision 2499
src/e/ptextarea/PNewlineInserter.java: note a deficiency.
2008-02-10 21:57:26 +0000 / enh / revision 2498
src/e/ptextarea/PNewlineInserter.java: further promotion of the hack; the previous revision implicitly assumed that PCopyingIndenter is the only indenter whose canOnlyAutoIndent returns true.
2008-02-10 21:42:52 +0000 / enh / revision 2497
src/e/ptextarea/PCopyingIndenter.java:
src/e/ptextarea/PIndenter.java:
src/e/ptextarea/PNewlineInserter.java: promote the midweek emergency hack to more permanent status, even though I'm not really sure where we ought to be going with all this. I don't know whether the fundamental design is broken, or the individual indenters are just too stupid.
2008-02-10 21:21:47 +0000 / enh / revision 2496
src/e/ptextarea/PIndenter.java: clarify a comment that still misses out the interesting part (which I don't know the answer to, and the lack of unit tests for the indentation code makes it hard to determine experimentally).
2008-02-10 20:44:27 +0000 / enh / revision 2495
lib/build/package-for-distribution.rb: avoid a likely dpkg-deb(1) failure when run with a umask different to the usual 0022, and attempt to protect the other platforms too.
2008-02-10 20:20:13 +0000 / mad / revision 2494
lib/build/parent.make: May as well support the "install" target here as it was useful to me just now.
2008-02-10 20:09:31 +0000 / mad / revision 2493
lib/build/universal.make: Now I've articulated my bad feeling about having one .PHONY target depend on another, in the email thread about my previous check-in, the principle is clearer in my mind. In particular, it's clear that the very line I checked-in contains another instance of the mistake that I avoided by not making "install" depend on "installer".
Replace "build" on the right-hand side of rule colons with $(BUILD_TARGETS). Instead of having "build" depend on "native", have it depend on the same targets which, perhaps disingenuously, aren't called $(NATIVE_TARGETS) but $(ALL_PER_DIRECTORY_TARGETS).
Move the variable assignments that depend on ALL_PER_DIRECTORY_TARGETS before the variables/rules separator. We can't correctly evaluate ALL_PER_DIRECTORY_TARGETS until we've included per-directory.make (multiple times), so add a protection mechanism to fail if we try (rather than taking make's default of incorrectly evaluating it).
Move the per-directory code up almost to the start of the rules section. We weren't obeying the comment where I said "let's keep this last". I think I either meant or should have meant that we should just keep it after the variables section. Indeed, it makes most sense to keep it at the variables/rules boundary. That minimizes the amount of code which needs to cope with variables defined after rules.
component-definitions.wxi depended on $(ALL_PER_DIRECTORY_TARGETS). At some point, it also came to depend on $(MACHINE_PROJECT_NAME).app, which had also come to depend on $(ALL_PER_DIRECTORY_TARGETS). So the first dependency was superfluous. Moreover, $(MACHINE_PROJECT_NAME).app had come to depend on "build" and "build" depended on "native" which depended on $(ALL_PER_DIRECTORY_TARGETS). So the second dependency had become obsolete too. Well, that's my belief, though I haven't even given this a once-over on Windows yet.
2008-02-10 19:08:46 +0000 / mad / revision 2492
lib/build/universal.make: One might reasonably use the nightly-build.rb script with the "install" or "installer" targets instead of native-dist. Extend the convenience hack that says "yeah, we know you can't upload a binary distribution for salma-hayek but, if you're asking for that, you'd probably like it built". On the one hand, this would be better in the nightly-build.rb script but, on the other, it is convenient to be able to build without remembering a special case for salma-hayek.
Given that, these days, we know when the Java definitely doesn't need building (and we've always known when the C++ doesn't need building), we could have the other projects build salma-hayek. We've got code for building multiple, independent C++ projects from one invocation of make, so how hard could extending that to Java be? It looks significantly simpler, mind, to get simple.make to recurse into salma-hayek first. But then we'd still want this hack, or something functionally equivalent.
2008-02-09 05:22:27 +0000 / enh / revision 2491
src/e/ptextarea/PKeyHandler.java: disable some old debugging code (but keep it compiling, to avoid bit-rot).
2008-02-09 04:42:49 +0000 / enh / revision 2490
src/e/ptextarea/PAbstractLanguageStyler.java: don't assume that multi-line comments are terminated with two-character sequence.
2008-02-08 07:04:09 +0000 / enh / revision 2489
src/e/ptextarea/PNewlineInserter.java: this hack makes PCopyingIndenter work as intended...
src/e/ptextarea/FileType.java: ...so Python can at least have some minimal auto-indentation. This is no longer unusable, but it's still pretty weak.
2008-02-08 06:52:12 +0000 / enh / revision 2488
src/e/ptextarea/FileType.java: PPythonIndenter is bad enough that no auto-indent is possibly less annoying for now. (PCopyingIndenter doesn't work, either, because it messes up the indentation of the line you're leaving when you hit return, rather than only affecting the indentation of the new line. Which given the simplicity of PCopyingIndenter suggests that the brokenness is quite fundamental.)
2008-02-07 23:05:53 +0000 / mad / revision 2487
src/e/ptextarea/PCFamilyIndenter.java: Stephen Parker supplies a patch to remedy an inconsistency between the treatment of /* and /** block comments. He'd like them to behave the same way but what really motivates me to fix it (aside from getting a patch - a rare treat!) is the inconsistency between this code and that in PNewlineInserter. Type /* and hit Enter - you'd get a " * " indent on the next line. Type colon or paste or Ctrl-I or hit Enter again and the asterisk would be whipped away. Inconsistency isn't sensible, even though either approach would be.
2008-02-06 18:50:30 +0000 / mad / revision 2486
src/e/util/GuiUtilities.java: Reverse the accidental reversal made yesterday evening, so that unshifted Alt-N gets you a new window in Terminator and unshifted Ctrl-S saves in Evergreen. Done on one line, against my leaning, to indicate that the method's just a convenience and not very interesting. I'll do new nightlies presently...
2008-02-06 05:57:23 +0000 / enh / revision 2485
src/e/util/GuiUtilities.java: expose the underlying implementation of makeKeyStroke for callers that actually need the more general form. Note especially that the hack to or-in InputEvent.SHIFT_MASK has moved up into the convenience method, so the underlying method lets its callers do anything they please.
2008-01-25 16:27:55 +0000 / mad / revision 2484
www/cygwin-problems.html: "But Ruby 1.9 was released at Christmas"... not for Windows, not in its "recommended" one-click-installer form. Write up my reasons for not doing anything (apart from helping via email) with Nikos Tzanos's troubles caused by multiple cygwin1.dll copies installed by other applications.
2008-01-18 18:10:36 +0000 / enh / revision 2483
src/e/tools/FatBits.java: FatBits has changed in 2008, so update the copyright date. Also give ourselves some minimal credit.
2008-01-18 00:54:01 +0000 / enh / revision 2482
src/e/util/Preferences.java: bring the code for "Preferences..." menu items into this class. It's slightly more complicated, as usual for library code, but it lets us remove near duplicates from the applications.
src/e/tools/FatBits.java: convert FatBits to use the new code.
2008-01-17 22:11:00 +0000 / enh / revision 2481
src/e/gui/EStatusBar.java: make our Mac OS status bars look more like native Mac OS status bars by using the right font.
2007-12-22 22:30:54 +0000 / enh / revision 2480
src/e/gui/DebugMenu.java:
src/e/gui/JFrameUtilities.java: MainFrame, as its name partially implies, is only really suitable for uses where it's the application's main frame, and its lifetime is tied to the application's lifetime. These two callers don't want MainFrame's dirty tricks.
2007-12-22 18:22:23 +0000 / enh / revision 2479
src/e/ptextarea/PTextAreaRenderer.java: I introduced a mistake a long time ago (the original, correct, code was from Ed) that I didn't notice until after Phil's watermark changes and seeing Martin with a workspace full of read-only files. This change just moves the "if opaque" down so that instead of guarding all the background-painting code (gray bits and white bits) it just guards the white bits. This looks less like a bug, in that having a watermark doesn't cause other decoration to disappear, but the effect still isn't particularly pleasing. My temptation is to pull the watermark code out of Evergreen, change it to use an ARGB image, and have PTextArea render it on top of everything else, rather than beneath everything else. My concerns are: (a) Phil's whole reason for his recent changes was performance with a particular back-end, and I don't know how it performs rendering ARGB images, and (b) PTextArea's API would get even bigger (though only by a method or two; the implementation could still live elsewhere, and be called from PTextAreaRenderer, whose size and complexity matters less).
2007-12-19 05:18:01 +0000 / enh / revision 2478
src/e/util/Preferences.java: it would be more convenient for all three current users of this class (and in keeping with the intended usage) if the subclass were responsible for knowing where its on-disk representation lives.
src/e/tools/FatBits.java: track API change.
2007-12-19 05:03:34 +0000 / enh / revision 2477
src/e/util/Preferences.java: testing with a LAF that actually draws combo boxes correctly (unlike the GTK+ LAF), it's obvious that I need to manually separate the two combo boxes.
2007-12-19 04:56:17 +0000 / enh / revision 2476
src/e/util/Preferences.java: fix FontHelper to provide a UI that lets you choose a font's size as well as its family.
2007-12-17 03:18:51 +0000 / enh / revision 2475
src/e/util/Preferences.java: for now, let's not worry about fully built-in support for color schemes; a couple of hooks so Terminator can continue to do what it currently does will suffice.
2007-12-17 02:35:58 +0000 / enh / revision 2474
src/e/util/Preferences.java: support for arbitrary preference types. Use "get" to get the value, and "setHelperForClass" to supply your own PreferencesHelper subclass for the given type. "PreferencesHelper.addRow" gains a parameter so that no external access to our descriptions is needed (and some duplication can be removed from the standard implementations too). Unrelatedly (other than that these changes are also necessary to switch Terminator over to using this class) "showPreferencesDialog" now takes a Frame rather than unnecessarily insisting on a JFrame, and we're now more robust in face of unexpected keys when reading preferences.
2007-12-03 06:35:37 +0000 / enh / revision 2473
src/e/util/Preferences.java: we're stuck with Terminator's existing preferences being saved as X11-like resources, but want to move to XML. So let's ensure that the new code can read X11 resources or XML, but only ever writes XML. (This isn't just the old XML code put back; this is brand new code that uses a much more sensible structure.)
src/e/util/XmlUtilities.java: make it possible to read XML from a String, so we don't have to read the file in twice (once to check whether it's XML or not, and again to parse the XML).
2007-12-03 00:30:55 +0000 / enh / revision 2472
src/e/ptextarea/FileType.java: better support for Emacs-like modelines. This still only looks for a clue as to the major mode (as is right and proper for the FileType class; fuller parsing of modelines would belong elsewhere).
2007-11-27 21:23:27 +0000 / mad / revision 2471
src/e/ptextarea/FileType.java: Clarify the situation regarding emacs mode strings by removing a reference to a no-longer extant set of methods and other cosmetic improvements. Really, though, I'm just doing this to point Chris in the right direction, should he want to generalize this to cover the case he's currently interested in.
2007-11-27 05:10:33 +0000 / enh / revision 2470
src/e/gui/HelpMenu.java: talking to simonj made me realize it's rather mad that the link to the main page is buried away and not right next to the change log and FAQ links.
2007-11-26 06:38:47 +0000 / enh / revision 2469
src/e/util/Preferences.java: switch to using X11-style "resources" files instead of XML for persistent storage.
src/e/tools/FatBits.java: fix the filename accordingly.
2007-11-26 05:07:36 +0000 / enh / revision 2468
src/e/util/Preferences.java: a general-purpose extended subset of Terminator's preferences mechanism, intended for use in all projects (including replacing the current implementation in Terminator). Note that this code uses a trivial XML format where Terminator currently uses something more like X11 resources. I think X11 resources are better. They're more easily read and edited by humans, and they're what we're already using in one of our applications. I can't really see anything we gain by using XML here, even if we used a fancier schema, such as something more like Mac OS' plists. The only obvious advantage of XML is that it's better for supporting sequences and maps, but I don't think this is the preferences mechanism for either of those things anyway. Something like the Mailer "accounts manager" can and should (and does) use XML, but the general preferences? Probably not.
src/e/tools/FatBits.java: as a demonstration, here's FatBits modified to have persistent preferences.
2007-11-24 20:51:24 +0000 / enh / revision 2467
src/e/gui/GnomeStockIcon.java: support a wider range of GTK+ mnemonics for buttons.
src/e/gui/AboutBox.java: remove a couple of special cases now handled more generally.
2007-11-24 00:15:20 +0000 / enh / revision 2466
src/e/ptextarea/PStyle.java:
src/e/ptextarea/PTextArea.java: use UIManager properties more widely (specifically, for the background color), and consistently use the EditorPane defaults rather than the TextArea ones. There doesn't appear to be anything to choose between EditorPane and TextPane, but TextArea – judging by the default gray background on Linux – may be intended as something else (or that may just be another Sun LAF bug).
2007-11-23 05:19:35 +0000 / enh / revision 2465
src/e/ptextarea/PKeyHandler.java: move "hungry delete" (delete back to first non-whitespace) onto control-backspace, and add delete back to beginning of line on alt-backspace. This makes all the functionality available in all PTextAreas and improves the out-of-box experience for Python programmers especially, at the cost of "hungry delete" no longer being the default, which has made editing seem slow and cumbersome in the time I've been building up to this. Hopefully when all my PTextAreas offer it, I'll be able to get used to using control-backspace.
src/e/util/Parameters.java: this class is no longer needed outside Evergreen.
2007-11-23 05:07:27 +0000 / enh / revision 2464
bin/nightly-build.rb: improve support for building Mercurial projects, and add support for Bazaar projects (rare though they may be).
2007-11-23 04:59:59 +0000 / enh / revision 2463
src/e/demo/PTextAreaDemo.java: my previous change to this code broke it (by commenting out the loop's variant); it had been done in the name of appeasing GCJ rather than utility, and I hadn't tested that the result worked, just that it compiled. So fix it by removing all the cruft.
2007-11-23 02:44:44 +0000 / enh / revision 2462
src/e/util/IndentationGuesser.java: we shouldn't be retrieving the fallback indentation from a deprecated source. Pass it in explicitly instead.
src/e/demo/PTextAreaDemo.java:
src/e/testing/PIndenterTester.java: fix callers, one of which also has unrelated tidying.
2007-11-23 01:16:17 +0000 / enh / revision 2461
src/e/gui/GnomeStockIcon.java: add a couple more stock icons.
2007-11-21 23:47:26 +0000 / enh / revision 2460
src/e/util/XmlUtilities.java: collect some of the magic required for almost-convenient XML handling in Java.
2007-11-21 22:51:56 +0000 / enh / revision 2459
src/e/util/StringUtilities.java: gain a handy utility from Evergreen.
2007-11-21 22:36:33 +0000 / enh / revision 2458
src/e/ptextarea/PKeyHandler.java: I'm not sure I've ever used this functionality, and it stands in the way of letting shift-tab in Mailer move focus back to the subject line, which I do find myself trying to use on a regular basis.
2007-11-19 05:54:36 +0000 / enh / revision 2457
src/e/ptextarea/PPythonIndenter.java:
src/e/ptextarea/FileType.java: a new Python auto-indenter.
2007-11-19 05:46:14 +0000 / enh / revision 2456
src/e/ptextarea/PGenericIndenter.java: if the indent pattern can be missing, there's no reason why the unindent pattern can't be missing too. I have no present use for this, but thought I might.
2007-11-18 20:33:16 +0000 / mad / revision 2455
bin/ithaki.sh: Actually, that whole comment section was overtaken by Debian shipping etch a long time ago. It's a long time since we upgraded ithaki.
2007-11-18 20:31:10 +0000 / mad / revision 2454
bin/ithaki.sh: wide's unreachable today, reminding me that, now I have a 64 bit build server at work, there's no reason to continue inflicting this build on Eric, although I don't remember him ever noticing.
2007-11-16 06:50:12 +0000 / enh / revision 2453
src/e/gui/HtmlPane.java: JTextPane doesn't store the actual HTML it was given, and attempts to reconstruct the HTML from its internal model. Given that my most likely use of this is to investigate Swing HTML parsing bugs, I'd much rather see the actual HTML that's upset it. (It's possible I might want to see both, but experience so far suggests that the problem's usually pretty obvious and the original HTML is more useful.)
2007-11-16 05:17:39 +0000 / enh / revision 2452
src/e/gui/HtmlPane.java: any HTML view should have a "View Source" pop-up menu item.
2007-11-14 04:12:32 +0000 / enh / revision 2451
src/e/gui/DialogFocusRedirector.java:
src/e/gui/EMenuBar.java:
src/e/gui/ETable.java:
src/e/ptextarea/PMouseHandler.java: don't use Class.cast unless it's actually necessary.
2007-11-14 03:21:10 +0000 / enh / revision 2450
src/e/gui/ETable.java:
src/e/gui/JHyperlinkButton.java:
src/e/gui/SearchField.java:
src/e/util/GuiUtilities.java: Ed points out that the current Mac OS 10.4 "os.version" is "10.4.10".
2007-11-13 18:44:43 +0000 / enh / revision 2449
src/e/gui/ETable.java: don't bother with a work-around on Mac OS 10.5, where the bug is fixed; prepare editors as we prepare renderers, for more consistent appearance; make use of Mac OS 10.5's ability to render smaller checkboxes.
2007-11-13 17:58:57 +0000 / enh / revision 2448
src/e/gui/SearchField.java: on Mac OS 10.5, Apple does all the work of making a convincingly native search field for us, so defer to them for a better experience.
2007-11-13 17:55:22 +0000 / enh / revision 2447
src/e/gui/JHyperlinkButton.java: on Mac OS 10.5, we need to setBorderPainted(false) to turn off the default button border; just setting the border to null is insufficient. Also add a special case for Mac OS' standard "help" buttons, which are now available in Java.
2007-11-13 17:50:15 +0000 / enh / revision 2446
src/e/util/GuiUtilities.java: on Mac OS 10.5, there's a new simpler way to set a window's alpha, and the old hack no longer works.
2007-11-13 05:33:47 +0000 / enh / revision 2445
lib/build/universal.make: to build on Mac OS 10.5 with the 10.4 SDK, we need an extra switch. When we drop support for 10.4, we can either remove this or update it to 10.5; the latter might save similar head-scratching come 10.6.
2007-11-12 19:02:54 +0000 / mad / revision 2444
lib/build/simple.make:
lib/build/universal.make: The clarity's worth more than compatible with make versions that don't support $(lastword). I see we depend on $(firstword) in the version checking code, which is more dubious.
2007-11-12 06:23:23 +0000 / mad / revision 2443
simple.make: The more I use it, the more I agree with Linus about Subversion.
2007-11-12 06:21:26 +0000 / mad / revision 2442
simple.make: Nope, it's going to make me do it in three stages.
2007-11-12 06:20:12 +0000 / mad / revision 2441
simple.make: Move simple.make to lib/build/ too and replace it with a symlink to the new location. I could replace it with a regular make file but then that would have to temporarily gain the make version check and a third copy of the salma-hayek locator code. That's too much pain for a temporary crutch.
lib/build/simple.make: The disadvantage of a symlink is that we need a temporary hack in the salma-hayek locator to cope with being included through a different path. Update the instructions too.
www/index.html: And the example error messages.
lib/build/make-new-project.sh: New projects should use the new location.
Makefile: Set a good example by using the new location ourselves.
Subversion appears unwilling to let me replace a regular file with a symlink in one check-in. Let's see if it will let me do it in two.
2007-11-12 05:44:35 +0000 / mad / revision 2440
simple.make: Refresh this slightly different copy of the salma-hayek locator code from universal.make.
2007-11-12 05:41:09 +0000 / mad / revision 2439
lib/build/universal.make: Lose the make version check to where it stands a chance of being executed by older makes. Lose a small piece of the make manual - I don't know why that particular wrinkle got a mention.
simple.make: Gain the make version check. Modernize the adjacent comments (whose rust I noticed while deciding where to paste).
2007-11-12 05:20:43 +0000 / mad / revision 2438
lib/build/universal.make: I was half-expecting to break Mercurial-based builds or Mac builds or builds of a project that I don't have checked-out but there was no excuse for checking in before testing that salma-hayek still built.
Try to say fewer things per line. We do need one := - put it in the right place and give it a comment.
2007-11-12 04:48:43 +0000 / mad / revision 2437
More root directory clean-ups.
java.make: This looks like a remnant from before the days when universal.make did a good job with Java.
parent.make:
lib/build/parent.make: I don't think anyone but me uses this makefile, so no-one will mind it moving.
per-directory.make:
lib/build/per-directory.make: This makefile has always been internal-use-only.
universal.make:
lib/build/universal.make: This makefile used to be used externally. I don't think it is any longer though it does still work when used like that. It's very verbose about what it's doing, so any users who haven't switched to simple.make probably want to.
lib/build/make-new-project.sh: Hmm, follow that advice here, rather than tracking universal.make's move.
lib/build/package-for-distribution.rb: But this invocation is used internally for the build and wants the verbosity.
simple.make: Leave this makefile where it is for the moment, for the sake of all the other projects that are using it.
2007-11-12 04:31:03 +0000 / mad / revision 2436
escaping.rb:
patch-to-html-email.rb: Move two scripts that aren't really intended for stand-alone use to...
lib/build/escaping.rb:
lib/build/patch-to-html-email.rb: ... somewhere hidden away. They aren't used in building but in post-commit and other patch mailing but at least lib/build/ isn't as in your face.
bin/mailpatch.rb: Adapt and modernize the one user-facing script that uses these directly, although I've nothing against putting lib/build/ on the path for the "require". (Shame that it's called something as obtuse as $:.)
incoming:
post-commit: Do a similar job on both versions of the post-commit script. This removes the subtle repetition of the assumption that the hook script is in the root directory of salma-hayek.
lib/build/svn-log-to-html.rb: This post-build script was already more modern.
2007-11-10 19:05:02 +0000 / enh / revision 2435
src/e/ptextarea/PEmailTextStyler.java: document one other problem I found mentioned in my mails on the subject.
2007-11-10 18:56:32 +0000 / enh / revision 2434
src/e/ptextarea/PEmailTextStyler.java: fix parochialisms (and then find that almost none of the comment was true any longer), remove a dead field, order fields into the traditional order, stop considering ":" and "|" to be quoting characters because I haven't seen anyone use those since 1997 and they do cause quoted Ruby source to be rather too colorful, remove STRING and KEYWORD as suitable quoting styles (COMMENT is okay for now), disable the signature detection until it's improved, and comment various other problems.
2007-11-07 17:05:56 +0000 / mad / revision 2433
bin/invoke-java.rb: Missed one, due to having other, long-standing but dubious unchecked-in changes.
2007-11-07 17:05:17 +0000 / mad / revision 2432
native/all/setpgid/setpgid.cpp:
native/all/setpgid/setsid.cpp: Fix my renaming omission. It's probably better to do this in a separate check-in because this one has no changes, despite looking like it's changing the whole file. And Subversion, of course, doesn't let me do this whole process atomically anyway.
2007-11-07 17:03:33 +0000 / mad / revision 2431
native/all/setpgid/setsid.cpp: Adapt the hard-coded argv[0] in the usage. I've forgotten to rename the source file, haven't I?
src/e/util/ProcessUtilities.java: Adapt to the new name for "setsid". Spelling "mistakes" are probably preferable to hiding grep matches with dubious use of CamelCase like "setSid".
universal.make: Fix an obsolete example. I wonder what version of make is shipped with Mac OS 10.5.
2007-11-07 16:54:07 +0000 / mad / revision 2430
native/all/setsid: Subversion won't let scm non-recursively commit a directory deletion.
This check-in brought to you by EDITOR=vim svn commit native/all/setsid.
2007-11-07 16:47:57 +0000 / mad / revision 2429
native/all/setsid: Not for the first time, this program confuses me. It doesn't call setsid and, according to the history, it never has.
native/all/setpgid: It calls setpgid instead. setsid is not a useless function - we use it in Terminator. The util-linux setsid that we're hiding actually does call setsid. We shouldn't pretend to be what we're not.
native/all/setsid/setsid.cpp: This needs replacing too, but Subversion won't let me do that until I've committed this. Sorry.
2007-11-04 21:32:21 +0000 / mad / revision 2428
bin/find-jdk-root.rb: Fix my previous change to package-for-distribution.rb to work for Linux. I like the idea of having a Pathname class that has a convenient way of constructing directory components without bothering about File.SEPARATOR but using operator+ for it was a crippling mistake that's led to Elliott removing calls to it elsewhere. The use of operator<< with arrays was grim but still a better choice.
2007-11-04 21:15:44 +0000 / mad / revision 2427
lib/build/package-for-distribution.rb: I can build happily on this Windows laptop but trying to make an installer failed with a rather cryptic error (generated by us) because Kernel.system failed to find jar. We use a script to select the JDK elsewhere during the build process, so it makes sense to use the consistent version of jar here too.
2007-11-04 16:54:27 +0000 / enh / revision 2426
TODO: notes from Apple's java-dev mailing list on something to try when one of us has 10.5 to test on.
2007-11-01 02:43:14 +0000 / enh / revision 2425
src/e/gui/GnomeStockIcon.java: the absence of the "OK" mnemonic is quite glaring whenever it appears next to "Cancel".
2007-11-01 02:05:50 +0000 / enh / revision 2424
src/e/gui/HtmlPane.java: delegate addKeyListener and removeKeyListener to the underlying JTextPane.
2007-11-01 01:04:00 +0000 / mad / revision 2423
universal.make: GuiUtilities changed in a way that was source-compatible with Terminator's usage but not runtime compatible. We must recompile our Java if salma-hayek's been recompiled. Darn, I thought we had those Java dependencies nailed, but it was clear what the problem was and it was easy to fix.
2007-10-31 21:47:43 +0000 / enh / revision 2422
src/e/util/GuiUtilities.java: make it possible to cancel keepMaximumShowing's auto-scrolling.
2007-10-31 20:15:51 +0000 / pcn / revision 2421
src/e/ptextarea/PEmailTextStyler.java: A new text styler for dealing with emails. This recognises various levels of commenting, and also (correctly-separated) signatures.
src/e/ptextarea/FileType.java: Include the new text styler in our styler enumeration.
2007-10-29 05:31:07 +0000 / enh / revision 2420
src/e/gui/JFrameUtilities.java: fix this test now the filename is likely to be null, but should never be non-null but empty.
2007-10-29 05:29:12 +0000 / enh / revision 2419
bin/invoke-java.rb: don't set the org.jessies.frameIcon property to a useless value.
2007-10-27 21:16:46 +0100 / enh / revision 2418
src/e/gui/GnomeStockIcon.java: add another useful GNOME stock icon.
2007-10-26 19:51:34 +0100 / mad / revision 2417
post-commit: Modernize style - we use double quotes unless we're deliberately preventing interpolation and we always use parentheses on method invocations (except for the like of "raise" which is a keyword in other languages)...
incoming: ... before the superstitions spread any further. Superstitions, like inconsistencies, make it harder to learn a language. "Oh, shift is special".
2007-10-26 19:18:53 +0100 / enh / revision 2416
src/e/gui/HtmlPane.java: work around Sun bug 4233012, and hack the style sheet to make HTML text look more like normal TextArea text.
2007-10-26 10:40:40 +0100 / car / revision 2415
src/e/ptextarea/PTextAreaSpellingChecker.java: Undo accidental commit of local optimisation.
2007-10-26 10:33:03 +0100 / car / revision 2414
incoming: Added. A rough and ready first attempt at a post-commit-like script for Mercurial, initially to be executed by Mercurial's incoming hook.
2007-10-26 05:02:12 +0100 / enh / revision 2413
src/e/gui/AboutBox.java: make the full identification details available to the program itself, not just as a subject line for bug reports.
2007-10-25 22:26:58 +0100 / enh / revision 2412
src/e/forms/FormPanel.java: there's no reason why outsiders shouldn't be able to use FormPanel directly; it's perfectly usable and useful on its own.
2007-10-25 22:16:48 +0100 / enh / revision 2411
www/downloads.html: show in the copy & paste instructions how to actually build the source when you've checked it out. If you don't know what's in salma-hayek, as Colin Walters didn't, it's not necessarily obvious what the errors from GNU Make are telling you if you try building a project without having built salma-hayek first.
2007-10-24 04:23:02 +0100 / enh / revision 2410
src/e/util/ComponentUtilities.java: as I redirected home/end last night, I wondered why I hadn't done so earlier. mad pointed out today that these keys are generally cursor movement keys, and useful in text fields. So only redirect them if the component we're redirecting key strokes from isn't a text field. (I'm ignoring more general text components because they're unlikely to have this method invoked on them, because they're unlikely to have any other component associated with them.)
2007-10-23 07:10:32 +0100 / enh / revision 2409
src/e/util/ComponentUtilities.java: viewing patches, I haven't found much use for being able to jump to the top or bottom with the keyboard. Viewing mail, I find this keyboard functionality invaluable. (I've never understood why Outlook, though one of Windows' would-be redeeming features is its tendency to have good support for keyboard-only use, misses this where Apple, who wouldn't know a keyboard if it acted as a crutch for their one-button mouse, get it right. We have NeXT to thank, probably.)
2007-10-23 06:55:41 +0100 / enh / revision 2408
src/e/gui/HtmlPane.java: hiding the complicated JTextPane API by presenting ourselves as a JPanel is all well and good, but we need to implement Scrollable if we're to behave sensibly in a JScrollPane. So mainly pass through to the JTextPane, but avoid asking for a horizontal scroll bar. Also pull out some of the most deeply-indented code into its own method; it was offending me every time I saw it.
2007-10-23 06:17:15 +0100 / enh / revision 2407
src/e/util/GuiUtilities.java: Chris Reece reports a problem on the two-hit JDK5/Solaris retro combo. It looks like Sun ships the X11 classes but not the JNI library, or maybe that they've already loaded the Motif JNI library by this point, and the two would conflict:
java.lang.UnsatisfiedLinkError: initIDs
at sun.awt.X11.XWindow.initIDs(Native Method)
at sun.awt.X11.XWindow.<clinit>(XWindow.java:82)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at e.util.GuiUtilities.setFrameAlpha(GuiUtilities.java:313)
Anyway, to cope with breakage like this, catch Throwable and use Log.warn, as the WM_CLASS code already correctly did.
2007-10-22 06:56:33 +0100 / enh / revision 2406
src/e/gui/HtmlPane.java:
src/e/tools/HtmlViewer.java: pull the HTML stuff out into its own class, for easier embedding.
2007-10-22 03:29:53 +0100 / enh / revision 2405
src/e/tools/HtmlViewer.java: as long as HtmlViewer serves as the copy-and-paste source for using Swing's HTML functionality, it should aim to be as useful as possible.
2007-10-22 02:50:33 +0100 / enh / revision 2404
src/e/gui/GnomeStockIcon.java: I'm not sure how I missed "OK"; perhaps I've been too successful at finding a more specific label for my buttons. Anyway, sometimes "OK" is as good as it gets, so let's have the appropriate appearance for that button too.
2007-10-17 06:36:42 +0100 / enh / revision 2403
src/e/ptextarea/FileType.java: I only meant to claim ".talc" as an extension. As mad says, FAT16 users can have the other three.
2007-10-17 06:07:21 +0100 / enh / revision 2402
src/e/ptextarea/PTextAreaSpellingChecker.java: fix another two raw type warnings and an unused local variable warning.
2007-10-17 06:06:45 +0100 / enh / revision 2401
src/e/gui/ChronologicalComboBoxModel.java:
src/e/gui/ETree.java:
src/e/util/StringUtilities.java: fix a few more raw type warnings.
2007-10-17 06:05:27 +0100 / enh / revision 2400
src/e/ptextarea/FileType.java:
src/e/ptextarea/PTalcTextStyler.java: add support for editing Talc scripts.
2007-10-17 05:52:16 +0100 / enh / revision 2399
www/cygwin-subfaq.html:
www/faq.html: factor out the "I'm having problems with Cygwin!" entry, so we can easily include it in other projects' FAQs.
2007-10-14 01:46:48 +0100 / mad / revision 2398
lib/build/filter-build-output.rb: Forwarding the zero-ness of the exit status turns out to be easier than I expected. I think the child will always have exited by this point, so I presume its exit status will be collected no later than when I ask for it.
2007-10-14 01:24:44 +0100 / mad / revision 2397
lib/build/filter-build-output.rb: You might think the IO.popen() documentation would tell you the incantation for piping stderr as well as stdout, or that reopen's documentation would mention dup or dup2. I've used it once before but I'd not have found that instance without already having the answer. Google thankfully remains excellent.
2007-10-14 01:10:30 +0100 / mad / revision 2396
lib/build/filter-build-output.rb: I don't understand when Ruby choose default objects on which to invoke eg gets(). Still, I'm glad it (eventually) told me that I'd messed up in my parameterization check-in earlier.
/Users/mad/software.jessies.org/work/salma-hayek/lib/build/filter-build-output.rb:19:in `gets': No such file or directory - make (Errno::ENOENT)
from /Users/mad/software.jessies.org/work/salma-hayek/lib/build/filter-build-output.rb:19:in `filterBuildOutput'
from /Users/mad/software.jessies.org/work/salma-hayek/lib/build/filter-build-output.rb:48
from /Users/mad/software.jessies.org/work/salma-hayek/lib/build/filter-build-output.rb:43:in `popen'
from /Users/mad/software.jessies.org/work/salma-hayek/lib/build/filter-build-output.rb:43
2007-10-14 01:02:07 +0100 / mad / revision 2395
simple.make: Move the "filter" invocation onto the front of the command line, passing the universal.make command line as arguments.
lib/build/filter-build-output.rb: Run ARGV down a pipe and filter its output.
This was my first thought. It doesn't solve the original problem - the exit status of the child command is still ignored. I'm not sure we're filtering the command's stderr. I think this is the right direction, so I'll check-in (as it's still basically functional) and then work on fixing those.
2007-10-14 00:42:10 +0100 / mad / revision 2394
lib/build/filter-build-output.rb: A large cosmetic-only change to parameterize the input stream for filtering, so I can change it to be a pipe in the next check-in without appearing to have changed the whole file.
2007-10-14 00:33:29 +0100 / mad / revision 2393
simple.make: The make convention, as decreed by $(if), is that an empty string means false whereas a non-empty one means true. Really, I want to be attacking the pipefail problem with the "recurse" rule but, before I rewrite it, I need to understand it. Having the "then" and "else" clauses contradict the condition variable's name wasn't helping. All I've done here is rename the variable to match its contents.
2007-10-14 00:30:00 +0100 / mad / revision 2392
simple.make: $(filter) wasn't what I wanted here. MAKEFLAGS = pn is what you get when you pass -n -p.
2007-10-13 22:53:32 +0100 / enh / revision 2391
src/e/gui/StopIcon.java: improve the appearance of the stop icon, and keep it from disappearing when disabled.
2007-10-12 18:48:13 +0100 / enh / revision 2390
src/e/util/Parameters.java: actually, for now, dump this functionality in (the deprecated class) Parameters, where it best belongs.
2007-10-12 18:40:33 +0100 / enh / revision 2389
src/e/util/FileUtilities.java: remove a few error- and inefficiency-prone methods that are only used in Evergreen (where I'm about to reimplement them).
2007-10-05 07:11:38 +0100 / enh / revision 2388
src/e/gui/ArrayListTableModel.java: remove unused (and not particularly useful) class.
src/e/gui/DebugMenu.java:
src/e/gui/HeapView.java:
src/e/gui/HorizontalScrollWheelListener.java:
src/e/ptextarea/PTextAreaRenderer.java:
src/e/tools/JarExplorer.java:
src/e/tools/JavaHpp.java:
src/e/tools/ShowUiDefaults.java:
src/e/util/InAppServer.java:
src/e/util/Launcher.java:
src/e/util/Log.java:
src/e/util/Stopwatch.java: fix raw type, unused local/field/method, and unnecessary cast warnings.
2007-10-04 06:59:31 +0100 / enh / revision 2387
src/e/gui/EMenuBar.java:
src/e/util/ProcessUtilities.java: remove unused locals.
src/e/gui/HelpMenu.java: remove unused field.
2007-10-04 06:54:25 +0100 / enh / revision 2386
universal.make: disable a silly warning that makes bad suggestions.
2007-10-04 06:17:43 +0100 / enh / revision 2385
src/e/debug/EventDispatchThreadHangMonitor.java:
src/e/debug/HungAwtExit.java:
src/e/forms/FormPanel.java:
src/e/gui/DialogFocusRedirector.java:
src/e/gui/HeapView.java:
src/e/gui/HelpMenu.java:
src/e/gui/JAsynchronousProgressIndicator.java:
src/e/gui/SimpleDialog.java:
src/e/ptextarea/BugDatabaseHighlighter.java:
src/e/ptextarea/HyperlinkStyleApplicator.java:
src/e/ptextarea/PAbstractLanguageStyler.java:
src/e/ptextarea/PAbstractTextStyler.java:
src/e/ptextarea/PActionFactory.java:
src/e/ptextarea/PAnchorSet.java:
src/e/ptextarea/PBashIndenter.java:
src/e/ptextarea/PFind.java:
src/e/ptextarea/PIndenter.java:
src/e/ptextarea/PPlainTextStyler.java:
src/e/ptextarea/PRubyIndenter.java:
src/e/ptextarea/PTextStyler.java:
src/e/ptextarea/RegularExpressionStyleApplicator.java:
src/e/ptextarea/TabStyleApplicator.java:
src/e/ptextarea/UnprintableCharacterStyleApplicator.java:
src/e/ptextarea/UnprintableCharacterTextSegment.java:
src/e/tools/FatBits.java:
src/e/toys/world/WorldClock.java:
src/e/util/BrowserLauncher.java:
src/e/util/GuiUtilities.java:
src/e/util/StringHistory.java: remove unused imports.
src/e/ptextarea/PNewlineInserter.java: remove an unused import and an unused local.
src/e/util/NumberDecoder.java: remove an unused field.
2007-10-03 21:42:35 +0100 / mad / revision 2384
lib/build/file-list-to-wxi.rb: Fix Cygwin installer build, which was failing with:
/software.jessies.org/work/salma-hayek/lib/build/file-list-to-wxi.rb:7:in `require': no such file to load – /software.jessies.org/work/salma-hayek/lib/lib/build/uuid.rb (LoadError)
from /software.jessies.org/work/salma-hayek/lib/build/file-list-to-wxi.rb:7
lib/build/ensure-repository-orthography.rb:
lib/build/svn-log-to-html.rb: Adapt other scripts that were recently moved to this directory in a similar way, so they still find salma-hayek's root correctly. I haven't tested either of them - just fixing it while I think of it.
2007-10-03 20:53:36 +0100 / mad / revision 2383
HACKING: The history doesn't say where this superstition came from. I've failed to find anything in my saved email (which isn't surprising given how little there is to search on). I say "superstition" because it's not really ringing any bells in my mind. All the problems I remember were with Ruby, though I might have assumed it was a Windows thing. I do have a vague feeling that we got a Ruby exception when writing to (unopened) $stderr and then tried to dump a stack trace... to $stderr. Perhaps the exception handler reentered itself (though that sounds like it would be a Ruby bug). Perhaps it was Ruby's default exception handler. Even if it had applied to Java as well as Ruby, ruby-launcher fixed this issue, by opening "/dev/null" as file descriptors 1 and 2 if they're not already open. If it happens again, I'm sure we'll record it more convincingly.
2007-10-03 06:22:07 +0100 / enh / revision 2382
bin/ensure-repository-orthography.rb:
bin/make-new-project:
lib/build/ensure-repository-orthography.rb:
lib/build/make-new-project.sh: move a couple of scripts that are only ever run by hand (if that; especially since future repositories are likely to be Mercurial rather than Subversion).
2007-10-03 06:17:30 +0100 / enh / revision 2381
bin/find-jdk-root.rb:
bin/which.rb: inline "which.rb" into its only caller. There's also a Talc replacement for this.
2007-10-03 06:14:54 +0100 / enh / revision 2380
bin/filter-build-output.rb:
lib/build/filter-build-output.rb:
simple.make: move another bit of the build system.
2007-10-03 06:13:29 +0100 / enh / revision 2379
bin/escape-for-html.rb:
bin/make-img-tag.rb: I'm already using the Talc replacements for these scripts.
2007-10-03 06:10:13 +0100 / enh / revision 2378
bin/javahpp:
bin/javahpp.rb:
universal.make: "javahpp" is (potentially) an end-user tool, so it shouldn't have a script extension.
2007-10-03 06:08:11 +0100 / enh / revision 2377
dist-exclude:
lib/build/dist-exclude:
universal.make: move another part of the build system out of the way.
2007-10-03 06:05:27 +0100 / enh / revision 2376
bin/file-list-to-wxi.rb:
bin/make-version-file.rb:
bin/package-for-distribution.rb:
bin/svn-log-to-html.rb:
bin/uuid.rb: move these files...
lib/build/file-list-to-wxi.rb:
lib/build/make-version-file.rb:
lib/build/package-for-distribution.rb:
lib/build/svn-log-to-html.rb:
lib/build/uuid.rb: ...into the new directory for build scripts.
universal.make: update the makefile.
2007-10-03 05:57:31 +0100 / enh / revision 2375
universal.make: make it possible to set JAVA_COMPILER from the environment, and make it possible to choose GCJ as your Java compiler. Also an independent but related hack to add a "make gcj" target to install a GCJ-compiled native binary in /usr/bin/. (Note that GCJ use requires GCJ_MAIN_CLASS to be set to the class whose main method you want the generated binary to run.)
2007-10-03 05:48:14 +0100 / enh / revision 2374
lib/build: new directory for build scripts and the like.
2007-10-03 05:37:41 +0100 / enh / revision 2373
bin/send-meeting-requests-to-ical.rb: I haven't used this in forever, and this repository isn't the right place for it anyway. It's on my blog if I need it again, which I won't.
2007-10-03 05:33:41 +0100 / enh / revision 2372
bin/xv:
src/e/tools/Xv.java: I now have a machine so fast even GIMP loads in an acceptable time, and my only real complaint with "Eye of GNOME" is its ridiculous name. I've been threatening to get rid of Xv for ages, and no-one's spoken up in its defense, so out it goes...
2007-10-02 18:32:21 +0100 / mad / revision 2371
bin/install-everything.sh: A copy of this was added to BlueArc's misc repository on 2006-06-09, where it's been improved. I've copied the FIXME to Terminator's TODO although, on reflection, I should have copied the code too.
2007-10-02 16:07:36 +0100 / enh / revision 2370
src/e/util/FileUtilities.java: Chris Reece had trouble with us translating /home/car/Projects/terminator to ~Projects/terminator instead of ~/Projects/terminator, because his HOME was /home/car/ instead of /home/car. Make life simpler for callers (and fix his problem) by guaranteeing that getUserHomeDirectory returns a string with no trailing File.separators.
2007-09-27 21:12:46 +0100 / enh / revision 2369
universal.make: make it possible to build source .tar.gz files for Mercurial-based projects.
2007-09-25 22:20:33 +0100 / mad / revision 2368
TODO: WiX makes everything difficult but I haven't even looked into how to implement these RFEs, so remove the misleading impression that I have. My "objection" to opening a monolog box to say "Hey dude! Success!!1 We've done the right thing!" isn't that it's difficult - it's just depressing. The most compelling argument for having such a box is to say "look on the desktop - we haven't sprayed shortcuts into some random sub-directory of your start menu that you'll never find".
2007-09-22 01:10:42 +0100 / enh / revision 2367
TODO: move the (Windows) installer-related to-do items that were hiding in Terminator's to-do list here.
2007-09-22 01:06:09 +0100 / enh / revision 2366
src/e/debug/EventDispatchThreadHangMonitor.java:
src/e/gui/JFrameUtilities.java:
src/e/ptextarea/PTextAreaSpellingChecker.java:
src/e/tools/JavaHpp.java:
src/e/tools/Xv.java:
src/e/util/FileUtilities.java:
src/e/util/GuiUtilities.java:
src/e/util/InAppServer.java:
src/e/util/Parameters.java:
src/e/util/SpellingChecker.java: it might be easier to quote like 'this' than like "this" in source, but the former looks weird.
2007-09-21 23:46:28 +0100 / enh / revision 2365
bin/package-for-distribution.rb: support installation of section 1 manual pages.
2007-09-21 21:02:06 +0100 / enh / revision 2364
src/e/forms/FormDialog.java:
src/e/gui/JFrameUtilities.java: move the Window-geometry preservation code to JFrameUtilities (which should probably be called WindowUtilities).
2007-09-21 18:05:15 +0100 / enh / revision 2363
bin/install-build-prerequisites.sh: replace our build-dependencies shell script...
bin/package-for-distribution.rb:
lib/DEBIAN-control-Build-Depends.txt: with proper Debian build dependencies. Use "sudo apt-get build-dep org.jessies.terminator" (or whatever) to get those packages you don't already have.
2007-09-21 18:02:04 +0100 / enh / revision 2362
bin/install-build-prerequisites.sh: our non-build dependencies are now expressed elsewhere.
2007-09-20 02:25:49 +0100 / mad / revision 2361
www/cygwin-setup.html: Now the message no longer says "you can safely ignore this", we'd better stop advising the reader to ignore it. I wonder how I installed. I've overwritten my /etc/passwd and /etc/group by following the suggestions, with the -d options. That stopped Terminator from running until I jumped through another hoop. I wonder if my nightly build will break.
2007-09-20 02:13:35 +0100 / mad / revision 2360
www/cygwin-setup.html: Mark Connell points out that our quote of the Cygwin "mkgroup" message is out-of-date. In particular, the "message is only displayed once" part has gone... and the message is displayed in every new terminal, as Mark says.
2007-09-19 01:04:54 +0100 / enh / revision 2359
src/e/ptextarea/FileType.java:
src/e/ptextarea/PCSharpTextStyler.java: basic coloring for C#. As far as I know, we can share the Java indenter.
2007-09-08 05:42:00 +0100 / enh / revision 2358
bin/package-for-distribution.rb: remove some duplication and use relative symbolic links to make it possible for users to install our packages somewhere other than /.
2007-09-08 05:25:59 +0100 / enh / revision 2357
bin/show-alert.rb: fix this lintian(1) complaint:
W: org.jessies.evergreen: script-not-executable ./usr/share/software.jessies.org/evergreen/Resources/salma-hayek/bin/show-alert.rb
2007-09-06 16:23:01 +0100 / enh / revision 2356
src/e/util/GuiUtilities.java: don't try to run the X11 code on Windows. That's silly.
2007-09-06 16:19:01 +0100 / enh / revision 2355
www/index.html: work around the same problem in the other file I touched. If anyone knows how to fix the CSS, I'm happy enough with our appearance, but I'd rather not have all the minor irritations!
2007-09-06 16:16:03 +0100 / enh / revision 2354
www/downloads.html: work around what's probably a problem with my CSS.
2007-09-06 16:14:32 +0100 / enh / revision 2353
www/downloads.html:
www/index.html: make the instructions clearer for anyone who ignores our advice to use Subversion and tries to use a .tar.gz instead. Include the specific error message they're likely to see.
2007-09-05 21:39:30 +0100 / mad / revision 2352
bin/find-jdk-root.rb:
universal.make: Adapt to the new java-launcher name in comments...
bin/invoke-java.rb: ... and in the code that specifies the executable's path. I considered changing @launcher and friends to @java_launcher. That might still be a good idea but it obscured the necessary change so it would be better in a separate, cosmetic-only check-i