ewx: (geek)

Further to this…

Model Problems

  • P4 doesn’t merge renames correctly. Instead when you merge a rename operation, it deletes the rename source in the destination branch and copies the source branch’s version of the renamed file(s). You have to manually re-do the rename every time you merge across it - expensive if you are in a branch-heavy environment.
Details )

VCS 0.6

Jul. 12th, 2009 06:55 pm
ewx: (geek)

I have released VCS 0.6.

What's VCS?

Do you find yourself typing bzr commit in Git branches, or cvs diff in your Perforce workspace? Then perhaps VCS is for you.

VCS is a wrapper for version control systems. It presents an essentially uniform interface to the user, allowing ‘muscle memory’ to use vcs commands rather than adapt to the version control system currently in use. Of course, the downside is that you have yet another three-letter command to start using!

The supported systems are Bazaar, Git, CVS, Subversion, Mercurial, Darcs and Perforce. More could be added. The supported commands are add, annotate (blame), clone, commit, diff, edit, log, remove, revert, status, update. Again, more could be added.

Where Do I Get It?

http://www.greenend.org.uk/rjk/2009/vcs.html for source code, .deb files and Bazaar branches.

What's New In VCS 0.6?

Various things )
ewx: (geek)

Missing Features

Things that just aren't there, that shouldn't (in principle) be hard to add.

  • p4 resolve won't show the difference between theirs and merged. A motivating example is where you merge from a release branch (theirs) that has changed more, and more recently, than the merge target (yours). In this case I'm more familiar with the branch changes and so would like to see what else I'm getting (i.e. from the branch I'm merging into) in the eventual submit. (Perforce have an enhancement request open for this one.)
  • There is no command to report the current status of your working tree (like cvs -n up, bzr status etc). When writing VCS I had to write my own. p4 opened is part way there in that it will tell you what have open, but the output format is rather verbose; it lacks the equivalent of .cvsignore; and it doesn't tell you if any files need resolving.
  • p4 diff (etc.) won't do the equivalent of diff -N (even if you set P4DIFF!). This makes the patches they generate incomplete if there are any added, branched or removed files, which is inconvenient for review and means that they're not suitable for use with the patch program.

Interface Inconveniences

Nuisances in the user interface. Again, I don't think these would be especially difficult to change.

  • Perforce forms (e.g. for p4 submit) treat visually identical whitespace as distinct. So if you've configured your editor not to insert raw tab characters (because your coding standard says you shouldn't use them, for instance, which is quite sensible given the trouble they cause) then your change description will appear to be correctly formatted when you submit it but be wrongly indented when you look at it in p4 changes or whatever.
  • p4 submit can only take one filename pattern. i.e. “p4 submit one.c” is OK but “p4 submit one.c two.c” is not; you have to manually add files to a change in separate steps before submitting it, or construct a change listing all the desired files manually.
  • If a change cannot be submitted you have to modify it and resubmit it; you can't delete it and start again, which otherwise might well be more convenient. The restriction seems to be an entirely bureaucratic one, too: you can remove all the files from it and then delete it. (For non-p4 users, the “change” here means the description and metadata, which in p4 have an independent life of their own; not your edits.)
  • Output tends to hide important information among unimportant. For example if a p4 sync updates 100 files and only one of them requires resolving, you're likely to miss it. Summarizing the files that need resolving at the end of the list of updates files would improve matters.

Model Problems

Flaws that result from some aspect of the system's design. These might well be difficult to change. (Which doesn't make them invalid; if the underlying design of a system doesn't support useful features, then perhaps that design is itself wrong.)

  • There's no whole-module graphical branch history view (like gitk or bzr visualise). p4v will show you a per-file branch diagram but nothing better than that.
  • p4 describe and p4 diff2 don't honor P4DIFF (because they do the diffing on the server), so if you have a better diff tool than p4's built-in one (which I do) then you don't get the benefit of it.
  • Execute bits are not properly versioned. You can't just edit a file and chmod it, you have to use a special command to change the execute bit. That's just inconvenient, but worse is that integration (merging) doesn't copy the change, so you have to change it on every branch separately. (Updated in the light of comments: apparently there's an option to do this, but, bafflingly, it's off by default.)
  • If the server is running slow or is down, all operations that are in any way related to version control are affected. Since there is no client-side state or caching other than file contents, this includes non-mutating operations (diff, history, etc; even testing whether a file is in version control).
  • P4 doesn’t merge renames correctly. Instead when you merge a rename operation, it deletes the rename source in the destination branch and copies the source branch’s version of the renamed file(s). You have to manually re-do the rename every time you merge across it - expensive if you are in a branch-heavy environment.

(Yes, some of these problems exist to some extent in some other version control systems too. That doesn't mean they're not annoying...)

Things that aren't annoying

  • The need to p4 edit isn't a big problem in practice (even though it sounds like a nuisance if you're not used to it), given adequate editor integration.
  • It doesn't crash. As a rule the problems seem to be design flaws (such as those above) rather than implementation bugs.
  • It's usually fast.

Stupid GCC

Apr. 27th, 2009 02:49 pm
ewx: (geek)
$ cat t.c
#include <stdio.h>
int main(void) { return printf(""); }
$ gcc -Wall -c t.c
t.c: In function ‘main’:
t.c:2: warning: zero-length printf format string
$ gcc -Wall -Wno-format-zero-length -c t.c
$ gcc --version
gcc (Debian 4.3.2-1.1) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Can anyone offer a plausible reason why:

  • -Wformat-zero-length is on by default (i.e. implied by -Wformat and thus by -Wall)?
  • Why it exists at all?

FTAOD, empty format strings are perfectly legitimate (and the GCC Manual knows this).

ewx: (geek)

There are a couple of scripts I've written to help me with development of DisOrder (and of other things).

polybuild

polybuild can build multiple programs on multiple computers; it produces a HTML “scoreboard” showing the results. I've been using it for a while from time to time to ensure that changes made in one place haven't broken something elsewhere. Here's an example while a build is underway:

For each platform, the left column is for the build (./configure and make) and the right column for tests (make check). Grey means hasn't started, yellow means underway, green means success and red means failure. As you can see, VCS is having some trouble on some of the platforms. The various symbols (other than “?”) link to logfiles containing the relevant build output. Here's the final state:

(heceptor, my FreeBSD machine, doesn't show up because it's turned off. Since I know this perfectly well its invisibility doesn't matter to me, but obviously this would be a problem for some users.)

stabilize

stabilize is rather more recent. I use it to maintain a disorder.stable branch that tracks disorder.dev; changes are only pushed from the latter to the former when the branch can pass make check. It also emails me if anything has gone wrong, so if I didn't bother to run the tests myself (they take quite a while) then I still find out within the hour that I made a mistake.

stabilize has no associated pretty pictures l-)

Both are quite optimized for my particular setup, but it should be at least possible to use them more widely. Also both only support Bazaar but they could be adapted to other version control systems.

Both can be acquired by:
bzr clone http://www.greenend.org.uk/rjk/bzr/rjk-buildtools.dev

VCS 0.5

Apr. 16th, 2009 08:44 pm
ewx: (geek)
Blurb, click if you've not seen it already )

Changes in VCS 0.5:

  • New environment variables VCS_PAGER and VCS_DIFF_PAGER allow you to feed log and diff output through colorizers and into pagers automatically.
  • Perforce support is now more self-consistent. In particular vcs diff and vcs commit now have a default of ..., applying them to just the current directory and its children rather than the whole workspace.
  • vcs status now produces much more useful output for Perforce, and honors .vcsignore files.

Get source code and/or .deb files from http://www.greenend.org.uk/rjk/2009/vcs.html.

VCS 0.4

Mar. 30th, 2009 09:29 pm
ewx: (geek)
I've added Mercurial, Darcs and Perforce support, and annotate (blame) and clone commands. Now depends on cURL. Read more at, or download from, http://www.greenend.org.uk/rjk/2009/vcs.html.

VCS 0.3

Mar. 28th, 2009 01:44 pm
ewx: (geek)
I've released VCS 0.3. This release adds Git support.
ewx: (geek)

From news.livejournal.com:

The recent break-ins resulted from hijackers finding and accessing lapsed Hotmail accounts that were used with LiveJournal accounts and publicly displayed on Profile pages in the past. You should be aware that Hotmail recycles email addresses that haven't been used in more than a year. If you validated a Hotmail address for your journal and displayed it publicly in the past, but then let the address lapse, someone who finds and re-registers that address can use it to obtain control of the journal.

This problem is unique neither to Livejournal (anything that has a password reminder and allows usernames to somehow be connected to email addresses will be vulnerable) nor to Hotmail (domain names can change owner). Connecting addresses to logins doesn't have to be 100% reliable for the exercise to be worthwhile to an attacker, and for a high-profile target they might well be prepared to spend a bit of time researching them.

Livejournal suggest that users make sure they only use addresses that they retain control over - in other words, user education, something with a poor track record.

Some possible measures that don't rely on the user's initiative:

  • Refuse to send password reminders to any email address that you've ever published. If addresses and logins can be connected some other way then this is no help, but it should at least reduce the size of the problem a bit.
  • Periodically verify that addresses recorded for password reminders are valid, for instance by sending them a confirmation link that must be clicked for the reminder address to remain usable. Unfortunately if the address has expired and already been re-used, this doesn't do any good - the attacker can follow the link. You could go further and require the password to be entered for the confirmation to complete - but training users to enter passwords in response to emails received out of the blue is a terrible idea!
  • Expire reminder addresses; users would have to (log in and) re-enable them and then re-confirm them (thus resetting the expiry on the email address too, conveniently). This is the most effort for the users, but probably also the most reliable. In practice you'd send a warning email a bit before expiry so that there need never be an interval where you couldn't get a password reminder.

VCS

Jan. 22nd, 2009 06:08 pm
ewx: (geek)

(Or, what I did on my day off.)

Over the last few years there've been a lot of new version control systems and where previously you could pretty much rely on most free (and many proprietary) projects using CVS, now they could use any of CVS, Subversion, Git, Bazaar, Mercurial, darcs, Arch or other less well-known (or less cheap) systems.

While the newer systems have many great features, and while there are advantages to diversity, one of the downsides is that your “muscle memory” is constantly betrayed by it. If you've got used to typing bzr add then it's easy to mistakenly keep to that even when using some project that still uses CVS (for instance).

My idea to address this is a new command called vcs which has a uniform command interface and figures out what version control system you're currently using and issues the appropriate native commands for it.

VCS is my implementation of this idea. Instead of remembering which of cvs add, svn add, bzr add or whatever you need to type, you can just enter vcs add and let the computer work out the right command for you.

Version 0.1 is very limited and best understood as a base for development rather than a finished product. It only knows about CVS, Subversion and Bazaar (which is plainly not enough), and it's missing some important commands such as update and status.

Update: I just put up version 0.2, which adds a few more commands.

ewx: (geek)

One of the things I needed for the user management window below was to convert from single bit in a bitmap to its bit number. (Rights are represented internally as a bitmap, but you want the bit number to index the array of GtkCheckButton widgets that represented them.)

An unportable answer and a portable one )

(comments locked due to excess spam which for some reason targets this article in particular.)

ewx: (geek)

GNU Emacs 22.2 has added support for bzr (and others) to its version control module. Being able to get diffs, logs and annotations for the current file in the editor rather than using a separate shell is quite a win, and is what I'm used to in contexts where I still use CVS, so I'm pleased with this up to a point.

But...

Committing using the usual VC key binding only commits the current file. That's just about acceptable for underlying tools like CVS where there's no concept of a changeset, but it's completely useless for any modern version control system.

I see from the help for C-x v v that:

If you call this from within a VC dired buffer, and one or more files are marked, it will accept a log message and then operate on each one. The log message will be used as a comment for any register or checkin operations, but ignored when doing checkouts. Attempted lock steals will raise an error.

So might this be the workaround? To get a VC dired buffer you type C-x v d. Unfortunately the actual effect of this is at least several minutes of apparently fruitless disk activity (even when only three or four files have changed). Obviously even if this does ever terminate (I got bored waiting) it's not something you're going to do every commit.

(Yes, I've read the manual and looked for any variables to configure, not that either of these would be particularly sensible default behaviour. No luck.)

RMS recently wrote that:

The GNU Project is not just a collection of software packages. Its intended result is a coherent operating system. It is particularly important therefore that GNU packages should work well with other GNU packages. For instance, we would like Emacs to work well with git or mercurial, but we especially want it to work well with Bzr.

Unfortunately it seems it's not really there yet l-(

ewx: (geek)

A discussion elsewhere raised the question of null pointers and varargs functions. The issue is essentially that NULL on its own is not guaranteed to a be a null pointer, and varargs functions are one of the contexts where this may actually matter. (The comp.lang.c FAQ has a whole section on this area.)

In particular a platform with 32-bit ints and 64-bit pointers that defined NULL to 0 would be expected to pass a value of the wrong size when just NULL was used where a pointer was expected by a varargs function.

I looked at a number of platforms to see how they defined NULL and what the outcome was.

Platform Definition of NULL
Solaris 0 on 32-bit, 0L on 64-bit
AIX 0
Linux ((void *)0)
HPUX 0L
Windows ((void *)0)
Mac OS X ((void *)0)

In all cases my test program (which passed a bare NULL for printf()'s %p conversion specifier) worked fine.

For the Windows/Linux/Mac definition of ((void *)0) this is completely unsurprising.

For HPUX, long is always the same width as a pointer. The same is true on Solaris but they went for distinct definitions for 32- and 64-bit anyway, probably to remain absolutely identical to historical definitions for 32-bit builds.

AIX is the slightly surprising one. Superficially in a 64-bit build you're passing a 32-bit value where a 64-bit value is required. In practice it turns out that it always gets away with it: the code generated to store even a 32-bit 0 is:

        addi    r30,r0,0
        std     r30,184(SP)

i.e. it always stores a 64-bit 0 even if you only ask for 32 bits (std is “store double-word”, a word being 32 bits in this context.)

ewx: (geek)

...I had a nightmare about GNU Arch.

And it didn't even involve the insane naming schemes.

ewx: (geek)

Many languages that have references (pointers, whatever) have a distinguished null value that refers to "nowhere": None, a null pointer, undef etc. Dereferencing this value produces some kind of runtime error (a segmentation fault or an exception, for instance) so you have check every possible use of any reference that can ever be null. (In some cases it's acceptable to take the exception or even the crash, but often it not)

What I'd like is a distinction between optional and mandatory references )
ewx: (Default)
XXXXX.c(118) : warning C4996: 'fopen' was declared deprecated
        c:\program files\microsoft visual studio 8\VC\include\stdio.h(234) : see
declaration of 'fopen'
        Message: 'This function or variable may be unsafe. Consider using fopen_
s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help
 for details.'
ewx: (geek)

I now have:

  • A Mingw install on one of my Linux boxes
  • A win32 .a of PCRE, which is one of the dependencies of my backup program
  • Eliminated the gcrypt dependency by dropping the SHA-1 implementation from the RFC in
  • Installed the free VC++ on my Windows box

Installing the PSDK's a bit steam-driven, isn't it? (I'm not sure whether I actually need it or not but I decided to just install everything.)

So all I have to do now is provide windows-friendly alternatives to all the POSIX-specific bits.

ewx: (Default)

I have a C++ program which works under Linux and MacOS (and will probably port nicely to other UNIXes). I also have a Windows XP system, which I want to run it on.

What's the most convenient way to get a C++-friendly build environment on Windows, preferrably without paying anything and preferrably without incurring a (runtime) dependency on Cygwin? I don't need (or particularly want) an IDE.

(The program in question being my backup software. Linux's NTFS implementation does not cut the mustard.)

May 2017

S M T W T F S
  123456
78910111213
14151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Expand Cut Tags

No cut tags