[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gforth] Multiple problems with latest Gforth-CVS
From: |
Bernd Paysan |
Subject: |
Re: [gforth] Multiple problems with latest Gforth-CVS |
Date: |
Wed, 28 Nov 2012 22:50:55 +0100 |
User-agent: |
KMail/4.8.5 (Linux/3.4.11-2.16-desktop; KDE/4.8.5; x86_64; ; ) |
Am Mittwoch, 28. November 2012, 14:20:50 schrieb David Kuehling:
> > That's because I've prepared Gforth to integrate as library - and it
> > now returns via (bye) after startup. Question: What kind of return
> > magic should we use? Maybe something > 255, because 0..255 are values
> > useful for exit.
>
> Don't understand exactly what you do, but maybe we should add another
> word for returning with an exit code. (bye) isn't even mentioned
> anywehere in the Gforth documentation, I just found it via grep'ing the
> sources. On the other hand, people already may be using (bye), so
> changing semantics may be a bad idea.
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. I.e. it needs a way to
intercept it. And changing (bye) to return is the easiest way to do so.
Maybe we should rename it into c-return or something like that. Its return
value is an error code or 0 on success. Maybe we can keep (bye) as exit(n)
function for backwards compatibility, and change BYE to 0 C-RETURN.
However, for the startup code, that doesn't work too well. If the startup
code wants to terminate, like -e "foo bar bye", we return 0 as "success".
This has to be different from no bye in the startup code, which means "fall
through to QUIT".
I should probably better return -56 (throw-code of QUIT) at the end of the
startup code.
> Gforth as a library... that'll be a nice feature.
> [..]
>
> > I'm now mostly working on my new header experiment branch, whihc is a
> > git repository here:
> >
> > git clone http://bernd-paysan.de/gforth
> >
> > I keep merging in changes from CVS, though, and once the experimental
> > header stuff is ok with Anton, I'll either check that back into CVS,
> > or we move to git officially.
>
> I think it's about time to drop CVS. It really gets in the way when
> working on Gforth sources. I'm not a big fan of Git, too complex, too
> many ways to do the same thing (and even more ways to do it slightly
> wrong). But already much better than CVS.
We've probably tried all DVCSes - Gerald uses Mercurial for SWIG, I used
Bazaar for some time and now use Fossil for net2o and the VDs, but as Git is
the top dog, it is probably the most appropriate.
Git has some typical Linus mistakes, like no reasonable defaults - when you
create a public git repository to push into, it *does* create a reasonable
default on-checkin action script, but it does not activate it (which is
completely stupid). The other completely stupid thing is that it requires a
switch on commit for "commit everything". If I say "commit" without argument,
I mean "commit everything", not "commit nothing", as git interprets it.
> Does it keep the full history?
Yes, of course.
> What about moving the Git repo to savannah?
Should be considered.
--
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.