gforth
[Top][All Lists]
Advanced

[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/

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


reply via email to

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