Win32Forth documentation
rickman
I am having trouble learning about the Win32Forth specific words. I
can't find any documentation on these and I can't get SEE to work
correctly on some words.
I am trying to do file I/O and when I look for the details of the
return codes, I see things like this...
11.6.2.1524 FILE-STATUS
FILE EXT
( c-addr u -- x ior )
Return the status of the file identified by the character string c-addr
u. If the file exists, ior is zero; otherwise ior is the
implementation-defined I/O result code. x contains
implementation-defined information about the file.
This is where they are supposed to be explaining what X means!
If anyone would like to give me more specific help, my problem is that
I am trying to create a file for writing. It keeps returning an error
code from CREATE-FILE. I am having trouble telling what directory it
uses by default. I can use DIR to list the directory contents, but the
directory changes when I use the menu LOAD command. I don't know if
that changes where the FILE words operate.
FILE-STATUS returns a non-zero value saying the file does not exist,
but I don't know what the other part of the return code means.
Likewise with CREATE-FILE.
dbu
rickman schrieb:
> I thought I had found a pretty well documented forth in Win32Forth,
Which win32forth Version are you using?
> but I am having trouble learning about the Win32Forth specific words. I
> can't find any documentation on these
There is documentation for some of them in the file UTILDOC.TXT.
> and I can't get SEE to work correctly on some words.
Which words make problems with SEE?
BTW with VIEW you can directly load the source for most words within
w32f.
> I am trying to do file I/O and when I look for the details of the
> return codes, I see things like this...
>
> 11.6.2.1524 FILE-STATUS
> FILE EXT
>
> ( c-addr u -- x ior )
>
> Return the status of the file identified by the character string c-addr
> u. If the file exists, ior is zero; otherwise ior is the
> implementation-defined I/O result code. x contains
> implementation-defined information about the file.
>
>
> This is where they are supposed to be explaining what X means!
>
> If anyone would like to give me more specific help, my problem is that
> I am trying to create a file for writing. It keeps returning an error
> code from CREATE-FILE. I am having trouble telling what directory it
> uses by default. I can use DIR to list the directory contents, but the
> directory changes when I use the menu LOAD command. I don't know if
> that changes where the FILE words operate.
You can get/set the current working directory with:
: $current-dir! ( a1 -- f1 ) \ a1 is a null terminated directory
string
: current-dir$ ( -- a1 ) \ get the full path to the current
directory
When you don't specify a complet path for your file (like
c:\temp\xyz.txt)
the file words work within this working directory.
> FILE-STATUS returns a non-zero value saying the file does not exist,
> but I don't know what the other part of the return code means.
> Likewise with CREATE-FILE.
Most of the file words in w32f only return TRUE or FALSE on error.
Some of them do return the windows error code.
In the later w32f versions you can get some help on the error with:
GetLastWinErr GetLastWinErrMsg count type
regards
Dirk Busch
P.S. Fell free to join the win32forth project group at:
http://groups.yahoo.com/group/win32forth
Coos Haak
In DOS, my CHForth FILE-STATUS returns the file-attribute bits (read-only,
hidden, archive, system).
For *NIX, access codes might be returned.
R/O, R/W, W/O and BIN are used for CREATE-FILE and OPEN-FILE
S" MYFILE" W/O CREATE-FILE
will make a file that can be written to only. After closing,
S" MYFILE" R/O OPEN-FILE
would than open it for reading and no writing.
Appending to files or changing contents in the middle, use R/W
LOAD is no standard word, so it might do anything from loading a block or
loading a file from another directory.
--
Coos
Andrew Haley
> LOAD is no standard word, so it might do anything from loading a
> block or loading a file from another directory.
I wonder if this is like the old joke when someone says
"'gullible' does not have a dictionary definition." and some poor
schmuck goes to look it up and then realizes ...
7.6.1.1790 LOAD
Andrew.
Coos Haak
My error, I was thinking of FLOAD ;-)
I also have LOAD implemented, because of the IMHO silly requirement the
BLOCK word set is needed when you have the FILE word set.
Have a nice weekend, it's Friday late afternoon. And the rain has stopped.
--
Coos
rickman
I am a bit confused about words that work with null terminated strings.
All my work in forth has used counted strings either in the array or
mostly on the stack. What equivalent words support null terminated
strings? What words convert?
I was looking for Starting Forth in PDF format and can't seem to find
it. HTML is fine, but I would like this reference off line and HTML is
a collection of files rather than a single file.
Jerry Avins
...
> I was looking for Starting Forth in PDF format and can't seem to find
> it. HTML is fine, but I would like this reference off line and HTML is
> a collection of files rather than a single file.
...
Email me your address an a solemn vow to return it and I'll lend you a
printed copy. Not the same, ANS and all that, but you might want it.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
rickman
somewhere at home. I am just looking for something more facile to use
at work. Actually, I don't expect there will be a lot of content that
I really need as I have done some Forth programming before. I am just
a bit rusty and thought it might be a good quick reference for the easy
stuff I just can't seem to recall.
I am currently working with Win32Forth writing a very simple file
comparison program for BOMs. I am finding that I just don't remember
the easy way to do string operations. I wrote a similar program at
home last year to generate PCB footprints and I expect I can find that
and very quickly recall how I did much of this same stuff. But I'll
have to wait until Monday and I wanted to wrap this up today. :(
Anton Ertl
>> FILE EXT
>>
>> ( c-addr u -- x ior )
>>
>> Return the status of the file identified by the character string c-addr
>> u. If the file exists, ior is zero; otherwise ior is the
>> implementation-defined I/O result code. x contains
>> implementation-defined information about the file.
>>
>>
>> This is where they are supposed to be explaining what X means!
The standard should have explained it, but did not, making the word
useless for standard programs. Why does the standard define such a
word? Different systems have implemented this in mutually
incompatible ways, making it impossible to standardize what x should
be.
>For *NIX, access codes might be returned.
My guess is that the intention was that for Unix, x would be a pointer
to a struct stat, and FILE-STATUS should be a wrapper for stat(2) or
lstat(2).
However, PFE implemented it differently (there x is a fam), and Gforth
followed PFE in this respect.
- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html
Maki
> it. HTML is fine, but I would like this reference off line and HTML is
> a collection of files rather than a single file.
I've manage to buy old, used Starting Forth over amazon for ~10 euro!
Good for reading without power supply and it is a single file :o)
M.
--
M. Veselic
Sigma Lab.
rickman
between Win32Forth and the ANS standard.
11.6.1.1520 FILE-POSITION FILE
( fileid -- ud ior )
ud is the current file position for the file identified by fileid. ior
is the implementation-defined
I/O result code. ud is undefined if ior is non-zero.
Seems pretty clear, put one item on the stack and get back two. But I
am getting three returned from FILE-POSITION as well as FILE-SIZE.
When I "see" the code for FILE-POSITION, it says
: FILE-POSITION 0 0 ROT lit 0x1 "0x40DBF4" ;
I don't know what to make of this unless "0x40DBF4" is a call address.
My return values seem to be the position and two zeros or the size and
two zeros.
Any idea why this diverges from the ANS spec? Or is "ior" not just an
undefined value, but an undefined size of data?
Coos Haak
Ever used a file longer than 64 Kb on a 16 bit system?
In my CHForth (16 bit) I have a block file 64 Mb long and with ud I can
easily adress anywhere in the file.
In the (probably) not so far future, files bigger than 4 TB may exist.
Forth is ready for them, even on 32 bit implementations.
The "0x40DBF4" is Win32Forth terminology for a headerless routine.
Its name SetFP can be found by typing: VIEW FILE-POSITION
--
Coos
Coos Haak
> Op 19 May 2006 14:27:19 -0700 schreef rickman:
>
>> I'm not sure, but I may have found a bug or at least a difference
>> between Win32Forth and the ANS standard.
>>
>> 11.6.1.1520 FILE-POSITION FILE
>> ( fileid -- ud ior )
>> ud is the current file position for the file identified by fileid. ior
>> is the implementation-defined
>> I/O result code. ud is undefined if ior is non-zero.
>>
<snip>
> In the (probably) not so far future, files bigger than 4 TB may exist.
Whew, it is worse, 4 GB already passes the 32 bit boundary!
> Forth is ready for them, even on 32 bit implementations.
>
> The "0x40DBF4" is Win32Forth terminology for a headerless routine.
> Its name SetFP can be found by typing: VIEW FILE-POSITION
P.S. I hope you know that ud (in FILE-POSITION and REPOSITION-FILE)
describes a double-precision number ;-)
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
rickman
That is what I am doing wrong. The "extra" zero is the MS half of the
double word! Thanks!!! :^)
Albert van der Horst
rickman <spamgo...@yahoo.com> wrote:
<SNIP>
>
>I am currently working with Win32Forth writing a very simple file
>comparison program for BOMs. I am finding that I just don't remember
>the easy way to do string operations. I wrote a similar program at
>home last year to generate PCB footprints and I expect I can find that
>and very quickly recall how I did much of this same stuff. But I'll
>have to wait until Monday and I wanted to wrap this up today. :(
What are BOM's?
If you can state the problem, I could take the challenge and
show how easy it can be handled in ciforth (lina/wina)
(I still have to encounter a string-problem that cannot be
readily handled by $@ $! $C+ $+! .
This includes a regular expression package, and a classic
assembler/disassembler with classic labels.)
>> Jerry
>> --
>> Engineering is the art of making what you want from things you can get.
>> =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
>=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
>=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF
>
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Albert van der Horst
Coos Haak <chf...@hccnet.nl> wrote:
>Op 19 May 2006 08:42:52 -0700 schreef rickman:
>
>> I thought I had found a pretty well documented forth in Win32Forth, but
>> I am having trouble learning about the Win32Forth specific words. I
>> can't find any documentation on these and I can't get SEE to work
>> correctly on some words.
Basically, if you are really into Windows programming, you need
to realize that you are running the c-API's through Win32Forth
and need a truck-load of Microsoft documentation.
>
>LOAD is no standard word, so it might do anything from loading a block or
>loading a file from another directory.
LOAD is a standard word from the BLOCK wordset. Note that the
BLOCK wordset is required if you have OPEN-FILE (or at least if you
want to claim to have them FILE wordset ).
>--
>Coos
Groetjes Albert
rickman
> In article <13pe02avbv7ux$.1hxwp2dwsj5if$.d...@40tude.net>,
> Coos Haak <chf...@hccnet.nl> wrote:
> >Op 19 May 2006 08:42:52 -0700 schreef rickman:
> >
> >> I thought I had found a pretty well documented forth in Win32Forth, but
> >> I am having trouble learning about the Win32Forth specific words. I
> >> can't find any documentation on these and I can't get SEE to work
> >> correctly on some words.
>
> Basically, if you are really into Windows programming, you need
> to realize that you are running the c-API's through Win32Forth
> and need a truck-load of Microsoft documentation.
No one is talking about using the API's of Windows and such. I am just
looking to create a simple program that I can process some files. I
don't want a GUI because I don't want to take the time to program it.
I spent a few hours yesterday on this and and I have much of the
program working now. I wish I had sent it home so I could finish it
off today. My only real issue is that the default directory and
setting the current directory is not documented. But I got those
commands here and now I should be good to go.
> >LOAD is no standard word, so it might do anything from loading a block or
> >loading a file from another directory.
>
> LOAD is a standard word from the BLOCK wordset. Note that the
> BLOCK wordset is required if you have OPEN-FILE (or at least if you
> want to claim to have them FILE wordset ).
He already posted that he meant FLOAD.
Anyone know if I can *easily* produce a standalone executable using
Win32Forth? I guess if push comes to shove, can I create a batch file
to run Win32Forth, load my program and run it with parameters from the
command line??? Or will I have to provide the user a list of
operations to run forth, load the program and then run it?
Jerry Avins
...
> What are BOM's?
[bill of materials]'s :-) Bills of materials is the proper plural; bill
of materials is the singular. Plural acronyms are subject to the whims
of AIG's (Acronym inspectors general).
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Alex McDonald
> Albert van der Horst wrote:
> > In article <13pe02avbv7ux$.1hxwp2dwsj5if$.d...@40tude.net>,
> > Coos Haak <chf...@hccnet.nl> wrote:
> > >Op 19 May 2006 08:42:52 -0700 schreef rickman:
> > >
> > >> I thought I had found a pretty well documented forth in Win32Forth, but
> > >> I am having trouble learning about the Win32Forth specific words. I
> > >> can't find any documentation on these and I can't get SEE to work
> > >> correctly on some words.
> >
> > Basically, if you are really into Windows programming, you need
> > to realize that you are running the c-API's through Win32Forth
> > and need a truck-load of Microsoft documentation.
>
> No one is talking about using the API's of Windows and such. I am just
> looking to create a simple program that I can process some files. I
> don't want a GUI because I don't want to take the time to program it.
Win32Forth adheres to ANS, and as noted elsewhere, the ior is
system-defined. In the W32F case, it's a simple error code, either true
or false, from all the x-FILE words; false for success. Windows
requires a call to get an extended error code that can be interpreted
by referring to the Windows API, or passed to another Windows routine
to get back an error message string that can be typed.
>
> I spent a few hours yesterday on this and and I have much of the
> program working now. I wish I had sent it home so I could finish it
> off today. My only real issue is that the default directory and
> setting the current directory is not documented. But I got those
> commands here and now I should be good to go.
Directory functions are, unfortunately, missing from the standard, and
from the W32F documentation.
>
> > >LOAD is no standard word, so it might do anything from loading a block or
> > >loading a file from another directory.
> >
> > LOAD is a standard word from the BLOCK wordset. Note that the
> > BLOCK wordset is required if you have OPEN-FILE (or at least if you
> > want to claim to have them FILE wordset ).
>
> He already posted that he meant FLOAD.
>
> Anyone know if I can *easily* produce a standalone executable using
> Win32Forth? I guess if push comes to shove, can I create a batch file
> to run Win32Forth, load my program and run it with parameters from the
> command line??? Or will I have to provide the user a list of
> operations to run forth, load the program and then run it?
Once you have tested your program, you can create an executable in
several ways. TURNKEY is the simplest. It creates an application
program that cannot run Forth any longer, because all headers are
discarded during the program save process. The 'cfa' of a forth
definition that runs your program must be passed to TURNKEY. TURNKEY
reduces the newly saved program image size by over 200k bytes.
Limitations: TURNKEYed programs cannot be debugged and the name passed
to TURNKEY must not be the same name as the Forth you are currently
running.
TURNKEY is used as follows;
' do-myprogram TURNKEY newprogram <enter>
The word CMDLINE returns the command line when the program you have
created is executed, and returns a counted string.
This is documented in doc\p-imageman.html, pointed directly from the
help file under "Building and saving an application". Hope this helps.
--
Regards
Alex McDonald
ziggy
"rickman" <spamgo...@yahoo.com> wrote:
Even file access would ultimately be thru the windows API's. ( not that
this helps you any, just a comment )
rickman
> rickman <spamgo...@yahoo.com> wrote:
> <SNIP>
> >
> >I am currently working with Win32Forth writing a very simple file
> >comparison program for BOMs. I am finding that I just don't remember
> >the easy way to do string operations. I wrote a similar program at
> >home last year to generate PCB footprints and I expect I can find that
> >and very quickly recall how I did much of this same stuff. But I'll
> >have to wait until Monday and I wanted to wrap this up today. :(
>
> What are BOM's?
Like Jerry said, they are lists of parts for a board (Bill Of
Material). Unfortunately many people pronounce it like BOMB. I don't
care for this given the current sensitivity to anything BOMB-like. :(
I prefer to pronouce it by spelling it out Be-Oh-Em.
> If you can state the problem, I could take the challenge and
> show how easy it can be handled in ciforth (lina/wina)
> (I still have to encounter a string-problem that cannot be
> readily handled by $@ $! $C+ $+! .
> This includes a regular expression package, and a classic
> assembler/disassembler with classic labels.)
Ok, I have a lot of it coded up and found some parts that require some
awkaward stack manipulations when reading lines. So I would appreciate
an alternate approach since I expect no two Forth programs will look
much alike. ;^)
I will have two equivalent CSV (comma separated value) files. Each
file will contain a superfluous header ending with a line starting with
8 dashes "-". All following lines are data entries, one per line, with
page separators which also start with 8 dashes.
The fields of the data lines are separated by commas and consist of
1) Part Numbers (PN) - alphanumeric with special chars (dash, slash,
etc) (e.g. SS-7024-501)
2) Reference Designator (RD) - alpha followed by numeric. Alpha is
single character, but not sure this is a real rule or just my data set.
(e.g. R12, R112, U7, U27, Y2, etc).
3-6) The third through 6th comma separated fields are ignored.
7) The seventh field contains the total count of this PN in this file.
This should be saved and compared to all other matching parts for
consistency.
8-N) remaining fields are not parsed, but will be printed to file with
entire line.
The input file data lines are already sorted by the RD. I'm not
certain on the type of sort, but it appears to be an alpha sort.
The processing on these files will be to skip the header lines and read
one data line from each file. The RDs are compared. If the same, the
PNs are compared. If the PNs match, the part is unchanged. If the PNs
do not match, the line from each file is written to the output file
with "CHANGE(1/2) - "appended to the start of each line (1 or 2, to
indicate which file the line came from). For all parts with matching
RDs a new part line should be read from each file.
If the RDs do not match, they are compared for order. If the RD from
file 1 is earlier than the RD from file 2, the part is considered
deleted and the line from file 1 should be written to the output file
with "DELETE1 - " appended to the beginning of the line. If the RD
from file 2 is earlier than the RD from file 1, the part is considered
as added and the line from file 2 should be written to the output file
with "ADDED2 - " appended to the front. In either case a new line
should be read from the cooresponding file.
The processing should continue until both files are at EOF. If one
file reaches EOF first, the parts in the remaining file are compared as
if the empty file contained non-matching data with a higher RD
(generate ADDEDs or DELETEs as appropriate).
For each unique PN found, running counts should be kept for each input
file. The number of ADDED2, CHANGE1/2 and DELETE1 should be counted as
well. Once both files are at EOF, this data should be written out for
each PN. The data should also be checked for consistency and errors
flagged. (PN count in file 1 - DELETE1 - CHANGE1 + CHANGE2 + ADDED2 =
file 2 count)
A total of 1000 unique parts should be allowed.
Albert van der Horst
rickman <spamgo...@yahoo.com> wrote:
<SNIP>
>
>> >LOAD is no standard word, so it might do anything from loading a block or
>> >loading a file from another directory.
>>
>> LOAD is a standard word from the BLOCK wordset. Note that the
>> BLOCK wordset is required if you have OPEN-FILE (or at least if you
>> want to claim to have them FILE wordset ).
>
>He already posted that he meant FLOAD.
>
>Anyone know if I can *easily* produce a standalone executable using
>Win32Forth? I guess if push comes to shove, can I create a batch file
>to run Win32Forth, load my program and run it with parameters from the
>command line??? Or will I have to provide the user a list of
>operations to run forth, load the program and then run it?
I can't comment on Win32Forth. This is how easy it *should* be
to compare two files:
------------8< ----------------- 8< ------------------
: MAIN
1 ARG[] GET-FILE >R
2 ARG[] GET-FILE
DUP R> <> IF ." Lenghts differ" ELSE
CORA IF ." Files are different"
ELSE ." Files are equal" THEN THEN
CR
;
------------8< ----------------- 8< ------------------
Save the file in doit.frt
(And yes the words you don't know are in the documentation
or in the library files.)
On linux:
lina -c doit.frt
(Tested)
On windows (3.11 NT XP whatever)
wina -c doit.frt
Use as
doit aap noot
Under windows:
place doit.exe on the desktop.
Select two files and drop them on the desktop icon.
Restriction :
under Windows
it may not work with long filenames.
rickman
> to compare two files:
>
> ------------8< ----------------- 8< ------------------
> : MAIN
> 1 ARG[] GET-FILE >R
> 2 ARG[] GET-FILE
> DUP R> <> IF ." Lenghts differ" ELSE
> CORA IF ." Files are different"
> ELSE ." Files are equal" THEN THEN
> CR
> ;
If I only wanted to compare the two files for equivalency, I can just
go to a DOS window and type FC (file1) (file2).