From Newsgroup: comp.lang.forth

My current project has 13,938 lines of code (and documentation).
That is too large to keep every detail of it in my head.

The reason to not factor it in a number of smaller files is that
there are many (unavoidable) global variables and data blobs.
These global variables prevent me from dividing the application
up into smaller programs that can run standalone. They also
prevent me from documenting sub-tools, and giving such tools
their own help words [ The main application now has lots of help
text that is not relevant for a user interested in working with
only one of the specific tools. ]

With respect to the coding and debugging aspect, there are
currently many "folding" and "workspace" based editors available
(my editor of choice can't do "folding" yet). Is there experience
with using such features advantageously for Forth?

I am thinking of introducing *.finc (forth include) files
alongside the existing *.frt ones. One of them will hold
all (?) the variables needed by all (?) of the subtools.
This will waste data space in some cases. A *.finc file is
loaded at an arbitrary spot inside the calling subtool(s).

I remember that long ago people were developing project management
tool in Win32forth ('Scintilla?') Did this go anywhere? Win32forth
seems to be as dead as a doornail and I am not even sure where to
get a decent source distribution of its tools?

It is also possible to write a plugin for Visual Studio (or maybe
an exiting one is good enough for Forth). It will be vast overkill
and some may frown on the MS dependency. Are there equivalent open
source projects that I should consider?

-marcel
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

These are several aspects:
1) code size exceeded to keep everything in mind
2) still a one-man project or collaboration?
3) code (re)organization not yet started (risk of introducing new bugs!)
4) IDE or more powerful editor not yet selected

My 5 cents:
A) change your tools and invest a lot of time in learning new work flows
(would it pay off?)
B) 13k code lines is large but still manageable
C) unless you expect big changes in future, don't reorganize
D) there are many intelligent editors (e.g. UltraEdit good but not free,
Notepad++ free but minimal and can do some code folding / line hiding,
VS Code is a fat hog etc) but choice depends also on your OS.

This reminds of a young business student we once had in our team and who
coded using MS Word. He was first laughed at but it went surprisingly well because he used Word's document structuring functions for collapsing
code blocks.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

mhx@iae.nl (mhx) writes:

With respect to the coding and debugging aspect, there are
currently many "folding" and "workspace" based editors available
(my editor of choice can't do "folding" yet). Is there experience
with using such features advantageously for Forth?

I have seen some of my students use folding for Forth code in VS Code.
I found it annoying to have to ask the students to unfold the folded
parts, but that may just be the presentation situation. Emacs (my
favourite editor) supports folding, but I have not used it. I don't
miss it, but I did not miss the Forth-GUI stuff (LOCATE etc.) before
we had it and I used it, so maybe I would find it useful after using
it for a while.

I am thinking of introducing *.finc (forth include) files
alongside the existing *.frt ones.

Standard Forth has INCLUDED, INCLUDE, REQUIRED and REQUIRE intended to
include Forth source code. What's the difference between .finc and
.frt (or .4th)?

Do I understand correctly that you have not used INCLUDED etc. inside
Forth source files?

It is also possible to write a plugin for Visual Studio (or maybe
an exiting one is good enough for Forth). It will be vast overkill
and some may frown on the MS dependency. Are there equivalent open
source projects that I should consider?

Visual Studio Code is open source; Wikipedia says that its developer
is Microsoft, so some may frown. There are lots of other source code
editors, many of them free software (aka open source); whether you
consider them to be equivalent depends on your requirements. As
mentioned, I use Emacs (free), some students use vi/vim; there is also
Eclipse, which used to have quite a bit of mindshare a while ago, but
even at the time I have not seen it used by students, while Code seems
quite popular, even among Linux users. IntelliJ IDEA (used in our
introductory programming course) has a community edition that is open
source, but it has no specific Forth support, and I don't know how
much it would take to add that.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 23-03-2024 10:30, mhx wrote:

My current project has 13,938 lines of code (and documentation).
That is too large to keep every detail of it in my head.

The reason to not factor it in a number of smaller files is that
there are many (unavoidable) global variables and data blobs. These
global variables prevent me from dividing the application
up into smaller programs that can run standalone. They also prevent me
from documenting sub-tools, and giving such tools their own help words [
The main application now has lots of help
text that is not relevant for a user interested in working with
only one of the specific tools. ]

With respect to the coding and debugging aspect, there are
currently many "folding" and "workspace" based editors available
(my editor of choice can't do "folding" yet). Is there experience
with using such features advantageously for Forth?

I can't feel with you, since my largest programs are 2 KLOC. Still, I
have no problem managing them.

Although I don't particularly like OOP, in this case such an approach
might be the way. Arrange your program along certain modules and only
take up the interaction between these modules in your main program - or arrange them in a way you can separate those dependencies.

I know this might be hard to establish afterward.. But it helped me in
the past. When I added strings to uBasic/4tH I designed that entire
module in separation (all variables included) so it was just a "drop in" module. I could still lift it out without any problems, I guess.

But 13,938 lines - that's a hellovalot of code..

Hans Bezemer

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 3/23/24 04:30, mhx wrote:

My current project has 13,938 lines of code (and documentation).
That is too large to keep every detail of it in my head.

The reason to not factor it in a number of smaller files is that
there are many (unavoidable) global variables and data blobs. These
global variables prevent me from dividing the application
up into smaller programs that can run standalone. They also prevent me
from documenting sub-tools, and giving such tools their own help words ...

Without seeing the code, I probably can't say much about how to separate
it into multiple files, each a logical unit.

Global data by itself shouldn't prevent you from separating the code
into multiple files. The files have external data dependency which can
be documented at the top of the code.

I've used the modular programming[1] approach successfully to write and maintain Forth applications which are composed of thousands of lines of
Forth source, but each module is logically separate, and, in a few
instances, relies on externally declared global data.

--
Krishna

Ref.
1. https://github.com/mynenik/kForth-Win32/blob/master/doc/modular-forth.pdf





--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

Anton Ertl wrote:

I have seen some of my students use folding for Forth code in VS Code.
I found it annoying to have to ask the students to unfold the folded
parts, but that may just be the presentation situation. Emacs (my
favourite editor) supports folding, but I have not used it. I don't
miss it, but I did not miss the Forth-GUI stuff (LOCATE etc.) before
we had it and I used it, so maybe I would find it useful after using
it for a while.

That's a good point. I didn't miss lower-case at first until somebody
pointed it out to me...

I am thinking of introducing *.finc (forth include) files
alongside the existing *.frt ones.

Standard Forth has INCLUDED, INCLUDE, REQUIRED and REQUIRE intended to include Forth source code. What's the difference between .finc and
..frt (or .4th)?

Do I understand correctly that you have not used INCLUDED etc. inside
Forth source files?

Of course I use INCLUDE. I'd better have said *.h like files. I use a
very simple version in my meta and target compilers and am curious
if others find merit in more elaborate versions or features. I've
never used shared data between separate (but related) applications.
The problem with shared data is that not every application should have permission to change just everything (a recent insight).

It is also possible to write a plugin for Visual Studio (or maybe
an exiting one is good enough for Forth). It will be vast overkill
and some may frown on the MS dependency. Are there equivalent open
source projects that I should consider?

Visual Studio Code is open source; Wikipedia says that its developer
is Microsoft, so some may frown.

Good points!

As mentioned, I use Emacs (free), some students use vi/vim;

Maybe I should have a look at Emacs + WSL2.

Thanks!
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 3/23/24 11:29, Krishna Myneni wrote:

On 3/23/24 04:30, mhx wrote:

My current project has 13,938 lines of code (and documentation).
That is too large to keep every detail of it in my head.

...

I've used the modular programming[1] approach successfully to write and maintain Forth applications which are composed of thousands of lines of Forth source, but each module is logically separate, and, in a few instances, relies on externally declared global data.

--
Krishna

Ref.
1.
https://github.com/mynenik/kForth-Win32/blob/master/doc/modular-forth.pdf

Out of curiosity, I measured one of the Forth applications which I
developed and use. It contains a total of 8301 lines, including
comments, somewhat less than your ~14,000 lines, but still respectable
in size. The number of code lines is slightly variable depending on
whether it runs on 32-bit or 64-bit Linux, or on Win32, but the
variation won't be more than about 10%.

The code is organized in 27 Forth files, with many of them being modular libraries. Some of them are typical Forth string library, i/o library
for data files in a specific format, the Forth assembler, four Forth Scientific Library modules, external library interface (in Forth + Forth assembler/machine code), a Forth ODE solver and a quad-precision
spherical Bessel function module for use with MPFR, IEEE 754-specific
Forth words, and numerical physics code.

The file and line counts do not include external dynamic libraries which
may be called from the code.

--
KM

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 23/03/2024 8:30 pm, mhx wrote:

My current project has 13,938 lines of code (and documentation).
That is too large to keep every detail of it in my head.

The reason to not factor it in a number of smaller files is that
there are many (unavoidable) global variables and data blobs. These global variables prevent me from dividing the application
up into smaller programs that can run standalone. They also prevent me from documenting sub-tools, and giving such tools their own help words [ The main application now has lots of help
text that is not relevant for a user interested in working with
only one of the specific tools. ]

I recall Elizabeth saying that (circumstances allowing) Chuck would write
as many as three versions of an application, each successively better.
So when are you going to start Version 2?


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

dxf wrote:

On 23/03/2024 8:30 pm, mhx wrote:

My current project has 13,938 lines of code (and documentation).
That is too large to keep every detail of it in my head.

The reason to not factor it in a number of smaller files is that
there are many (unavoidable) global variables and data blobs. These global variables prevent me from dividing the application
up into smaller programs that can run standalone. They also prevent me from documenting sub-tools, and giving such tools their own help words [ The main application now has lots of help
text that is not relevant for a user interested in working with
only one of the specific tools. ]

I recall Elizabeth saying that (circumstances allowing) Chuck would write
as many as three versions of an application, each successively better.
So when are you going to start Version 2?

When version 1 is at least feature complete. A third version would have to wait
for many other projects.

-marcel
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 23 Mar 2024 at 10:30:31 CET, "mhx" <mhx> wrote:

My current project has 13,938 lines of code (and documentation).
That is too large to keep every detail of it in my head.

This all in my humble opinion, but I have been around for a while.
I have been involved in Forth projects of up to 30 programmers
from several companies in several countries. For my sins, I
have even been the project manager for a project involving
five organisations in four countries.

It's a management problem. If you are the only programmer, then
the problems are mainly to do with your approach to management.

There are two primary factors, project lifetime and project size.
Both are intimately intertwined with the project documentation.
If you do not document the design and the code, you are building
problems for the future.

The MPE cross compiler has evolved over 40+ years. Most
compilers compile between 30k and 45k source lines of code
(SLOC) to produce a compiler. The 30k figure is for AMD64
and includes assembler, code generator and dissassembler..
The 45k figure is for ARM32 including both ARM32 and
Thumb2 instruction sets. Design documentation is skimpy
and I have wanted to rewrite the compiler chassis for over
a decade. This may be one of my retirement projects.

A client application has evolved over a similar period to the
cross compiler and now exceeds 1M SLOC. It is managed,
maintained and developed by a small team managed by
a very determined person, from whom I have learned a
great deal.

The key document to orient your thinking about larger
projects is from Joel Spolsky:

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/
If you have not read it, do it now.

The reason to not factor it in a number of smaller files is that
there are many (unavoidable) global variables and data blobs.
These global variables prevent me from dividing the application
up into smaller programs that can run standalone. They also
prevent me from documenting sub-tools, and giving such tools
their own help words [ The main application now has lots of help
text that is not relevant for a user interested in working with
only one of the specific tools. ]

If you have decided that the code cannot be documented
then it's time to throw one away.

With respect to the coding and debugging aspect, there are
currently many "folding" and "workspace" based editors available
(my editor of choice can't do "folding" yet). Is there experience
with using such features advantageously for Forth?

Choosing an editor is somewhat like choosing a religion.
After a few years the editor is part of muscle memory.
I have always let programmers choose their own
editors, subject to a few simple rules such as setting
hard tabs to 8.

Spolsky says to use the best tools. Hence, you have
to be prepared to pay for tools.

All our bugs are in our source code. Debugging is
an application of Formal Scientific Method, and I
have written about it several times, e.g.

https://jacobfilipp.com/DrDobbs/2008webarticles/printa982.html

The article is entitled modern Forth (from 2008) and I quote
from it
"
Debugging consists of two nested loops. How fast you can
go around the inner loop determines how fast you can
debug a system. Interactive debugging is the fastest route
I have found. The stages of debugging are:

1) Make the problem repeatable. This usually involves
finding out which inputs cause the problem.
2) Gather data about the problem. Observation is crucial,
so take this stage slowly and carefully. I have seen people
immediately dismiss exception displays and crash-dumps
which contain vital clues.
3) From the data, form a hypothesis as to what caused the problem.
4) Design an experiment which tests the hypothesis. The
important part in designing the experiment is to ensure
that it gives a yes/no answer.
5) Run the experiment. If the hypothesis is incorrect, go
back to stage 2.
6) Fix the problem.
7) If you have more bugs to fix, go back to stage 1 for the next problem.

Programmers are very rarely taught how to debug. The
problems they face are almost always in their source code.
So why don't they read it more carefully? In particular, why
don't they write a line or two describing the whats and whys
of of a routine before they write the code? The poor relation
who maintains your code for the next 10 years costs your
employer a fortune because you could not be bothered.
As a sidenote to this potential rant, my company has been
using literate programming for 10 years and we believe
that it has increased the quality of our code. Whenever
we incorporate third-pary code into our code bases we
document it to our house standards. This process nearly
always reveals bugs. To produce stable software the golden
rule is to fix the bugs first. A second rule is not to write clever
code. Although this upsets people trying to achieve alpha-male
guru status, you should remember the aphorism attibuted to
Brian Kernighan:

Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible,
you are, by definition, not smart enough to debug it.

Forth is a wonderful tool for debugging systems and their software. Since we spend most of our time debugging and testing, it astounds me how our industry accepts mediocre tools for critical activities. "

I am thinking of introducing *.finc (forth include) files
alongside the existing *.frt ones. One of them will hold
all (?) the variables needed by all (?) of the subtools.
This will waste data space in some cases. A *.finc file is
loaded at an arbitrary spot inside the calling subtool(s).

Sounds like a very second order issue.

I remember that long ago people were developing project management
tool in Win32forth ('Scintilla?') Did this go anywhere? Win32forth
seems to be as dead as a doornail and I am not even sure where to
get a decent source distribution of its tools?

It is also possible to write a plugin for Visual Studio (or maybe
an exiting one is good enough for Forth). It will be vast overkill
and some may frown on the MS dependency. Are there equivalent open
source projects that I should consider?

I know of one Forth company that is rewriting its development
IDE in Visual Studio because it's known by the "children" and
is therefore cheaper in the long term.

Sorry, that turned into something of a diatribe, but the importance
of project management and debugging is one of my buttons.

Stephen
--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com
MPE website
http://www.vfxforth.com/downloads/VfxCommunity/
downloads
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <nnd$2c4d4890$00491f77@4cefa5103c6642bc>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 23-03-2024 10:30, mhx wrote:

My current project has 13,938 lines of code (and documentation).
That is too large to keep every detail of it in my head.

The reason to not factor it in a number of smaller files is that
there are many (unavoidable) global variables and data blobs. These
global variables prevent me from dividing the application
up into smaller programs that can run standalone. They also prevent me
from documenting sub-tools, and giving such tools their own help words [
The main application now has lots of help
text that is not relevant for a user interested in working with
only one of the specific tools. ]

With respect to the coding and debugging aspect, there are
currently many "folding" and "workspace" based editors available
(my editor of choice can't do "folding" yet). Is there experience
with using such features advantageously for Forth?

I can't feel with you, since my largest programs are 2 KLOC. Still, I
have no problem managing them.

Although I don't particularly like OOP, in this case such an approach
might be the way. Arrange your program along certain modules and only
take up the interaction between these modules in your main program - or >arrange them in a way you can separate those dependencies.

I know this might be hard to establish afterward.. But it helped me in
the past. When I added strings to uBasic/4tH I designed that entire
module in separation (all variables included) so it was just a "drop in" >module. I could still lift it out without any problems, I guess.

But 13,938 lines - that's a hellovalot of code..

My largest project is tmanx the musical score program, that is driven
hardware for e.g. linux, raspberry pi, windows.
It is heavily dependant on OO. The classes are defined beforehand,
and the objects are defined were needed. I have succeeded in separating
the source for different concerns: instruments, circular buffer,
real time stuff, musical language. There are only two files larger
than say a 100 bytes. That is domanx that is repetitive and contains definitions for each pitch, articulation, note duration etc.
The other is score.frt that defines the musical language. It also is
pretty self contained, and runs 194 lines with comment.

The total lines is 2700. I could certainly expand this with features
without fear that the architecture collapses.
Actually I have done that for adding an organ instrument, and a software
(ms) midi interface and a hardware (expander) midi interface.
There are occasionally deferred words, that cannot be avoided. During
runtime you can change the instrument where on a part is to be played.
A part is a sequence of execution tokens that plays a bar/measure.
DEFER itself is never used.

I don't think that using global variables ever can handle a large
project. Global variables in manx contains configuration mainly.
The rest must be compartmentalized using OO.

(how many parts are allowed, how many bars in a part).
How many divisions for a quaver?
How many MS before an event is due you start a busy wait?
Musical pause before a piece start. (That moment the pianist stares
straight ahead to give you a last chance to cough.)

It is absolutely possible to make a SPICE clone in Forth without
loosing track.

Hans Bezemer

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <utn00k$3o406$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 3/23/24 04:30, mhx wrote:

My current project has 13,938 lines of code (and documentation).
That is too large to keep every detail of it in my head.

The reason to not factor it in a number of smaller files is that
there are many (unavoidable) global variables and data blobs. These
global variables prevent me from dividing the application
up into smaller programs that can run standalone. They also prevent me
from documenting sub-tools, and giving such tools their own help words ...

Without seeing the code, I probably can't say much about how to separate
it into multiple files, each a logical unit.

Global data by itself shouldn't prevent you from separating the code
into multiple files. The files have external data dependency which can
be documented at the top of the code.

I've used the modular programming[1] approach successfully to write and >maintain Forth applications which are composed of thousands of lines of
Forth source, but each module is logically separate, and, in a few
instances, relies on externally declared global data.

I guess that separates the men from the boys.

--
Krishna

Ref.
1. https://github.com/mynenik/kForth-Win32/blob/master/doc/modular-forth.pdf

--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <65ff8942$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 23/03/2024 8:30 pm, mhx wrote:

My current project has 13,938 lines of code (and documentation).
That is too large to keep every detail of it in my head.

The reason to not factor it in a number of smaller files is that
there are many (unavoidable) global variables and data blobs. These global variables prevent me from dividing the application
up into smaller programs that can run standalone. They also prevent me from documenting sub-tools, and giving such tools their own help words [ The main application now has lots of help
text that is not relevant for a user interested in working with
only one of the specific tools. ]

I recall Elizabeth saying that (circumstances allowing) Chuck would write
as many as three versions of an application, each successively better.
So when are you going to start Version 2?

That is methodology that fits Chuck Moore. I'm not proficient at writing
bug free code, and I cherish anything that has passed tests.

The other method is evolution. You were evolved from a single cell
organism, this evolution thing can be quite successful.
You can compare the first version of manx that originated from Marcel
Hendrix to tmanx now, or fig-Forth 8086 to ciforth.
Quantitative changes in the end lead to qualitative changes.

I agree with Chuck Moore, that you should relentlessly cut superfluous branches, only disagree that you have to start over.
A good source control system helps, psychologically. You don't have
to worry that you can't go back, although you never will.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <utp79v$c6qj$1@dont-email.me>,
Stephen Pelc <stephen@vfxforth.com> wrote:

On 23 Mar 2024 at 10:30:31 CET, "mhx" <mhx> wrote:

<SNIP>

1) Make the problem repeatable. This usually involves
finding out which inputs cause the problem.

(-; I worked in train software. Repeating train crashes is not
an option.

2) Gather data about the problem. Observation is crucial,
so take this stage slowly and carefully. I have seen people
immediately dismiss exception displays and crash-dumps
which contain vital clues.

This is vital is the problem occurs once in a blue moon.

<SNIP>

Programmers are very rarely taught how to debug. The
problems they face are almost always in their source code.
So why don't they read it more carefully? In particular, why
don't they write a line or two describing the whats and whys
of of a routine before they write the code? The poor relation
who maintains your code for the next 10 years costs your
employer a fortune because you could not be bothered.
As a sidenote to this potential rant, my company has been
using literate programming for 10 years and we believe
that it has increased the quality of our code. Whenever
we incorporate third-pary code into our code bases we
document it to our house standards. This process nearly
always reveals bugs. To produce stable software the golden
rule is to fix the bugs first.

Never expand buggy code.
Hugh insulted me as being a maintenance programmer. Being a
hired gun I was frequently involved in fixing defects of others,
mostly poorly documented.
The first thing to do write comment about what a procedure is
supposed to do. Then check the places where it is used against
that documentation, hopefully documenting that procedure.
Make a testset, and clean up a bit, using the testset.
Slowly you gain control of the software. Now look at the defect
again. It is gone!

<SNIP>

Sorry, that turned into something of a diatribe, but the importance
of project management and debugging is one of my buttons.

Worthwhile article, reflects my own experiences.

Stephen

--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 2024-03-23 13:30, mhx wrote:
[...]

With respect to the coding and debugging aspect, there are
currently many "folding" and "workspace" based editors available
(my editor of choice can't do "folding" yet). Is there experience
with using such features advantageously for Forth?

I use folding sometimes. Folding is more useful when the size of folded
blocks is large, and/or folded structures are hierarchical. For example,
when words are grouped into word lists (with clear markup in the source
code) and a whole word list is folded.

But also, I split the application code into many small files — on
average 70 lines per file, maximum 350 lines (statistics for 204 files
of the application). So I have less need of folding.

I am thinking of introducing *.finc (forth include) files alongside the existing *.frt ones. One of them will hold all (?) the variables needed
by all (?) of the subtools. This will waste data space in some cases. A *.finc file is loaded at an arbitrary spot inside the calling subtool(s).

In my view, a package system or reusable components infrastructure
should solve this problem.


--
Ruvim

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

mhx@iae.nl (mhx) writes:

My current project has 13,938 lines of code (and documentation).

I've never worked on a Forth program that large, but can make some non-Forth-specific remarks.

The reason to not factor it in a number of smaller files is that
there are many (unavoidable) global variables and data blobs.

This is an antipattern but some amount of it sometimes can't be helped.
Can you decrease the number of variables by grouping related ones into
structs or something similar? That decreases the amount of clutter even
though you now have to get at the individual struct members.

It can help to have each struct "owned" by some module so that the
contents of the struct aren't changed from random places in the code,
but rather, by calling some word in the module, that sanity checks the
change being made. And generally, include lots of asserts and other consistency checks in the program. If something goes wrong, you want to
find out as quickly as possible.

It's nice if you can have lots of automated tests as well, so you can
run the full suite every time you commit a change. You can write tests concurrently with writing the code, and that shapes the code design.
Adding tests afterwards is clumsier.

Look at the dejagnu test framework for high level tests. GCC uses it.

You could also spend some time looking at large C or assembly language
programs to get a sense of their organization, if large Forth programs
are harder to find.

There is a big document on how SQLite is tested. The tests are very
extensive: https://sqlite.org/testing.html

These global variables prevent me from dividing the application up
into smaller programs that can run standalone.

What does the program look like now, in number of modules, subsystems,
etc.? Why can't you document sub-tools separately even if the sub-tools themselves share a bunch of data? Could you move a lot of those
variables to something like a database?

With respect to the coding and debugging aspect, there are
currently many "folding" and "workspace" based editors available

I've never felt any benefit from these, but obviously some people like them.

I remember that long ago people were developing project management
tool in Win32forth ('Scintilla?')

Project management, what does that even mean? Everyone uses github
these days, even though it is in many ways terrible.

It is also possible to write a plugin for Visual Studio (or maybe
an exiting one is good enough for Forth). It will be vast overkill
and some may frown on the MS dependency.

I guess github is an MS dependency of a different sort.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 25/03/2024 9:07 am, Paul Rubin wrote:

mhx@iae.nl (mhx) writes:
...

I remember that long ago people were developing project management
tool in Win32forth ('Scintilla?')

Project management, what does that even mean? Everyone uses github
these days, even though it is in many ways terrible.

I'd never use github. It's 'reality show' for programmers :)

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <6600d18a$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 25/03/2024 9:07 am, Paul Rubin wrote:

mhx@iae.nl (mhx) writes:
...

I remember that long ago people were developing project management
tool in Win32forth ('Scintilla?')

Project management, what does that even mean? Everyone uses github
these days, even though it is in many ways terrible.

I'd never use github. It's 'reality show' for programmers :)

I abuse github.

Nowadays one expect to find a program on github.
I hate git, and I use github only to publish my programs, not using
git for development.
However github offers:
- a free way to publish with great visibility
- easy way to add releases that are ready to use
- easy way to add wiki documentation
- all source are visible as a tree, no need to unpack
- way for the public to report defects
- the scent of reliability

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -
--- Synchronet 3.20a-Linux NewsLink 1.114