Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #46216 > unrolled thread

File extensions and Gforth on Openhub

Back to article view | Back to comp.lang.forth

Contents

  File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-26 08:15 +0000
    Re: File extensions and Gforth on Openhub Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-27 00:53 +0000
      Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-27 07:32 +0000
        Re: File extensions and Gforth on Openhub Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-27 21:29 +0000
          Re: File extensions and Gforth on Openhub stephen@mpeforth.com (Stephen Pelc) - 2016-03-28 13:21 +0000
            relative file names and INCLUDED (was: File extensions ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-28 14:25 +0000
              Re: relative file names and INCLUDED (was: File extensions ...) stephen@mpeforth.com (Stephen Pelc) - 2016-03-28 15:35 +0000
                Re: relative file names and INCLUDED (was: File extensions ...) Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-28 19:58 +0000
                Re: relative file names and INCLUDED (was: File extensions ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 07:42 +0000
                  Re: relative file names and INCLUDED (was: File extensions ...) stephen@mpeforth.com (Stephen Pelc) - 2016-03-29 11:33 +0000
                    Re: relative file names and INCLUDED (was: File extensions ...) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-29 15:34 +0000
                      Re: relative file names and INCLUDED Doug Hoffman <glidedog@gmail.com> - 2016-03-29 12:31 -0400
                        Re: relative file names and INCLUDED Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 14:21 +0000
                          Re: relative file names and INCLUDED Doug Hoffman <glidedog@gmail.com> - 2016-03-30 10:35 -0400
                      Re: relative file names and INCLUDED (was: File extensions ...) stephen@mpeforth.com (Stephen Pelc) - 2016-03-29 16:58 +0000
          Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-28 12:29 +0000
            Re: File extensions and Gforth on Openhub Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-29 11:47 +0000
      Re: File extensions and Gforth on Openhub mhx@iae.nl - 2016-03-27 01:36 -0700
      Re: File extensions and Gforth on Openhub Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-27 15:19 +0000
    Re: File extensions and Gforth on Openhub Julian Fondren <julian.fondren@gmail.com> - 2016-03-26 19:51 -0700
      Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-27 08:01 +0000
        Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-27 15:00 +0100
          Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-27 14:15 +0000
            Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-29 08:13 +0100
              Re: File extensions and Gforth on Openhub Paul Rubin <no.email@nospam.invalid> - 2016-03-29 00:15 -0700
                Re: File extensions and Gforth on Openhub stephen@mpeforth.com (Stephen Pelc) - 2016-03-29 09:45 +0000
              Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 08:39 +0000
                Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-29 11:09 +0100
                  Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 10:35 +0000
                    Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-29 14:23 +0100
                      Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 16:47 +0000
                        Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-30 12:14 +0100
                          Re: File extensions and Gforth on Openhub Bob Butler <bob@work.com> - 2016-03-30 11:11 +0000
                            Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 14:10 +0000
                          Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 14:00 +0000
                            Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-30 17:27 +0100
                              Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 16:47 +0000
                    Re: File extensions and Gforth on Openhub Julian Fondren <julian.fondren@gmail.com> - 2016-03-29 09:41 -0700
          Re: File extensions and Gforth on Openhub stephen@mpeforth.com (Stephen Pelc) - 2016-03-28 13:34 +0000
            Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-28 14:17 +0000
              Re: File extensions and Gforth on Openhub stephen@mpeforth.com (Stephen Pelc) - 2016-03-28 15:24 +0000
                Re: File extensions and Gforth on Openhub Paul Rubin <no.email@nospam.invalid> - 2016-03-28 10:51 -0700
                  Re: File extensions and Gforth on Openhub foxaudioresearch@gmail.com - 2016-03-28 18:35 -0700
                  Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-29 08:05 +0100
                Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 07:12 +0000
                  Re: File extensions and Gforth on Openhub Paul Rubin <no.email@nospam.invalid> - 2016-03-29 00:42 -0700
                  Re: File extensions and Gforth on Openhub stephen@mpeforth.com (Stephen Pelc) - 2016-03-29 09:55 +0000
                    Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 10:23 +0000
      Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-27 14:09 +0000
      Re: File extensions and Gforth on Openhub Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-27 15:20 +0000
    Re: File extensions and Gforth on Openhub "Steve(spt)" <steven@jupiter-ace.co.uk> - 2016-03-28 06:44 -0700
    Re: File extensions and Gforth on Openhub Lars Brinkhoff <lars.spam@nocrew.org> - 2016-03-30 08:49 +0200

Page 1 of 3  [1] 2 3  Next page →

#46216 — File extensions and Gforth on Openhub

I came across <https://www.openhub.net/p/gforth>; the site produces
statistics over various software projects available in source,
including Gforth.  The statistics are sometimes interesting, sometimes
amusing.

One particular amusing aspect is that the statistics thinks that
Gforth contains 86k code lines of F# code, and 29 code lines of Forth
code.

This reminded me that we had a discussion about Forth file extensions
at EuroForth 2015 (or in the Forth-200x meeting).  Someone had already
made some statistics about the popularity of file extensions (IIRC
posted here).  In the discussion, it turned out that, while .4th is
relatively unpopular, it was the only file extension in common use
that is not primarily associated with some non-Forth usage.

Here are the non-Forth usages of some file extensions:

.fth Foobar2000 Theme File; FileMaker Theme File
.f   Fortran
.frt FoxPro (file-extensions.org only lists GP-Forth)
.4   man pages and others

So we decided that theforth.net uses .4th as default file extension
(essentially for package.4th).  Now the question is if we should not
move in that direction as a community in general.  I.e., add .4th as
extension to various tools we support, and use .4th as extension in
new projects, or maybe even in new files in old projects.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [next] | [standalone]

#46224

Am Sat, 26 Mar 2016 08:15:04 +0000 schrieb Anton Ertl:
> So we decided that theforth.net uses .4th as default file extension
> (essentially for package.4th).  Now the question is if we should not
> move in that direction as a community in general.  I.e., add .4th as
> extension to various tools we support, and use .4th as extension in new
> projects, or maybe even in new files in old projects.

We should probably register the extension as trademark, so that we have 
some title in our hands to sue the hell out of extension-grabbers like 
Microsoft ;-).  Not that this has any chance of working, SwiftForth/SwiftX 
vs. Apple's Swift is also not gaining ground. I guess that in two or 
three years, Apple will sue Forth Inc. to stop using their high-value 
brand(tm).  And win; they seem to have bought the court.

As user, I would absolutely hate it when the next release of my Forth 
system would break all my programs which include some system library, 
just because the maintainer had changed all the extensions.  So, in order 
to make a change of file extensions possible, we would first need to 
specify that INCLUDE works even when you don't specify the extension.  At 
the moment, the de facto standard is that Forth systems just perform OPEN-
FILE on the name provided by INCLUDE or INCLUDED or REQUIRE and REQUIRED. 
Some systems like Gforth have a search path, some systems like VFX use 
the macro expansion of SUBSTITUTE.  Neither one is appropriate for a 
graceful migration of suffixes, though in VFX, you could say include file%
4th%, and you can set it to replace to either one or the other suffix; 
but the typical situation during migration is that you have both: files 
with the old, and files with the new suffix.

Judging from the past discussions about source file names, I think that 
any approach that nails it down to one particular way of processing file 
names will not be accepted. "We have done it this way for 20 years, and 
you don't want to wade through 1 million lines of code and change it", 
and I think yes, that's reasonable.  I wouldn't want to do that, either.  
So the thing is to make sure that the 1 millions lines of code can 
survive untouched even if the system libraries all change their suffix 
from .fth to .4th (but only those).  And I also want to make sure that 
nobody else needs to implement the code necessary for this stunt in his 
Forth system which is not burdened with the 1 million lines of code.  
There are also severe discrepancies *where* the handling happens: In VFX, 
EXPANDMACROS is called from OPEN-FILE, while in Gforth, INCLUDED calls 
OPEN-FPATH-FILE, which does the path lookup and when it succeeds to open 
a file, it returns that file handle plus the path where it found it.

So my proposal would be in that direction: Push that actual semantics out 
of the standard into a library, and just make sure the necessary plugin 
interface is standardized.  That would allow us to say "require some-
packet" and the logic behind expanding filenames in require could say "ok, 
there's no file for that in the search path, but let's look in 
theforth.net package list, if we find one - and if so, download that, and 
include it", which would be part of the fget include.  You probably don't 
want to have this on open-file, though... so the plugin mechanism must be 
able to distinguish between these cases.

I've checked three Forth systems which do perform non-trivial operations 
on file names in include (trivial is e.g. convert it to a C string to 
pass it to the OS):

VFX: Performs macroexpand in open-file (hard-coded)
Gforth: Uses open-fpath-file (path search) in included (hard-coded)
bigForth: Has a deferred word >path.file in open-file, which does all the 
trivial but non-portable and non-trivial, but portable things together, 
i.e. it returns a C-string file name with path.

I don't think any of these are a good solution, but bigForth is closest 
to what I have in mind (probably no surprise ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#46228

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Am Sat, 26 Mar 2016 08:15:04 +0000 schrieb Anton Ertl:
>> So we decided that theforth.net uses .4th as default file extension
>> (essentially for package.4th).  Now the question is if we should not
>> move in that direction as a community in general.  I.e., add .4th as
>> extension to various tools we support, and use .4th as extension in new
>> projects, or maybe even in new files in old projects.
...
>As user, I would absolutely hate it when the next release of my Forth 
>system would break all my programs which include some system library, 
>just because the maintainer had changed all the extensions.

That's why I did not suggest changing existing files.

>So, in order 
>to make a change of file extensions possible, we would first need to 
>specify that INCLUDE works even when you don't specify the extension.

That would not help existing code that contains the file extension.

Of course, if we wanted to support changing the extension of existing
files, these words could try the filename with the new extension if
the file name with the old extension does not work.  But it is simpler
not to change existing files.

>Judging from the past discussions about source file names, I think that 
>any approach that nails it down to one particular way of processing file 
>names will not be accepted.

True.  One more reason not to change existing files.

> "We have done it this way for 20 years, and 
>you don't want to wade through 1 million lines of code and change it", 
>and I think yes, that's reasonable.

Actually, I did not hear that argument when discussing the directories
RfDs.  It was more like "We don't have this problem (we build programs
on only one system and deliver binaries, so setting up the directories
for finding the source code in the source code is the way to do it;
and we use SUBSTITUTE for that, and that's the best thing since sliced
bread, and it will make your proposal unnecessary), so what you
propose is unnecessary."

>So my proposal would be in that direction: Push that actual semantics out 
>of the standard into a library, and just make sure the necessary plugin 
>interface is standardized.  That would allow us to say "require some-
>packet" and the logic behind expanding filenames in require could say "ok, 
>there's no file for that in the search path, but let's look in 
>theforth.net package list, if we find one - and if so, download that, and 
>include it", which would be part of the fget include.  You probably don't 
>want to have this on open-file, though... so the plugin mechanism must be 
>able to distinguish between these cases.

Interesting idea.  Now if two libraries use their own plug-ins, how to
combine that?  And how do you overcome the "we don't have this
problem" attitude?

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#46238

Am Sun, 27 Mar 2016 07:32:54 +0000 schrieb Anton Ertl:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>Am Sat, 26 Mar 2016 08:15:04 +0000 schrieb Anton Ertl:
>>As user, I would absolutely hate it when the next release of my Forth
>>system would break all my programs which include some system library,
>>just because the maintainer had changed all the extensions.
> 
> That's why I did not suggest changing existing files.

But that's a bad idea: The existing files continue to have the problem, 
e.g. being wrongly syntax-highlighted in the editor, because the editor 
thinks it is a F# file.  Furthermore, inconsistent extensions are 
annoying, too.  I want to load the string library, is it called string.fs 
or is it a new library which would come under the name string.4th? And, 
what could be worse: They both might exist, but actually be two different 
string libraries, the first our "old, legacy" one, and the new string.4th 
the "shiny new, much better one", which unfortunately is incompatible...

Don't.  If you change things like extensions, change them everywhere.  
And before you do that, make sure the change will go smooth.

>>So, in order to make a change of file extensions possible, we would
>>first need to specify that INCLUDE works even when you don't specify the
>>extension.
> 
> That would not help existing code that contains the file extension.

A warning could be printed when the existing code still uses the file 
extension, like "in <file>:<line>: explicit use of file extensions for 
include is deprecated".

> Of course, if we wanted to support changing the extension of existing
> files, these words could try the filename with the new extension if the
> file name with the old extension does not work.  But it is simpler not
> to change existing files.

If there weren't any drawbacks with the existing extension, we don't need 
to change anything.

>>Judging from the past discussions about source file names, I think that
>>any approach that nails it down to one particular way of processing file
>>names will not be accepted.
> 
> True.  One more reason not to change existing files.

Still doesn't help with the drawbacks.  Funny that you are in the "we 
don't have a problem" camp here.  If we don't have a problem with the 
existing file extensions, we can stop the discussion right now.  If we 
have a problem, it includes existing files, and they better get the new, 
non-conflicting suffix.

On Linux, we haven't problems with .fs now, because nobody is using .net 
on Linux, and for the Windows users, we don't give a shit ;-).  This may 
change in the next years (the Linux use of .net, not that we don't give a 
shit with Windows users problems; that won't change ;-).

>> "We have done it this way for 20 years, and
>>you don't want to wade through 1 million lines of code and change it",
>>and I think yes, that's reasonable.
> 
> Actually, I did not hear that argument when discussing the directories
> RfDs.  It was more like "We don't have this problem (we build programs
> on only one system and deliver binaries, so setting up the directories
> for finding the source code in the source code is the way to do it; and
> we use SUBSTITUTE for that, and that's the best thing since sliced
> bread, and it will make your proposal unnecessary), so what you propose
> is unnecessary."

It looks like VFX is a "works for me" product in that respect, it ships 
with some of these macros set to the paths Stephen Pelc's computer uses.  
This definitely works for him, with settings like "vfxpath = /home/
stephen/Products/VfxForth.dev/Sources".  I doubt it works for anybody 
else.  Strictly speaking, I think the shipping of MINOS without an out-of-
the-box setting to find the dependencies was a GPL violation, as the GPL 
requires all build scripts ;-).

Maybe the VFX users don't have the expectation of things working out of 
the box, and actually read the manual to change that setting... or figure 
out that they really ought to buy that support contract MPE wants them to 
sell ;-).  There's an incentive for MPE to deliver something that doesn't 
work without support; while for us, there's an incentive to deliver 
something that does, because for us, support is our cost.

>>So my proposal would be in that direction: Push that actual semantics
>>out of the standard into a library, and just make sure the necessary
>>plugin interface is standardized.  That would allow us to say "require
>>some- packet" and the logic behind expanding filenames in require could
>>say "ok,
>>there's no file for that in the search path, but let's look in
>>theforth.net package list, if we find one - and if so, download that,
>>and include it", which would be part of the fget include.  You probably
>>don't want to have this on open-file, though... so the plugin mechanism
>>must be able to distinguish between these cases.
> 
> Interesting idea.  Now if two libraries use their own plug-ins, how to
> combine that?  And how do you overcome the "we don't have this problem"
> attitude?

As usual with global settings and libraries: It is expected that the 
library reverts the setting to the previous one, unless the library's 
purpose is to change that setting.  It's the same issue as with BASE or 
the search order, and recognizers.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#46250

On Sun, 27 Mar 2016 21:29:47 -0000 (UTC), Bernd Paysan
<bernd.paysan@gmx.de> wrote:

>On Linux, we haven't problems with .fs now, because nobody is using .net 
>on Linux, and for the Windows users, we don't give a shit ;-).  This may 
>change in the next years (the Linux use of .net, not that we don't give a 
>shit with Windows users problems; that won't change ;-).

This comes down to the meaning of Hillel's aphorism, which starts:
  “If I am not for myself, who will be for me?"

As a Linux promoter, it would also be appropriate to understand the
meaning of the word Ubuntu.


>> Actually, I did not hear that argument when discussing the directories
>> RfDs.  It was more like "We don't have this problem (we build programs
>> on only one system and deliver binaries, so setting up the directories
>> for finding the source code in the source code is the way to do it; and
>> we use SUBSTITUTE for that, and that's the best thing since sliced
>> bread, and it will make your proposal unnecessary), so what you propose
>> is unnecessary."
>

My position on the directory proposal ended up being:
1) Most systems have their own default behaviour, which may not be
what a particular person wants. So, make the wanted behaviour explicit
by using (say) a prefix.
2) You can make these prefices compatible with SUBSTITUTE by making
the prefices be of the form %xxx%. VFX has done this for more than
15 years without a single tech support issue.
3) MPE has no position on directory search lists. Clients who value
code know where it is because they put it there.

>It looks like VFX is a "works for me" product in that respect, it ships 
>with some of these macros set to the paths Stephen Pelc's computer uses.

This simply reflects the importance of x86 Linux in the scheme of
things. The ranking order in our scheme is
  Windows
  OS X
  ARM Linux
  x86 Linux

Given your attitude to Windows users stated above, surely you have to
expect the same treatment from Windows users?

The vast majority of x86 Linux users do not pay for their toys from
MPE, and they are the rudest. If you want want change from a supplier,
it is usually more productive to be polite.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#46254 — relative file names and INCLUDED (was: File extensions ...)

stephen@mpeforth.com (Stephen Pelc) writes:
>On Sun, 27 Mar 2016 21:29:47 -0000 (UTC), Bernd Paysan
><bernd.paysan@gmx.de> wrote:
>>> Actually, I did not hear that argument when discussing the directories
>>> RfDs.  It was more like "We don't have this problem (we build programs
>>> on only one system and deliver binaries, so setting up the directories
>>> for finding the source code in the source code is the way to do it; and
>>> we use SUBSTITUTE for that, and that's the best thing since sliced
>>> bread, and it will make your proposal unnecessary), so what you propose
>>> is unnecessary."
>>
>
>My position on the directory proposal ended up being:
>1) Most systems have their own default behaviour, which may not be
>what a particular person wants. So, make the wanted behaviour explicit
>by using (say) a prefix.

I tried to accomodate that by proposing a prefix.  You still showed it
a cold shoulder.  You even cold-shouldered the minimal proposal that
just tried to propose totally uncontroversial things
<http://www.forth200x.org/directories1.html>.

Given that, and more importantly, the fact that many programmers are
not going to use prefixes when they should, leading to problems
downstream, I now think that we should not go for prefixes.
Source-directory-relative should be the default for relative file
names in INCLUDED etc. (and for legacy programs the system can also
try working-directory-relative afterwards, and maybe warn if both
exist).

>2) You can make these prefices compatible with SUBSTITUTE by making
>the prefices be of the form %xxx%. VFX has done this for more than
>15 years without a single tech support issue.

Ok, I'll try this:

We have a main program with a library in a subdirectory, the library
consisting of several files.  The library wants to refer to its part
with a source-directory-relative file name, and uses the %xxx% prefix
for that:

[~/tmp/vfxtest:87002] cat main.fs
include lib/lib.fs
[~/tmp/vfxtest:87003] cat lib/lib.fs
include %xxx%part.fs
[~/tmp/vfxtest:87004] cat lib/part.fs 
." part" cr
[~/tmp/vfxtest:87005] vfxlin "include main.fs"
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including main.fs
Including lib/lib.fs
Including %xxx%part.fs
Err# -258 ERR: Failed to open requested file.
 Source: "lib/lib.fs" on line 1 
 -> include %xxx%part.fs
                       ^

Nope, the %xxx% prefix does not work.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#46256 — Re: relative file names and INCLUDED (was: File extensions ...)

On Mon, 28 Mar 2016 14:25:34 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>>2) You can make these prefices compatible with SUBSTITUTE by making
>>the prefices be of the form %xxx%. VFX has done this for more than
>>15 years without a single tech support issue.
>
>Ok, I'll try this:
>
>We have a main program with a library in a subdirectory, the library
>consisting of several files.  The library wants to refer to its part
>with a source-directory-relative file name, and uses the %xxx% prefix
>for that:
>
>[~/tmp/vfxtest:87002] cat main.fs
>include lib/lib.fs
>[~/tmp/vfxtest:87003] cat lib/lib.fs
>include %xxx%part.fs
>[~/tmp/vfxtest:87004] cat lib/part.fs 
>." part" cr
>[~/tmp/vfxtest:87005] vfxlin "include main.fs"
>VFX Forth for Linux IA32 Version: 4.72 [build 0555]
>Including main.fs
>Including lib/lib.fs
>Including %xxx%part.fs
>Err# -258 ERR: Failed to open requested file.
> Source: "lib/lib.fs" on line 1 
> -> include %xxx%part.fs

>Nope, the %xxx% prefix does not work.

Hey, you have to be able to read! I said "of the form %xxx%". Section
18.4 of the VFX Forth for Linux manual, entitled "System Defined
Macros", describes the IDIR macro, which expands relative to the file
currently being INCLUDEd. 

That Linux culture seems to prevent people reading manuals is a shame.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#46259 — Re: relative file names and INCLUDED (was: File extensions ...)

Am Mon, 28 Mar 2016 15:35:49 +0000 schrieb Stephen Pelc:
> That Linux culture seems to prevent people reading manuals is a shame.

It is much easier if the thing works out of the box, and you don't have 
to read anything in the manual.  And in communication, you just could 
write the correct %idir%/file example, instead of some %xxx%.

IMHO our expectation is different, and that comes from different 
understanding what "Ubuntu" means.  In my world, download it, compile it, 
works is the expectation.  It's not download it, read the manual, edit 
some config file, compile it, read more in the manual, edit another config 
file, and then debug three show-stopper bugs, and then it works.  That's 
ok when I'm testing an early version.

If you want to get Forth libraries to be written *and* used, it must be 
easy and work out of the box.  There are many things you, as distributor, 
don't control about the target, where your code will run.  The directory 
where it is downloaded to is one thing.

When you typically ship binaries, then this thing is not important.  The 
developer in this case is controlling his environment, and that's 
sufficient.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#46281 — Re: relative file names and INCLUDED (was: File extensions ...)

stephen@mpeforth.com (Stephen Pelc) writes:
>Hey, you have to be able to read! I said "of the form %xxx%". Section
>18.4 of the VFX Forth for Linux manual, entitled "System Defined
>Macros", describes the IDIR macro, which expands relative to the file
>currently being INCLUDEd. 

Ok, I changed lib/lib.fs as follows:

include %IDIR%/part.fs

(after first trying "%IDIR%part.fs" unsuccessfully), and it works:

[~/tmp/vfxtest:87029] vfxlin "include main.fs"
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including main.fs
Including lib/lib.fs
Including %IDIR%/part.fspart

The last "part" is the output of the program.

>That Linux culture seems to prevent people reading manuals is a shame.

Not really sure what "Linux culture" has to do with it, whatever that
may be.

I do read manuals for software and other products, but life's too
short to read every manual for every product, and it is much too short
for rereading manuals all the time to search for things that may have
changed, or that may be there but hard to find.

I have had a longer look at the VFX manual at least once.  For
everyday use, it has several problems:

1) It's in an inconvenient format, and is hidden somewhere in the
depths of the file system.  When I need information about, say, xpdf,
I say "man xpdf", and I get the man page.  For the VFX manual, I first
have to find out the file name and locateion:

locate -i vfx|grep .pdf

About two dozen hits, but the right one is among them and viewed with

xpdf /usr/local/VfxLinEval/Doc/VfxLin.pdf

Anyway, quite a hurdle right at the start.

2) On various occasions I tried to find things in the VFX manual, and
failed.  IIRC your suggested remedy was to read the whole manual
instead of just searching for the thing I needed at the moment.  Of
course, my conclusion was not to use the VFX manual unless I have time
to read all of it and the task is worth that effort.

In this particular case, there is no mention of something of the form
%xxx% in the description of INCLUDE, nor in the whole chapter on
files.  The next place to look up would be the chapter that contains
SUBSTITUTE.  So if I look SUBSTITUTE up in the index (which indexes
only Forth words, not concepts or anything else), I get to chapter
31.4, which contains no mention of system-defined macros.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#46289 — Re: relative file names and INCLUDED (was: File extensions ...)

On Tue, 29 Mar 2016 07:42:54 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

<rant about VFX>

Anton, I'll take you seriously when you provide gforth with a
LOCATE system that does not require a database update, i.e. works
with any loaded source file and can be configured for any editor
regardless of the Linux command line conventions.

Please deal with deficiencies in gforth before ponitificating
about other Forths.

Stephen

P.S. Thank you for your comments about the deficiencies in the
VFX manual, which will be updated.

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#46295 — Re: relative file names and INCLUDED (was: File extensions ...)

stephen@mpeforth.com (Stephen Pelc) writes:

>On Tue, 29 Mar 2016 07:42:54 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:

><rant about VFX>

>Anton, I'll take you seriously when you provide gforth with a
>LOCATE system that does not require a database update, i.e. works
>with any loaded source file and can be configured for any editor
>regardless of the Linux command line conventions.

>Please deal with deficiencies in gforth before ponitificating
>about other Forths.

>Stephen

>P.S. Thank you for your comments about the deficiencies in the
>VFX manual, which will be updated.

I downloaded VFX in order to inspect the manual.
There are two documents, a reference manual for installation and
facilities, and a user manual, with more introductory material that
does have an index, which includes concepts and also persons
(Elizabeth Rather).
The user manual contains the usual introduction to Forth, stacks,
philosophical remarks etc. It looks good, but I'd have to read it
thoroughly and consciencely from a novice perspective in order to
assess it.
Instead I looked more deeply into the other.
It is a reference manual both in html and pdf format. It has a
side pane that allows to go to a section of interest. This document it
has no cross references. That may be considered a missed chance, but
it is clear that it would be a great effort and the result in improved
usability would be limited considered the following.

What is apparent that it is well organized with coherent sections,
each with a well choosen subject name. Each section can be
understood without undue need to reference other sections.
The side pane eminently serves to get an overview of what is possible
with vfxforth.

The reference manual would benefit from an index, that is a
remark that Anton made, and it stands.
The html files however are text files and if I want to know
about drop I might be inclined to do
    grep -C3 -iw drop *.html | more
anyway.
This compares favourable with e.g. gforth's info files, which are
compressed.

Of course reliability and usability is everything in a compiler,
but the documentation promises a professional experience using
vfxforth.

>--
>Stephen Pelc, stephenXXX@mpeforth.com
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#46296 — Re: relative file names and INCLUDED

On 3/29/16 11:34 AM, Albert van der Horst wrote:

> I downloaded VFX in order to inspect the manual.
> There are two documents, a reference manual for installation and
> facilities, and a user manual, with more introductory material that
> does have an index, which includes concepts and also persons
> (Elizabeth Rather).
> The user manual contains the usual introduction to Forth, stacks,
> philosophical remarks etc. It looks good, but I'd have to read it
> thoroughly and consciencely from a novice perspective in order to
> assess it.
> Instead I looked more deeply into the other.
> It is a reference manual both in html and pdf format. It has a
> side pane that allows to go to a section of interest. This document it
> has no cross references. That may be considered a missed chance, but
> it is clear that it would be a great effort and the result in improved
> usability would be limited considered the following.
>
> What is apparent that it is well organized with coherent sections,
> each with a well choosen subject name. Each section can be
> understood without undue need to reference other sections.
> The side pane eminently serves to get an overview of what is possible
> with vfxforth.
>
> The reference manual would benefit from an index, that is a
> remark that Anton made, and it stands.
> The html files however are text files and if I want to know
> about drop I might be inclined to do
>      grep -C3 -iw drop *.html | more
> anyway.
> This compares favourable with e.g. gforth's info files, which are
> compressed.
>
> Of course reliability and usability is everything in a compiler,
> but the documentation promises a professional experience using
> vfxforth.

Further, one can easily jump directly to the definition of a word in the
pdf using the Skim pdf reader. For example, in MFonVFX a right click on
a word in the editor brings up a menu where one can (among other things)
jump to the manual definition (which is of course surrounded by
associated words and definitions). *Very* handy. The process may be
different when in VFX, I don't know.

-Doug

[toc] | [prev] | [next] | [standalone]

#46332 — Re: relative file names and INCLUDED

Doug Hoffman <glidedog@gmail.com> writes:

>On 3/29/16 11:34 AM, Albert van der Horst wrote:

>> I downloaded VFX in order to inspect the manual.

Oops. I forget to mention that it is the evaluation version for
Linux. And I always nag people about not placing things in context.

<SNIP>
>> Of course reliability and usability is everything in a compiler,
>> but the documentation promises a professional experience using
>> vfxforth.

>Further, one can easily jump directly to the definition of a word in the
>pdf using the Skim pdf reader. For example, in MFonVFX a right click on
>a word in the editor brings up a menu where one can (among other things)
>jump to the manual definition (which is of course surrounded by
>associated words and definitions). *Very* handy. The process may be
>different when in VFX, I don't know.

Getting at a definitions description easily is important for usability.

Even in the minimalistic lina, there is pdf and html with a section for
each word in the core. (and LOCATE for user-loaded words, application or
library).
Having their section named after words you can do
    firefox ci86.lina64.html#'>R'
to get at the definition of >R immediately.
I was utterly surprised that this also works with pdf files:
    firefox ci86.lina64.pdf#'>R'
(but not for names that contain quotes).
The html file is heavily cross referenced and has a clickable index,
A definition has at an average 3 clickable "see also" references.
That was my effort, then the usual browers take it from there.

*Very* handy, indeed.

>-Doug

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#46335 — Re: relative file names and INCLUDED

On 3/30/16 10:21 AM, Albert van der Horst wrote:

> Getting at a definitions description easily is important for usability.
>
> Even in the minimalistic lina, there is pdf and html with a section for
> each word in the core. (and LOCATE for user-loaded words, application or
> library).
> Having their section named after words you can do
>      firefox ci86.lina64.html#'>R'
> to get at the definition of >R immediately.
> I was utterly surprised that this also works with pdf files:
>      firefox ci86.lina64.pdf#'>R'
> (but not for names that contain quotes).
> The html file is heavily cross referenced and has a clickable index,
> A definition has at an average 3 clickable "see also" references.
> That was my effort, then the usual browers take it from there.
>
> *Very* handy, indeed.

Yes. Thanks for that description. More tools like this, and the
knowledge that they are there and how to use them, should help those
using Forth.

-Doug

[toc] | [prev] | [next] | [standalone]

#46302 — Re: relative file names and INCLUDED (was: File extensions ...)

On 29 Mar 2016 15:34:55 GMT, Albert van der Horst
<albert@spenarnc.xs4all.nl> wrote:

>It is a reference manual both in html and pdf format. It has a
>side pane that allows to go to a section of interest. This document it
>has no cross references. That may be considered a missed chance, but
>it is clear that it would be a great effort and the result in improved
>usability would be limited considered the following.
>
>What is apparent that it is well organized with coherent sections,
>each with a well choosen subject name. Each section can be
>understood without undue need to reference other sections.
>The side pane eminently serves to get an overview of what is possible
>with vfxforth.
>
>The reference manual would benefit from an index, that is a
>remark that Anton made, and it stands.

Thank you for the review, presumably of VFX Forth for Linux
(VfxLin.pdf and the folder VfxLin.htm). The primary manual
is the PDF. The Forth tutorial is ProgramForth.pdf. Both 
have indices. The HTML manuals do not have indices because
at the time DocGen was written, generating HTML index pages
was a horror, whereas using pdftex for indices is easy.

This is not my area of expertise, and I (personally) prefer
PDF to HTML for manuals.

>The html files however are text files and if I want to know
>about drop I might be inclined to do
>    grep -C3 -iw drop *.html | more
>anyway.
>This compares favourable with e.g. gforth's info files, which are
>compressed.

If you set up the PDF help system, you can type:
  help drop
and VFX will display the relevant manual page.

You can also set up the LOCATE system.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#46252

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Am Sun, 27 Mar 2016 07:32:54 +0000 schrieb Anton Ertl:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Am Sat, 26 Mar 2016 08:15:04 +0000 schrieb Anton Ertl:
>>>As user, I would absolutely hate it when the next release of my Forth
>>>system would break all my programs which include some system library,
>>>just because the maintainer had changed all the extensions.
>> 
>> That's why I did not suggest changing existing files.
>
>But that's a bad idea: The existing files continue to have the problem, 
>e.g. being wrongly syntax-highlighted in the editor, because the editor 
>thinks it is a F# file.

If a project really has that problem (any occurences in the wild?),
they don't need me to suggest changing the extenson of the existing
file names.  They don't even need a consensus for a new extension in
that case.  So this issue is related to, but indepenent of what I was
suggesting.

>  Furthermore, inconsistent extensions are 
>annoying, too.  I want to load the string library, is it called string.fs 
>or is it a new library which would come under the name string.4th? And, 
>what could be worse: They both might exist, but actually be two different 
>string libraries, the first our "old, legacy" one, and the new string.4th 
>the "shiny new, much better one", which unfortunately is incompatible...

If the two files are related, that only occurs in the presense of
renaming, which I did not suggest; and I would hope that the project
members have enough sense to avoid that kind of confusion by also
making the basename different (e.g., string.fs and string2.4th).

If the two files are independent, we already have that problem now.
E.g., I find a string.fth coming with VFX, a string.f coming with
iForth (I would have expected SwiftForth), a string.4th coming with
PFE, and a string.fs coming with Gforth (actually, different versions
seem to include incompatible string.fs files; so much for project
members having sense; no matter, because they are all undocumented, so
anybody who uses that stuff is on their own).  And of course, if
someone wants to use two or more of these (e.g., because one library
uses one and another library uses another one), with the current lack
of directory support in the standard, the way to go is to put
everything in one directory.

Anyway, letting INCLUDE add or replace an extension would increase
that kind of confusion rather than reducing it.  E.g,, if there is

require string

which of the two should be included?

If there is

require string.fs

which of the two should be included?

>Don't.  If you change things like extensions, change them everywhere.  
>And before you do that, make sure the change will go smooth.

So your suggestion is to require various changes in Forth systems (to
make the file renamings go smooth), and that, when these changes are
implemented, everybody should switch all the files to the new common
extension?

That's quite a different, and somewhat complementary approach to what
I have suggested.  I believe that your suggestion has a very slim
chance of acceptance starting from where we are now.  My guess is that
people will see the costs of your suggestion higher than the benefits of 
having a common file extension.

OTOH, if my suggestion is accepted, and if you are right and it brings
about confusion and problems, then your suggestion has a better chance
of being accepted; of course smoothness is lost in this scenario.

However, I believe that there will not be much confusion and problems
if my suggestion is accepted.  Then maybe after some more years
passing, some existing projects may feel the desire to rename their
files to the new extension in order to benefit from better tool
support that will hopefully emerge.  We can add features to make that
transition smoother, and we can think about these features now, but
it's beyond what I am suggesting.

>>>So, in order to make a change of file extensions possible, we would
>>>first need to specify that INCLUDE works even when you don't specify the
>>>extension.
>> 
>> That would not help existing code that contains the file extension.
>
>A warning could be printed when the existing code still uses the file 
>extension, like "in <file>:<line>: explicit use of file extensions for 
>include is deprecated".

And that helps in which way?  Note that the topic is *legacy* code that
loads a new version of a library with changed extensions.

If I wanted to rename the files in a library (e.g., because my
editor becomes an F# editor for .fs files or something), what I would
do is to rename <file>.fs into <file>.4th, and also have a file
<file>.fs that contains just the following line:

require <file>.4th

(I think I can write that even in an F# editor).  No need for all
Forth systems to agree on an extension handling mechanism.  These stub
files are only needed for the load-files that were already used in the
old version (often only one file).

>> Of course, if we wanted to support changing the extension of existing
>> files, these words could try the filename with the new extension if the
>> file name with the old extension does not work.  But it is simpler not
>> to change existing files.
>
>If there weren't any drawbacks with the existing extension, we don't need 
>to change anything.

The question is if the drawbacks of renaming are not bigger than the
drawbacks of the existing extension.  I leave it to each project to
decide that for themselves.

>Still doesn't help with the drawbacks.  Funny that you are in the "we 
>don't have a problem" camp here.  If we don't have a problem with the 
>existing file extensions, we can stop the discussion right now.  If we 
>have a problem, it includes existing files, and they better get the new, 
>non-conflicting suffix.

We have a problem, but the questions are if 1) your suggested cure
(rename all existing code) is not worse than the disease and 2) you
can convince the whole community of that.

>On Linux, we haven't problems with .fs now, because nobody is using .net 
>on Linux, and for the Windows users, we don't give a shit ;-).  This may 
>change in the next years (the Linux use of .net, not that we don't give a 
>shit with Windows users problems; that won't change ;-).

I certainly do care for Windows users problems, and so do you, you
even make the Windows distributions.  As for .NET becoming more
relevant outside Windows, there was quite a lot of noise about Mono
maybe a decade ago, but I have not heard much about it in recent
years.  It seems to me that developers who drink the .NET Kool-Aid,
also use Windows-specific API calls, so .NET applications typically
work only on Windows.  Mono seems to be just a marketing effort by
Microsoft to make .NET seem more relevant than it is (e.g., to meet
token requirements for cross-platfrom-ness in some project bids), just
like the Windows POSIX support.

> Strictly speaking, I think the shipping of MINOS without an out-of-
>the-box setting to find the dependencies was a GPL violation, as the GPL 
>requires all build scripts ;-).

If there was a build script for that, the GPL requires you to include
it, but there is not, so there is no such requirement.

>>>So my proposal would be in that direction: Push that actual semantics
>>>out of the standard into a library, and just make sure the necessary
>>>plugin interface is standardized.  That would allow us to say "require
>>>some- packet" and the logic behind expanding filenames in require could
>>>say "ok,
>>>there's no file for that in the search path, but let's look in
>>>theforth.net package list, if we find one - and if so, download that,
>>>and include it", which would be part of the fget include.  You probably
>>>don't want to have this on open-file, though... so the plugin mechanism
>>>must be able to distinguish between these cases.
>> 
>> Interesting idea.  Now if two libraries use their own plug-ins, how to
>> combine that?  And how do you overcome the "we don't have this problem"
>> attitude?
>
>As usual with global settings and libraries: It is expected that the 
>library reverts the setting to the previous one, unless the library's 
>purpose is to change that setting.  It's the same issue as with BASE or 
>the search order, and recognizers.

Actually these cases are different:

BASE: there is no way you can combine BASEs, so you save it, change
it, and later restore it.  But even that is controversial, and is not
always done.  BASE seems to be a rather bad idea to me, and we are
slowly getting away from that, with number prefixes, and BASE-EXECUTE.

Search order: Here we typically add a new wordlist to the front of the
search order, and the others still remain in the search order
(possibly with some names shadowed).  Shadowing is relatively rare, so
that has not lead to big problems.

Recognizers: Again, we have a stack of recognizers to allow combining
them, with suggestions that we may want to add some to the end, and
maybe not remove them.  We don't have enough experience with
user-defined recognizers yet to see how that works out when combining
recognizers from different people; the potential for shadowing is
certainly higher.

Coming back to the issue at hand, defining a user-extendable mechanism
is a good idea if user extension is the primary goal, and even then
it's hard to get it right and easy to get it wrong, as evidenced by
BASE.

I don't think a user-extension mechanism is a good solution for the
problem of system implementors being unable to find consensus on a
standard mechanism for a problem.  Specifying a good user-defined
mechanism is harder (and more complex to specify and implement) than
specifying a common mechanism, so if we are too stupid to specify a
common mechanism, we are by far too stupid to specify a user-defined
mechanism.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#46291

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>Bernd Paysan <bernd.paysan@gmx.de> writes:
MSNIP>
>>> That would not help existing code that contains the file extension.
>>
>>A warning could be printed when the existing code still uses the file
>>extension, like "in <file>:<line>: explicit use of file extensions for
>>include is deprecated".

>And that helps in which way?  Note that the topic is *legacy* code that
>loads a new version of a library with changed extensions.

I would hate to see that warning. Forth files are interpreted and
that means they are versatile and multi purpose.
The configuration file for my com-4e5.frt is just a piece of Forth
code. I called it com-4e.cfg. I would hate that users of my communication
program are confronted with that warning, each time the configuration
file is automatically loaded.

My philosophy is :
 - use absolute filenames or filenames relative to the current working
     directory
 - don't change the current directory while compiling
 - for library code use a library, not a myriad of a source files and
    hide the mechanism (i.e. WANT)
 - If the extension is conventional (in my case .frt) there is
   a convention about a resulting executable (which is system
   dependant, e.g. exe) on windows.

Never went wrong with that.

>- anton
>--
>M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#46229

On Sunday, March 27, 2016 at 1:57:02 AM UTC+1, Bernd Paysan wrote:
> Am Sat, 26 Mar 2016 08:15:04 +0000 schrieb Anton Ertl:
> > So we decided that theforth.net uses .4th as default file extension
> > (essentially for package.4th).  Now the question is if we should not
> > move in that direction as a community in general.  I.e., add .4th as
> > extension to various tools we support, and use .4th as extension in new
> > projects, or maybe even in new files in old projects.
[..]
> 
> I've checked three Forth systems which do perform non-trivial operations 
> on file names in include (trivial is e.g. convert it to a C string to 
> pass it to the OS):
> 
> VFX: Performs macroexpand in open-file (hard-coded)
> Gforth: Uses open-fpath-file (path search) in included (hard-coded)
> bigForth: Has a deferred word >path.file in open-file, which does all the 
> trivial but non-portable and non-trivial, but portable things together, 
> i.e. it returns a C-string file name with path.
[..]

iForth uses the ".frt" extension.
For the past 25 years, NEEDS is the standard way to include libraries from
a configured INCLUDE path ( dfwforth/include ). No extension is needed, but
it is not forbidden:
gamma.frt(13): NEEDS -horner
(gamm.frt is actually in include, too).

NEEDS also supports subdirectories of the include directory, like this
xmini\bench.frt(1): NEEDS -xmini/basics

INCLUDE wants a fully qualified path, but it searches the current directory
and several other directories (also dfwforth/include) first.

Then there is +INCLUDE, which starts from the current file's location:
C:\dfwforth\examples\misc\md5-nwr.frt(9): 64BIT? [IF] +INCLUDE md5-nwr64.frt

-marcel

[toc] | [prev] | [next] | [standalone]

#46234

Bernd Paysan <bernd.paysan@gmx.de> writes:

>Am Sat, 26 Mar 2016 08:15:04 +0000 schrieb Anton Ertl:
>> So we decided that theforth.net uses .4th as default file extension
>> (essentially for package.4th).  Now the question is if we should not
>> move in that direction as a community in general.  I.e., add .4th as
>> extension to various tools we support, and use .4th as extension in new
>> projects, or maybe even in new files in old projects.

>We should probably register the extension as trademark, so that we have
>some title in our hands to sue the hell out of extension-grabbers like
>Microsoft ;-).  Not that this has any chance of working, SwiftForth/SwiftX
>vs. Apple's Swift is also not gaining ground. I guess that in two or
>three years, Apple will sue Forth Inc. to stop using their high-value
>brand(tm).  And win; they seem to have bought the court.

We should start with claiming some extension (e.g. .frt) as a de facto.
This means:
  incorporating the extension as a language syntax coloring in Vim
  have the extension in the gnu makefile database.

I also would like to have the -c option reserved for compilation
for all forth systems and register the rule

%: %.frt
    $(FORTH) -c $<

in GNU's

>As user, I would absolutely hate it when the next release of my Forth
>system would break all my programs which include some system library,
>just because the maintainer had changed all the extensions.  So, in order
>to make a change of file extensions possible, we would first need to
>specify that INCLUDE works even when you don't specify the extension.  At
>the moment, the de facto standard is that Forth systems just perform OPEN-
>FILE on the name provided by INCLUDE or INCLUDED or REQUIRE and REQUIRED.
>Some systems like Gforth have a search path, some systems like VFX use
>the macro expansion of SUBSTITUTE.  Neither one is appropriate for a
>graceful migration of suffixes, though in VFX, you could say include file%
>4th%, and you can set it to replace to either one or the other suffix;
>but the typical situation during migration is that you have both: files
>with the old, and files with the new suffix.

I can't see what path's have to do with suffix.

<SNIP>

>I've checked three Forth systems which do perform non-trivial operations
>on file names in include (trivial is e.g. convert it to a C string to
>pass it to the OS):

The only sensible operation on a source file name is transform
the forth suffix into .exe (for Windows) or nothing (for unices)
when a turnkey is generated.
Who needs a new file name, if there isn't a new file?

>--
>Bernd Paysan

Groetjes ALbert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#46225

On Saturday, March 26, 2016 at 3:49:54 AM UTC-5, Anton Ertl wrote:
> I came across <https://www.openhub.net/p/gforth>; the site produces
> statistics over various software projects available in source,
> including Gforth.  The statistics are sometimes interesting, sometimes
> amusing.
> 
> One particular amusing aspect is that the statistics thinks that
> Gforth contains 86k code lines of F# code, and 29 code lines of Forth
> code.

This conclusion uses https://www.openhub.net/p/ohcount , which
includes the ability to disambiguate languages based on file
contents.  Its source is on github.

github used to only go by file extension, but it seems that they
now use https://github.com/github/linguist for language
identification, and it seems that it supports Forth:
https://github.com/forthy42?tab=repositories

bitbucket just lets you declare what language a project uses.

Personally I like the

  .fs - Forth source
  .fb - Forth blocks
  .fi - Forth images

convention.  Which has the appeal of being potentially extensible.
You might have used .fp for Forth project files.  Perl does
something similar with .pm (Perl module) vs. .pl; Python has '.py'
and then '.pyc' for precompiled files, and then whatever '.pyo' is.
The FFL at least also uses these extensions.

> 
> Here are the non-Forth usages of some file extensions:
> 
> .fth Foobar2000 Theme File; FileMaker Theme File
> .f   Fortran
> .frt FoxPro (file-extensions.org only lists GP-Forth)
> .4   man pages and others
> 

.4 is an extension for *compiled* manpages.  Not something you'd
find in a repo.  I thought that F# was a pretty unimportant
collision, since it's just O'Caml or SML or something dialect for
.NET , but (with respect to .f) these are even less important.

The last version of FoxPro was released in 1994.  Visual FoxPro was
discontinued in 2007.  Theme files are not program source files.

>
> So we decided that theforth.net uses .4th as default file extension
> (essentially for package.4th).  Now the question is if we should not
> move in that direction as a community in general.  I.e., add .4th as
> extension to various tools we support, and use .4th as extension in
> new projects, or maybe even in new files in old projects.
> 

*shrug*. github and openhub both have language identification
libraries.  One already supports Forth and making the other support
it seems like a more direct path to getting openhub to accurately
identify Forth code.

I guess the overall point is Forth advocacy, by way of increased
visibility of Forth code.  That's a worthy goal, but, eh, '.4th' is
an ugly extension.  I don't like the emphasis on the number four.
The language is not actually called Fourth.  The potential advocacy
benefit from settling on an extension is small enough that I think
it should be weighed seriously against the small effect of the
displeasure people might experience when working with this
extension, which reminds them that some ancient filesystem had a
character limit, or suggests that the language they're using is
misspelled.

(4th and 8th of course can get away with these extensions since
this is the actual name of the implementation and language,
respectively.)

theforth.net looks nice, though.


-- Julian

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web