Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!news.stack.nl!.POSTED!not-for-mail
From: Willem <willem@turtle.stack.nl>
Newsgroups: comp.programming
Subject: Re: programmer's keyboard
Date: Thu, 3 Jan 2013 08:35:39 +0000 (UTC)
Organization: Stack Usenet News Service
Lines: 102
Message-ID: <slrnkeagmr.714.willem@turtle.stack.nl>
References: <150e1c64-726a-43cc-82f9-a52c81a2e8ce@googlegroups.com> <o0omd8184k13mdl5j9d2pn0eta2a112hik@4ax.com> <N5KCs.693987$nB6.448936@fx21.am4> <cdcqd8htmmdm7l81imb6c3mn8cl33jcbj0@4ax.com> <EphDs.952759$W63.92055@fx05.am4> <_sWdnYhcjvIJl0LNnZ2dnUVZ8sadnZ2d@bt.com> <kbnkla$k1b$1@news.albasani.net> <ak96fjFk2kiU4@mid.individual.net> <kbos5r$r64$1@news.albasani.net> <akab0vFltc3U1@mid.individual.net> <kbouh0$v0p$1@news.albasani.net> <kbq073$jv2$1@dont-email.me> <kbq4t1$988$1@news.albasani.net> <akbmv7Fltc3U3@mid.individual.net> <kbqiq3$3q7$1@news.albasani.net> <akc2s5Fltc3U4@mid.individual.net> <kbrl33$659$1@news.albasani.net> <kc18sk$1s6$1@dont-email.me> <kc25p6$ul9$1@news.albasani.net>
NNTP-Posting-Host: turtle.stack.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: mud.stack.nl 1357202139 63607 2001:610:1108:5010::132 (3 Jan 2013 08:35:39 GMT)
X-Complaints-To: abuse@stack.nl
NNTP-Posting-Date: Thu, 3 Jan 2013 08:35:39 +0000 (UTC)
User-Agent: slrn/0.9.9p1 (FreeBSD)
Xref: csiph.com comp.programming:2716

BGB wrote:
) the advantage of the GUI based option though is that usually a person 
) can click on things faster than they can type things.

On average, perhaps.  But looking at programmers or other power users, the
average is the other way around.  They can usually type things faster than
they can click on things.  Which is why every menu has a keyboard shortcut.

) this is mostly an issue of having longish paths to 'cd' through, making 
) getting to the desired directory take a little longer (meaning a higher 
) initial cost).

Longish paths can be tab-completed, if you have the right shell.
I'm way faster into a directory if I can just type it in with
tab-completion.

) this means that navigating to a directory, or moving between 
) directories, can be done faster and easier in Windows Explorer than in a 
) shell.

Me experience is otherwise.

) granted, a better option would be if Explorer had an "Open CMD Shell 
) Here" option. (or, even, the ability to, like in Linux, open a new shell 
) in the same directory as the prior shell...).

There are tools to add that option.  You can make one yourself with just a
bit of windows api knowledge.

) but, even then, there would be a secondary annoyance:
) MS configures their compiler via environment variables used in the batch 
) file used to open the shell (rather than, say, putting the compiler on 
) the default path and using an INI file or similar for config). granted, 
) OTOH, it does make MSVC a little easier to auto-configure tools against 
) than GCC (which would externally appear to use magic to know its 
) settings...).
)
) the issue here is that an "open shell here" would then not be nearly so 
) useful if the intent is to rebuild the project...

Then you add an 'open shell here' which uses that batch file.

) as-is, I currently have 3 branches of my VM's interpreter:
) the original / current live version;
) a version which I tried to rewrite to use untagged values, but ran into 
) problems I can't yet address (there are still holes in the type-system, 
) which is a killer for untagged values);
) another version, which I am in the process of migrating from the 
) original tagged pointers, to a new tagged-reference system (where the 
) references are always 64-bits), mostly as the prior effort ran into a 
) wall (64-bit tagged references allow unboxed int/float/double on 32-bit 
) targets, although sadly, not an unboxed 64-bit long).
)
)
) but, how am I managing these branches:
) well, via copies of the directory tree.
)
) if this new branch gets written and working, it may then be substituted 
) in, in place of the original.

You can do all that with a VCS as well.  And then you can merge both
directory trees together and get all the changes in one place.

)> Development branches are useful even in single-developer projects.  They let
)> you have multiple development branches which can be easily merged and
)> forked.  The best part of it is that versioned history can be kept between
)> merges.
)>
)
) yes, but this can also be done (more or less) via copies, and is "part 
) of the process".

Yes, but a version control system makes this easier for you.
You *can* do anything the hard way, that's not a reason to keep doing it
like that.

)> Not necessarily.  If you track changes to your project tree, and if by any
)> chance one of those changes happens to introduce a bug, a version control
)> system lets you pinpoint which change introduced the bug, and you can
)> quickly inspect what changes were made by diff'ing between any couple of
)> versions.  With a version control system, you can do all this without having
)> to checkout anything.
)>
)
) granted.
)
) rebuilding / retesting after nearly every change (at least to the "live" 
) version) can also help reduce bugs though (granted, yes, this may take 
) many minutes each time this is done).

With a VCS, you can set up a continuous integration system, which do this
in the background and send you an email if a build or automatic test fails.
(Or send you a message in an IM system, or cause a popup on your screen.)


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT