Re: [gforth] Multiple problems with latest Gforth-CVS

[Bernd Paysan]

Am Donnerstag, 29. November 2012, 03:02:22 schrieb David Kuehling:
> >>>>> "Bernd" == Bernd Paysan <address@hidden> writes:
> > The point is - if Gforth is a library, the main program maybe doesn't
> > want to quit when someone says "bye" in the Forth interpreter.
> 
> [..]
> 
> Then what about just vectoring bye in the C-code?  This way we could
> keep the old implementation by default.

Actually, I haven't changed anything in (bye), it always was a return from the 
engine.  I only changed the way the engine is called, and that boot calls now 
(bye).  I've now changed that to -56 (QUIT throwcode), and also return the 
other throw-codes if the startup code fails for some reason.

> Given the abilities of the average Forther, I think we should at least
> consider SVN.  How many forks of Gforth are there ever going to exist?

After I started using git, I've created 6 forks of Gforth just here on one 
computer.  That's simply six different target platforms I maintain or make 
experiments with (clang is not a recommended compiler for Gforth).  Maybe 
instead of using Git, we could change the makefiles to support multi-platform 
builds (the NaCl patches for Gforth are supposed to contain that).

> I could list more mistakes, and I haven't even used Git much yet.
> 
>   * Having no proper thought-through design *at* *all* at the the user
>   interface level.

I was just giving a few examples ;-)

>   * Possible data loss at some undefined time when the Garbage collector
>   runs after branches/tags have been removed/rebased (a Garbage
>   Collector that's waiting to eat my code?  WTF?).

Well, a branch/tag removal or a rebase is a lossy operation.  The accounting 
view of a VCS is that you should append only, but many people don't want to 
expose all their intermediate checkins to the public and therefore have 
demanded a rebase command - which just creates another branch, applies the 
delta between start and end of the rebased sequence in one go, and then 
removes the original branch.

This removal then does not immediately affect the data base, because the data 
base actually is append-only ;-).

>   * Being completely glued together by perl scripts.  Did you have a
>   look at what stuff TortoiseGit has to install on Windows to make a
>   working Git client?  AFAIK there's a full cygwin installed beneath it.
>   This is why GitHub re-implemented a (proprietary/closed) Git for their
>   servers.

As long as we need a full cygwin install (including TeX) to develop Gforth on 
Windows anyways, this is not really a show-stopper ;-).

>   * Lots of features missing when compared to SVN: no proper
>   svn:externals (submodules ar a joke), no cherry-picking merges, no
>   subtree merges, no per-file properties.

git cherry-pick?

Subversion is deeply directory-based.  And I had my fair share of problems 
with it.  IMHO it's a good thing we skipped it for Gforth ;-).

> Not that I'd object to Git.  Anything is better than CVS.

I had two cases of people using Git to develop Gforth, either from the 
unofficial Git mirror, or from a Gforth copy they checked into their own Git 
repository.  It is popular, probably because it has about the same amount of 
quirks as the average programmer (the more quirky thing wins ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

signature.asc
Description: This is a digitally signed message part.