[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kuehling
Subject: Re: [gforth] Multiple problems with latest Gforth-CVS
Date: Fri, 30 Nov 2012 02:14:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

>>>>> "Bernd" == Bernd Paysan <address@hidden> writes:

> 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.  

Ah, that was the (to me) missing piece of information.

> 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.

Wherever you canged that, maybe you didn't change it in Gforth CVS (yet)?
Because after updating, I still have the same problems.

BTW does that mean (bye) is not going to be able to return all exit
codes?  That's somehow a nuisance, I currently cannot think of a
programming language that *doesn't* support arbitrary exit codes (apart
from, now obviously, Gforth).  Maybe the engine needs to return more
bits than just an int?  Or just add a primitive that does an explicit

[..] cut short, trying to not ignite a flamewar, but:

>> * 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?

'git cherry-pick' is the same kind of joke as 'git submodule'.  It badly
emulates a feature of SVN that cannot be represented using the Git data
model.  'git cherry-pick' is just a normal commit.  Later merges of the
originating branch won't see that the change has already been applied.
Although merge heuristics sometimes hide the conflict.

> 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
> ;-).

Then let's do it, just in time before the flamewar hits :) I wonder what
Anton thinks.


GnuPG public key:
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

Attachment: pgpKaiEMMd67P.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]