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

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

How to get an address for a string by direct user input without using PAD

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

Contents

  How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-08 18:26 -0800
    Re: How to get an address for a string by direct user input without using PAD albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-09 12:18 +0000
      Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-09 20:00 -0800
        Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-13 15:47 -0800
    Re: How to get an address for a string by direct user input without using PAD anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-09 13:02 +0000
      Re: How to get an address for a string by direct user input without using PAD anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-09 13:12 +0000
    Re: How to get an address for a string by direct user input without using PAD Julian Fondren <julian.fondren@gmail.com> - 2014-02-09 08:48 -0800
      Re: How to get an address for a string by direct user input without using PAD henry.lenzi@gmail.com - 2014-02-11 16:22 -0800
      Re: How to get an address for a string by direct user input without using PAD henry.lenzi@gmail.com - 2014-02-11 16:22 -0800
    Re: How to get an address for a string by direct user input without using PAD "Elizabeth D. Rather" <erather@forth.com> - 2014-02-09 08:47 -1000
      Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-09 18:13 -0800
        Re: How to get an address for a string by direct user input without using PAD Julian Fondren <julian.fondren@gmail.com> - 2014-02-10 02:27 -0800
          Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-14 01:20 -0800
            Re: How to get an address for a string by direct user input without using PAD Julian Fondren <julian.fondren@gmail.com> - 2014-02-18 14:14 -0800
              Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-18 20:11 -0800
                Re: How to get an address for a string by direct user input without using PAD Julian Fondren <julian.fondren@gmail.com> - 2014-02-19 06:56 -0800
              Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-18 21:17 -0800
        Re: How to get an address for a string by direct user input without using PAD Steve <jsgrahamus@yahoo.com> - 2014-02-10 19:29 +0000
          Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-14 01:34 -0800
        Re: How to get an address for a string by direct user input without using PAD henry.lenzi@gmail.com - 2014-02-11 16:25 -0800
      Re: How to get an address for a string by direct user input without using PAD henry.lenzi@gmail.com - 2014-02-11 16:59 -0800
        Re: How to get an address for a string by direct user input without using PAD "Elizabeth D. Rather" <erather@forth.com> - 2014-02-11 16:58 -1000
          Re: How to get an address for a string by direct user input without using PAD henry.lenzi@gmail.com - 2014-02-12 16:07 -0800
            Re: How to get an address for a string by direct user input without using PAD Paul Rubin <no.email@nospam.invalid> - 2014-02-12 16:46 -0800
              Re: How to get an address for a string by direct user input without using PAD Paul Rubin <no.email@nospam.invalid> - 2014-02-12 16:47 -0800
                Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-13 15:53 -0800
              Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-13 15:52 -0800
            Re: How to get an address for a string by direct user input without using PAD "Elizabeth D. Rather" <erather@forth.com> - 2014-02-12 14:32 -1000
              Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-12 17:13 -0800
                Re: How to get an address for a string by direct user input without using PAD Paul Rubin <no.email@nospam.invalid> - 2014-02-12 18:56 -0800
                  Re: How to get an address for a string by direct user input without using PAD anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 08:40 +0000
                    Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-13 17:16 -0800
                  Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-13 16:32 -0800
                Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-14 01:11 -0800
                  Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-15 12:15 -0800
                    Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-15 17:35 -0800
                Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-14 12:02 -0800
                  Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-15 12:57 -0800
                    Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-15 18:12 -0800
                      Re: How to get an address for a string by direct user input without using PAD henry.lenzi@gmail.com - 2014-02-15 19:10 -0800
                        Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-15 19:34 -0800
                          Re: How to get an address for a string by direct user input without using PAD "Alex McDonald" <blog@rivadpm.com> - 2014-02-16 09:48 +0000
                            Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-16 03:21 -0800
                              Re: How to get an address for a string by direct user input without using PAD albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-17 12:38 +0000
                                Re: How to get an address for a string by direct user input without using PAD Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-17 08:09 -0600
                                  Re: How to get an address for a string by direct user input without using PAD Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-17 19:32 +0100
                              Re: How to get an address for a string by direct user input without using PAD "Alex McDonald" <blog@rivadpm.com> - 2014-02-17 14:53 +0000
                                Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-17 20:48 -0800
                                  Re: How to get an address for a string by direct user input without using PAD "Alex McDonald" <blog@rivadpm.com> - 2014-02-18 16:21 +0000
                        Re: How to get an address for a string by direct user input without using PAD Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-02-16 09:32 +0100
                        Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-16 03:07 -0800
                        Re: How to get an address for a string by direct user input without using PAD Alexander Skobelev <al.skobelev@gmail.com> - 2014-02-16 10:09 -0800
                          Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-16 15:39 -0800
                          Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-17 19:54 -0800
                            Re: How to get an address for a string by direct user input without using PAD "Elizabeth D. Rather" <erather@forth.com> - 2014-02-17 19:51 -1000
                              Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-18 16:40 -0800
                            Re: How to get an address for a string by direct user input without using PAD humptydumpty <ouatubi@gmail.com> - 2014-02-18 11:44 -0800
                              Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-18 15:18 -0800
                            Re: How to get an address for a string by direct user input without using PAD Julian Fondren <julian.fondren@gmail.com> - 2014-02-18 14:48 -0800
                              Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-18 16:00 -0800
                                Re: How to get an address for a string by direct user input without using PAD albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-19 01:01 +0000
                                  Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-18 18:11 -0800
                                    Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-18 18:19 -0800
                                      Re: How to get an address for a string by direct user input without using PAD humptydumpty <ouatubi@gmail.com> - 2014-02-19 11:41 -0800
                                        Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-19 16:24 -0800
                                          Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-19 23:08 -0800
                                            Re: How to get an address for a string by direct user input without using PAD Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-20 13:11 +0000
                                              Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-20 21:10 -0800
                                                Re: How to get an address for a string by direct user input without using PAD humptydumpty <ouatubi@gmail.com> - 2014-02-20 22:42 -0800
                                                  Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-21 22:16 -0800
                                          Re: How to get an address for a string by direct user input without using PAD humptydumpty <ouatubi@gmail.com> - 2014-02-20 12:04 -0800
                                  Re: How to get an address for a string by direct user input without using PAD Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-19 07:45 +0000
                                    Re: How to get an address for a string by direct user input without using PAD albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-19 20:10 +0000
                                      Re: How to get an address for a string by direct user input without using PAD Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-19 22:25 +0000
                                        Re: How to get an address for a string by direct user input without using PAD albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-20 12:10 +0000
                                          Re: How to get an address for a string by direct user input without using PAD Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-20 13:10 +0000
                                            Re: How to get an address for a string by direct user input without using PAD albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-20 17:11 +0000
                Re: How to get an address for a string by direct user input without using PAD "Elizabeth D. Rather" <erather@forth.com> - 2014-02-15 16:34 -1000
                  Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-15 19:06 -0800
                    Re: How to get an address for a string by direct user input without using PAD henry.lenzi@gmail.com - 2014-02-15 19:22 -0800
              Re: How to get an address for a string by direct user input without using PAD "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-13 02:56 -0500
                Re: How to get an address for a string by direct user input without using PAD "Elizabeth D. Rather" <erather@forth.com> - 2014-02-12 22:13 -1000
                  Re: How to get an address for a string by direct user input without using PAD anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 08:56 +0000
                    Re: How to get an address for a string by direct user input without using PAD albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-13 11:57 +0000
            Re: How to get an address for a string by direct user input without using PAD "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-13 02:56 -0500
        Re: How to get an address for a string by direct user input without using PAD albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-12 14:56 +0000
          Re: How to get an address for a string by direct user input without using PAD mhx@iae.nl - 2014-02-12 11:24 -0800
          Re: How to get an address for a string by direct user input without using PAD henry.lenzi@gmail.com - 2014-02-12 15:48 -0800
            Re: How to get an address for a string by direct user input without using PAD Paul Rubin <no.email@nospam.invalid> - 2014-02-12 16:18 -0800
              Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-12 17:39 -0800
            Re: How to get an address for a string by direct user input without using PAD Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-13 01:41 +0100
              Re: How to get an address for a string by direct user input without using PAD Hank Lenzi <henry.lenzi@gmail.com> - 2014-02-12 17:25 -0800
                Re: How to get an address for a string by direct user input without using PAD Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-14 01:25 +0100
                  Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-13 17:03 -0800
                    Re: How to get an address for a string by direct user input without using PAD albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-14 02:41 +0000
            Re: How to get an address for a string by direct user input without using PAD stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-13 12:40 +0000
      Re: How to get an address for a string by direct user input without using PAD henry.lenzi@gmail.com - 2014-02-11 17:41 -0800
    Re: How to get an address for a string by direct user input without using PAD Mark Wills <markrobertwills@yahoo.co.uk> - 2014-02-10 02:32 -0800
      Re: How to get an address for a string by direct user input without using PAD henry.lenzi@gmail.com - 2014-02-11 17:23 -0800
      Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-13 15:49 -0800
    Re: How to get an address for a string by direct user input without using PAD Julian Fondren <julian.fondren@gmail.com> - 2014-02-12 20:50 -0800
      Re: How to get an address for a string by direct user input without using PAD hank.lenzi@gmail.com - 2014-02-13 16:38 -0800
    Re: How to get an address for a string by direct user input without using PAD hughaguilar96@yahoo.com - 2014-02-15 19:20 -0800
      Re: How to get an address for a string by direct user input without using PAD henry.lenzi@gmail.com - 2014-02-15 19:23 -0800

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#28274 — How to get an address for a string by direct user input without using PAD

Hello --

If you use PAD for input, you keep getting the same address for the user string input. OTOH, S" <STRING>" will generate a new memory address each time, as you know, and a count information.

How can I avoid PAD's always-the-same address? Is there some sort of hack with HERE?

My problem is this: where we work, I use software for our patient's prescriptions. I have words, like CAPT25 30CP 1XD (each one is a FORTH word) which expand to "Captopril 25mg ---------- 30 pills" and then on the new line "Take one pill P.O. 1x/day". 

I would like user input to be parsed. One word at a time, producing the address and the string count, which will be thrown on a matrix. Later on, I can use EVALUATE to "expand", provided I have the address and the string size stored on the matrix. I would also do some sort of exception handling (CATCH/THROW), in order to check the user has provided the correct syntax (say, makes the mistake CAPTO25, instead of CAPT25).

The problem is, with direct user input using PAD, I can never get 3 diferent address and 3 different string sizes on the stack. This severely hampers the possibility of using some sort of DO LOOP that would produce different addresses and count information for a user specified number of times.

I hope to use the matrix not only to expand the word with evaluate, but also do some statistical book keeping, such as finding out which words are most frequently used, etc.

TIA,
Hank Lenzi

[toc] | [next] | [standalone]

#28278

In article <153253e8-4cb9-4438-8357-9dd8872388a4@googlegroups.com>,
 <hank.lenzi@gmail.com> wrote:
>Hello --
>
>If you use PAD for input, you keep getting the same address for the user
>string input. OTOH, S" <STRING>" will generate a new memory address each
>time, as you know, and a count information.
>
>How can I avoid PAD's always-the-same address? Is there some sort of
>hack with HERE?
>
>My problem is this: where we work, I use software for our patient's
>prescriptions. I have words, like CAPT25 30CP 1XD (each one is a FORTH
>word) which expand to "Captopril 25mg ---------- 30 pills" and then on
>the new line "Take one pill P.O. 1x/day".
>
>I would like user input to be parsed. One word at a time, producing the
>address and the string count, which will be thrown on a matrix. Later
>on, I can use EVALUATE to "expand", provided I have the address and the
>string size stored on the matrix. I would also do some sort of exception
>handling (CATCH/THROW), in order to check the user has provided the
>correct syntax (say, makes the mistake CAPTO25, instead of CAPT25).
>
>The problem is, with direct user input using PAD, I can never get 3
>diferent address and 3 different string sizes on the stack. This
>severely hampers the possibility of using some sort of DO LOOP that
>would produce different addresses and count information for a user
>specified number of times.
>
>I hope to use the matrix not only to expand the word with evaluate, but
>also do some statistical book keeping, such as finding out which words
>are most frequently used, etc.

Your problem is temporary versus permanent strings, not where it is
stored.
If you don't want to think about strings, but just use them,
 use a Forth that accomodates strings like ciforth.
There may be
It was one of the major design points, but is not standard.

"ASJLKAJSDLASDJL" : a permanent string that can be TYPE d.
(ACCEPT)        : get a temporary string that you can make permanent
 by `` $, $@ ''
: make-permanent   $, $@ ;
Most of the time you will keep the pointer returned by $,

The following code was run on ciforth.
\ -------------------8<----------------------------------
CREATE recipee 10 CELLS ALLOT
: fill-recipees 10 0 DO
   "Dear user, give me recipee #" TYPE I . CR
   (ACCEPT) $, recipee I CELLS + !
  LOOP ;

\ Show recipee NUMBER ( d -- )
: show-recipee
   CELLS recipee + @
   $@ TYPE  ( or $? )
;
\ -------------------8<----------------------------------

Disadvantage: after the user types 2G word of recipees,
Forth will crash.

The standard way is to use ALLOCATE which is the equivalent of
malloc() in C and an equally great pain in the ass.

>
>TIA,
>Hank Lenzi
-- 
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]

#28289

On Sunday, February 9, 2014 5:18:27 AM UTC-7, Albert van der Horst wrote:
> Your problem is temporary versus permanent strings, not where it is
> stored.
> If you don't want to think about strings, but just use them,
>  use a Forth that accomodates strings like ciforth.
> ...
> It was one of the major design points, but is not standard.

The remarkable thing about my novice package, is that I made it ANS-Forth compliant, so it will compile and run under any ANS-Forth system. If I want to abandon ANS-Forth (which I am with my language that I'm developing), then Forth becomes easy. Getting software to work under ANS-Forth is like getting a bear to write a bicycle; it is not easy --- my whole novice package is a complicated series of work-arounds for ANS-Forth failures (and bugs in ANS-Forth compilers such as SwiftForth and Win32Forth).

Albert: I think you should really just stick to being a Wikipedia editor --- that is more your speed.

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

#28394

> The remarkable thing about my novice package, is that I made it ANS-Forth compliant, so it will compile and run under any ANS-Forth system. If I want to abandon ANS-Forth (which I am with my language that I'm developing), then Forth becomes easy. Getting software to work under ANS-Forth is like getting a bear to write a bicycle; it is not easy --- my whole novice package is a complicated series of work-arounds for ANS-Forth failures (and bugs in ANS-Forth compilers such as SwiftForth and Win32Forth).
> 
 I though this package was very interesting. I wish I understood the :NAMES examples more. Also, I had to ask explicitly for the floating point package in SwiftForth in order for it to compile.

 - Hank Lenzi

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

#28279

hank.lenzi@gmail.com writes:
>Hello --
>
>If you use PAD for input, you keep getting the same address for the user st=
>ring input. OTOH, S" <STRING>" will generate a new memory address each time=
>, as you know, and a count information.

Whether intepretive S" generates a new address each time depends on
the system.  Gforth does so, and has done so for some time, but early
versions just used one buffer, and you always got the same address.

If you get the input in a temporary buffer (like S" does), you can do
the same thing as Gforth's S" does: ALLOCATE the memory for the string
and copy it from the temporary buffer to the ALLOCATEd buffer.  Gforth
has a word for this:

save-string ( c-addr1 u -- c-addr2 u )

- 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 2013: http://www.euroforth.org/ef13/

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

#28280

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
Gforth
>has a word for this:
>
>save-string ( c-addr1 u -- c-addr2 u )

Actually the name is SAVE-MEM (it works for any memory block, not just
strings).

- 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 2013: http://www.euroforth.org/ef13/

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

#28282

On Saturday, February 8, 2014 8:26:16 PM UTC-6, hank....@gmail.com wrote:
> Hello --

Hi.

> 
> If you use PAD for input, you keep getting the same address for the user string input. OTOH, S" <STRING>" will generate a new memory address each time, as you know, and a count information.
> 

OK, so you have a program, you're currently receiving input to PAD, and you
would like to not forget prior input when you receive more input.

You've already been given two ways to do that, but I think you may have missed
them.  There are in general three ways to do this:

1. Copy the input to some ALLOCATEd memory.

2. Copy the input to some ALLOT'd memory, or to part of some other fixed
generic buffer.

3. Copy the input to specific memory -- for instance, if you had a
'prescription' data structure that included space for the name of the medicine
as well as the dosage of the medicine and the like, you could copy the input to
the appropriate section of the data structure.

Thinking about #3 and your input routines for a bit may reveal a fourth way:

4. Rather than accepting input to PAD and then copying it somewhere, just
accept input directly into the relevant part of the data structure.  When you
get around to asking for interesting side-effects, you can use the 'interesting
side-effects' buffer for your input, instead of PAD.

An obvious factor of options #1 through #3 is a word that does the copying.
Forth provides this with MOVE ( source destination size -- )

A more useful factor for #1 and #2 might be a word with MOVE's exact arguments,
but which returned the resulting string.  This is pretty straightforward, since
( destination size ) is exactly what you want:

: SAVE ( c-addr1 c-addr2 u -- c-addr2 u )
  2dup 2>r MOVE 2r> ;

But maybe you'd rather have these arguments:

: SAVE-INTO ( c-addr1 u c-addr2 -- c-addr2 u )
  SWAP SAVE ;

Which would allow you write words like this:

: ALLOCATED ( u -- u c-addr )
  dup allocate throw ;
: ALLOTED ( u -- u c-addr )
  here >r dup allot r> ;
\ ^ there's your HERE trick :)

: save-mem ( c-addr1 u -- c-addr2 u )
  allocated save-into ;

: save-buf ( c-addr1 u -- c-addr2 u )
  alloted save-into ;

So after you receive your input, just save it and go on to receive more.


I don't recommend doing this:

CREATE HEAP

: SAVE-INTO ( c-addr1 u HERE/HEAP -- c-addr2 u )
  dup HERE = if drop alloted swap save exit then
      HEAP = if allocated swap save exit then
  true abort" I don't know how to save into that :-(" ;

... because that's pretty silly.

> TIA,
> 
> Hank Lenzi

Hope that helped.

Julian

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

#28315

> Hope that helped.

> Julian

It sure did, Julian, thanks so much. 
I was strugling a bit with memory allocation, to be frank.
Thanks to everyone, BTW, for the nice help.

Hank Lenzi

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

#28316

> Hope that helped.

> Julian

It sure did, Julian, thanks so much. 
I was strugling a bit with memory allocation, to be frank.
Thanks to everyone, BTW, for the nice help.

Hank Lenzi

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

#28283

On 2/8/14 4:26 PM, hank.lenzi@gmail.com wrote:
> Hello --
>
> If you use PAD for input, you keep getting the same address for the user string input. OTOH, S" <STRING>" will generate a new memory address each time, as you know, and a count information.
>
> How can I avoid PAD's always-the-same address? Is there some sort of hack with HERE?
>
> My problem is this: where we work, I use software for our patient's prescriptions. I have words, like CAPT25 30CP 1XD (each one is a FORTH word) which expand to "Captopril 25mg ---------- 30 pills" and then on the new line "Take one pill P.O. 1x/day".
>
> I would like user input to be parsed. One word at a time, producing the address and the string count, which will be thrown on a matrix. Later on, I can use EVALUATE to "expand", provided I have the address and the string size stored on the matrix. I would also do some sort of exception handling (CATCH/THROW), in order to check the user has provided the correct syntax (say, makes the mistake CAPTO25, instead of CAPT25).
>
> The problem is, with direct user input using PAD, I can never get 3 diferent address and 3 different string sizes on the stack. This severely hampers the possibility of using some sort of DO LOOP that would produce different addresses and count information for a user specified number of times.
>
> I hope to use the matrix not only to expand the word with evaluate, but also do some statistical book keeping, such as finding out which words are most frequently used, etc.

In addition to the other suggestions people have given, my thought is to 
process each piece as you get it, rather than wait till you have all 
three. Maybe you can only do preliminary processing, and save the 
results somewhere, each being in a different place.

I don't know if the "3" you mentioned is a representative number or a 
stable component of the design -- if you know how many sub-strings 
you're going to want, you can ALLOT or ALLOCATE that many buffers and 
parse the successive pieces of information into those buffers, and then 
continue with your analysis.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#28286

On Sunday, February 9, 2014 11:47:22 AM UTC-7, Elizabeth D. Rather wrote:
> In addition to the other suggestions people have given, my thought is to 
> process each piece as you get it, rather than wait till you have all 
> three. Maybe you can only do preliminary processing, and save the 
> results somewhere, each being in a different place.
> 
> I don't know if the "3" you mentioned is a representative number or a 
> stable component of the design -- if you know how many sub-strings 
> you're going to want, you can ALLOT or ALLOCATE that many buffers and 
> parse the successive pieces of information into those buffers, and then 
> continue with your analysis.

There is no need to contort your code like this. It is not robust. This is just more bad advice from a non-programmer.

Just use my novice package: http://www.forth.org/novice.html
It automatically provides memory for strings in a circular buffer. I also have an upgrade that allows for strings larger than 255 chars, but haven't included it in the novice package yet --- you can find it here: 
https://groups.google.com/forum/#!topic/comp.lang.forth/3Y4w_MdYl0k

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

#28291

On Sunday, February 9, 2014 8:13:00 PM UTC-6, hughag...@yahoo.com wrote:
> There is no need to contort your code like this. It is not robust. This is 
just more bad advice from a non-programmer.
> 

Suppose you're writing little Unix filter to sum up the numbers in
a column.  You know how to receive a line of input.  You know how
to turn a line of input into a number.  Your first thought may be
to receive all of the lines, dumping them to the stack, to then
process them:

: SUM ( 0 a1 u1 ... aN uN -- u )
  0 >r BEGIN dup WHILE
    to-number r> + >r
  REPEAT drop r> ;

But wait!  Your input routine uses PAD for input!  So all of your
lines are the same, and instead of adding up the column you just
multiply the last value in the column by the number of rows.  What
a terrible mistake!

One way to fix this is to ALLOCATE a few thousand strings.
That'll work OK.

I guess you could also process the input line by line:

VARIABLE sum

: summer ( -- )  \ throws exception on end of input
  BEGIN get-line to-number sum +! AGAIN ;

But yeah, that's obviously stupid.  What kind of a person would
ever step back from a problem to even consider if the result could
be arrived at in some other way?  Not any kind of programmer,
that's for sure!

> Just use my novice package: http://www.forth.org/novice.html
> 
> It automatically provides memory for strings in a circular buffer. I also have an upgrade that allows for strings larger than 255 chars, but haven't included it in the novice package yet --- you can find it here: 
> 
> https://groups.google.com/forum/#!topic/comp.lang.forth/3Y4w_MdYl0k

The actual relevant words from this package are:

ALLOC  ( size -- adr )
  which is just ALLOCATE THROW with its own error message instead
of your system's error message.

<HSTR> ( adr cnt -- hstr )
  which is identical to SAVE-MEM apart from returning a counted
string and making use of ALLOC

HSTR ( str -- hstr )
  which accepts a counted string.  It's just COUNT <HSTR>

The circular buffer he's talking about relates to some
string-formation words that probably aren't directly useful.

By the way, my earlier word:

: ALLOTED ( u -- u c-addr )
  here >r dup allot r> ;

Is much better written as:

: ALLOTED ( u -- u c-addr )
  here over allot ;

And ,STR from that novice package:

: ,str ( adr cnt -- )
    here >r  dup char+ allot
    dup r@ c!
    r> char+ swap cmove> ;

Is better written as:

: ,str ( adr cnt -- )
  dup c, here swap move ;

With which you can define SAVE-BUF (for u<256):

: SAVE-BUF ( c-addr u -- c-addr2 u )
  here -rot ,str count ;

Which I would tend to write as:

: SAVE-BUF ( c-addr u -- c-addr2 u )
  here >r ,str r> count ;

If you reach too quickly for >R you can arrive at a solution that
looks optimal.


Julian

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

#28417

On Monday, February 10, 2014 3:27:08 AM UTC-7, Julian Fondren wrote:
> And ,STR from that novice package:
> 
> : ,str ( adr cnt -- )
>     here >r  dup char+ allot
>     dup r@ c!
>     r> char+ swap cmove> ;
> 
> Is better written as:
> 
> : ,str ( adr cnt -- )
>   dup c, here swap move ;

This is baloney --- you aren't allotting any memory in the dictionary for your string, so the next thing you compile will overwrite it. 

You aren't testing your code at all before you post it on comp.lang.forth. I doubt that you have spent more than 5 minutes studying my novice package, and you only did that with the intention of attacking it --- you don't know what you are talking about.

I skimmed over your post and it was all baloney --- I won't bother to go through it line-by-line --- you are wasting everybody's time.

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

#28539

On Friday, February 14, 2014 3:20:10 AM UTC-6, hughag...@yahoo.com wrote:
> On Monday, February 10, 2014 3:27:08 AM UTC-7, Julian Fondren wrote:
> 
> > : ,str ( adr cnt -- )
> 
> >     here >r  dup char+ allot
> 
> >     dup r@ c!
> 
> >     r> char+ swap cmove> ;
> 
> > 
> 
> > Is better written as:
> 
> > 
> 
> > : ,str ( adr cnt -- )
> 
> >   dup c, here swap move ;
> 
> 
> 
> This is baloney --- you aren't allotting any memory in the dictionary for your string, so the next thing you compile will overwrite it. 
> 

Yes, it obviously needs a DUP ALLOT

Usenet doesn't allow me to correct minor errors, so I don't correct them.

Is it still baloney that

: str, ( adr cnt -- )
  dup c,  here swap  dup allot  move ;

reads better than the return-stack version?
 
> 
> I doubt that you have spent more than 5 minutes studying my novice package, 
> 

If I spent more than 5 minutes studying your novice package, I'd be compelled to rewrite it without all the gratuitous words like

: w cell ;
: blah, postpone blah ; immediate
swiftforth? [if] code -rot ... end-code

You know, for the good of humanity.  You flame Rather for not discussing linked lists (how dare FAT have a Forth multitasking chapter instead?!) and then, instead of saying "hey, here's how you do linked lists in Forth" in an approachable fashion, you hide it under among the noise of your novice package.  How many minutes do you think anyone would need to understand linked lists?  Anyway, five minutes was plenty enough to dismiss the direct utility of your <CSTR words and to identify HSTR and friends as potentially useful if already discussed, which is all that I did.

Also, the FFL copy in that github is quite old.  Contributing to FFL is quite easy; just send a patch.  FFL does have a painfully humble, unimposing naming system.  It's easy enough to use your own names in your own code.  At least loading an FFL library doesn't result in pages of redefinition warnings for core words.

Also, speaking of books and linked lists.  I've just received Forth Applications: Ready to run programs in Forth (sub-subtitle: Data Structures * Artificial Intelligence Utilities * Recursion Procedures * Small Business Programs, Graphics, Games).

Chapter 4 has linked lists.  This is the first bit of code in this chapter:

: (>LST) @PA
  BEGIN @PTRS COMP DUP 0=
    IF ." ALREADY IN LIST" DROP 0 1
    ELSE 0<
      IF PJR @ 0=
        IF ( NEW ELEMENT IS LARGEST )
          0 !NPR @N PJ @ !PR PJ @ !NPL 1 1
        ELSE ( CONTINUE SEARCH ) PJR @ 0
        THEN
      ELSE PJL @ 0=
        IF ( NEW ELEMENT IS SMALLEST )
          0 !NPL @PA !NPR @N DUP @PA !PL !PA 1 1
        ELSE ( SORTING IN )
          PJ @ @PL !NPL PJL @ @PR !NPR
          @N PJL @ !PR @N PJ @ !PL 1 1 
        THEN
      THEN
    THEN
   UNTIL IF !MEM THEN ;

I wish I could've seen a few of the faces of people who spotted this book, wondered what Forth was, and then flipped it open to the data structures chapter.

It's a pretty good title, subtitle, and sub-subtitle, though.  Would anyone like to write a modern book to go with it?


-- Julian

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

#28555

On Tuesday, February 18, 2014 3:14:52 PM UTC-7, Julian Fondren wrote:
> If I spent more than 5 minutes studying your novice package, I'd be compelled to rewrite it without all the gratuitous words like
> 
> : w cell ;

That is not my code. Also, CELL is not ANS-Forth anyway. You're making things up again, and not testing the code that you post.
 
> : blah, postpone blah ; immediate

These make the code much more readable, as compared to a series of POSTPONE xxx --- important for somebody who writes a lot of meta-compilation words.

Also, these can be given to POSTPONE, where as POSTPONE xxx can't be given directly to POSTPONE, so these allow for meta-compilation of meta-compilation words. An example is FIELD --- one of the most important words in the novice package.

I don't like these either. In my own language, all of these will get generated automatically by the compiler --- it will not be necessary to hand-write them, which is rather tedious. But, this is ANS-Forth --- the whole novice package is a collection of work-arounds for ANS-Forth problems, and this is one of them.

> swiftforth? [if] code -rot ... end-code

This is not my code --- you're making things up again.

You have spent maybe 5 minutes studying the novice package, and you only did that so you could attack it. You make up quite a lot (generally known as "lying"), which is what I was referring to previously when I said that truth is not an issue for a troll --- your whole purpose is to poison the minds of people like Hank with the idea that my novice package is full of bugs.

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

#28579

On Tuesday, February 18, 2014 10:11:17 PM UTC-6, hughag...@yahoo.com wrote:
> On Tuesday, February 18, 2014 3:14:52 PM UTC-7, Julian Fondren wrote:
> 
> > all the gratuitous words like
> >
> > : w cell ;
> 
> That is not my code.
>

No, but that's your ugly word, which is ugly however it's implemented, because it's ugly every time you use it.

> Also, CELL is not ANS-Forth anyway.

Yes, that's true.  Fortunately ANS Forth comes with several ways to create new words...

> > : blah, postpone blah ; immediate
> 
> These make the code much more readable, as compared to a series of POSTPONE xxx --- important for somebody who writes a lot of meta-compilation words.
> 

Meh.  POSTPONE does good work as a programmer's gargoyle.  This isn't pretty:

: ?FAIL ( 0 -- ) ( x -- x )
  POSTPONE dup POSTPONE 0= POSTPONE if POSTPONE drop POSTPONE exit POSTPONE then
; immediate

But how pretty should it be?  Maybe while typing all of those POSTPONEs you can think about whether your novel control flow structure is going to be readable when actually used, elsewhere in your program.

Go and compare the Forth and Factor entries to RosettaCode's four-way-if task.  Forth's entry has some ugly POSTPONEs.  Factor uses pretty code quotations.  Forth's example that makes use of its new control flow structure is actually extremely readable.  Factor's example that makes use of its new control flow structure is three tests, four code quotations, and then the control-flow word.

Also, I don't expect that a rewrite of novice.4th without these words will instead have a ton of POSTPONEs.  I expect that a rewrite also wouldn't need the POSTPONEs.

> 
> > swiftforth? [if] code -rot ... end-code
> 
> This is not my code
>

It isn't.  But novice.4th does reimplement -ROT and it does have a lot of unnecessary CODED words and it does run a lot of this only under SwiftForth.  I feel as if the code strongly suggests all of this, in code.

> 
> your whole purpose is to poison the minds of people like Hank with the idea that my novice package is full of bugs.

And you'll never stop me!  Ha ha ha ha ha!  See what a clever super-villain I am, that I can suggest that your code is full of bugs without ever pointing to any bug in it?  By never doing so, I superbly cloak my whole purpose in life.
Cassandra may pity you, but I don't.


-- Julian

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

#28556

On Tuesday, February 18, 2014 3:14:52 PM UTC-7, Julian Fondren wrote:
> If I spent more than 5 minutes studying your novice package, I'd be compelled to rewrite it without all the gratuitous words like
> : blah, postpone blah ; immediate

Those words aren't IMMEDIATE --- that is something else that you are making up.

Do you even know what POSTPONE does?

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

#28302

On Sun, 09 Feb 2014 18:13:00 -0800, hughaguilar96 wrote:

>
> There is no need to contort your code like this. It is not robust. This
> is just more bad advice from a non-programmer.
> 

The history of Forth, Inc. puts Ms Rather as the programmer with the 
earliest experience in programming/using/teaching Forth, other than the 
creater, Charles Moore.

If one must criticize another, perhaps facts would be best employed.

Steve

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

#28419

On Monday, February 10, 2014 12:29:06 PM UTC-7, Steve wrote:
> On Sun, 09 Feb 2014 18:13:00 -0800, hughaguilar96 wrote:
> 
> > There is no need to contort your code like this. It is not robust. This
> > is just more bad advice from a non-programmer.
 
> The history of Forth, Inc. puts Ms Rather as the programmer with the 
> earliest experience in programming/using/teaching Forth, other than the 
> creater, Charles Moore.
> 
> If one must criticize another, perhaps facts would be best employed.

Well, you have obviously been reading the Forth Inc. website (http://www.forth.com/resources/evolution/index.html). This is what it says:
"Elizabeth Rather is the co-founder of FORTH, Inc. and is a leading expert in the Forth programming language. Elizabeth was a colleague of Chuck Moore back when he worked at NRAO in the early 1970s. During his development of Forth, she became the second ever Forth programmer. Since then, she has become a leading expert in the language and one of its main proponents. Elizabeth was the chair of the ANSI Technical Committee that produced the ANSI Standard for Forth (1994).  She is an author of several books on Forth and gives regular training seminars on its usage."

She wrote that herself, you dope! She is a salesperson --- salespeople always describe themselves as the world expert on whatever they are selling --- this is always baloney.

I know that Elizabeth Rather is a non-programmer because she doesn't believe that code can be reusable. She says, for example, that in my novice package the data-structures only work for specific records. That is not true. She really doesn't understand the concept of a data structure (linked lists, LLRB trees, etc.) being able to be used for any data type without having to be rewritten specifically for that data type. None of her books describe the implementation of linked lists or any other data type (except a crude implementation of an array in "Starting Forth" that only works for single-cell data). She wants everybody to write every program totally from scratch --- this is bad advice from a non-programmer. The only code that she has ever posted on comp.lang.forth was taken straight out of the "Starting Forth" book (STARS seems to be her favorite) --- I don't think she knows anything about Forth beyond what is in "Starting Forth," which is the basis for her class on Forth at Forth Inc..

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

#28318

Em segunda-feira, 10 de fevereiro de 2014 00h13min00s UTC-2, hughag...@yahoo.com  escreveu:
> On Sunday, February 9, 2014 11:47:22 AM UTC-7, Elizabeth D. Rather wrote:
> 
> > In addition to the other suggestions people have given, my thought is to 
> 
> > process each piece as you get it, rather than wait till you have all 
> 
> > three. Maybe you can only do preliminary processing, and save the 
> 
> > results somewhere, each being in a different place.
> 
> > 
> 
> > I don't know if the "3" you mentioned is a representative number or a 
> 
> > stable component of the design -- if you know how many sub-strings 
> 
> > you're going to want, you can ALLOT or ALLOCATE that many buffers and 
> 
> > parse the successive pieces of information into those buffers, and then 
> 
> > continue with your analysis.
> 
> 
> 
> There is no need to contort your code like this. It is not robust. This is just more bad advice from a non-programmer.
> 
> 
> 
> Just use my novice package: http://www.forth.org/novice.html
> 
> It automatically provides memory for strings in a circular buffer. I also have an upgrade that allows for strings larger than 255 chars, but haven't included it in the novice package yet --- you can find it here: 
> 
> https://groups.google.com/forum/#!topic/comp.lang.forth/3Y4w_MdYl0k

Yet again, a *ton* of advice for the Forth newbie!
You guys, as a Usenet newsgroup are *so* good!
Thanks!

Hank Lenzi

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

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

csiph-web