[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
exit(n)
[..] 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.
cheers,
David
--
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
pgpKaiEMMd67P.pgp
Description: PGP signature