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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#28550

In article <f2ed5b12-6c7b-459c-9415-6038f64252d3@googlegroups.com>,
 <hank.lenzi@gmail.com> wrote:
>On Tuesday, February 18, 2014 7:48:12 PM UTC-3, Julian Fondren wrote:
>> On Monday, February 17, 2014 9:54:16 PM UTC-6, hank....@gmail.com wrote:
>>
>> >  Yes, very nice! (although, I wish it was BSDed or LGPLed).
>>
>>
>>
>> The Forth Foundation Library is LGPLed, actually, as noted under
>License at http://code.google.com/p/ffl/
>
> Oh, my bad! Well, that's good news! However, the page says it's LGPLed
>"since version 0.9.0", but this version isn't actually on the Download
>link they provide.
>
>>
>> SAVE-MEM ( caddr1 u -- caddr2 u ) is a word that replaces the string
>at the top of the stack with an ALLOCATEd string that has the same data
>and length.
>>
>
> Yes. It's just that I thought REFILL could capture a "whole" line of my
>"medication (forth) words".
>
> Let me see if I expand on what I was thinking in a clear way: I thought
>REFILL would capture, e.g., "CAPT25 30P 1PD" (all valid words in my
>software), as a whole *line*.

The word you're looking for is ACCEPT, in older Forth's EXPECT.
It waits until the user has completed a line.

CREATE MY-BUFFER 80 ALLOT
MY-BUFFER DUP 80 ACCEPT    ( -- address u)

If your system has a file descriptor 0 for standard input, it is almost
the same than
MY-BUFFER DUP 80  0 READ-FILE THROW
"get me at most 80 characters to MY-BUFFER from the input stream."

[ REFILL is used by the system to get the next line to compile (or interpret).
It is used internally by WORD as per:
"Gosh, nothing on this line. Let's get another one before parsing a word."

REFILL is a somewhat obscure word. You don't need it. ciforth has
  : REFILL FALSE ;
and is doing just fine. ]

<SNIP>

> -- Hank Lenzi
>

I had a similar situation with Python. There you've got to use
    x = input(promptstring)

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]

#28552

On Tuesday, February 18, 2014 10:01:42 PM UTC-3, Albert van der Horst wrote:
 
> The word you're looking for is ACCEPT, in older Forth's EXPECT.
> 
> It waits until the user has completed a line.
> 
> 
> 
> CREATE MY-BUFFER 80 ALLOT
> 
> MY-BUFFER DUP 80 ACCEPT    ( -- address u)
> 
> 
 REFILL does seem kind of obscure...
 : NEW13 \ Bugged -- dumps thing correctly at the stack, but botches nodes (nodes  :6 0 6 4 4)
 	 \ Also, has the "27 bug": 32 135910720 27 51 135910976 27 32 135910736 27 <-Top  ok
 	 \ Writes garbage 
 	 \ .s
         \ 32 135910720 27 51 135910976 27 32 135910736 27 <-Top  ok
         \ drop swap type 1cpdc÷~}¿ÁˆD e c    
          CR ." Write a word and press <ENTER> " 
          CR ." When finished press <ESC>" 
          CR ." To erase the whole line press <ESC> (if did not <ENTER>)" CR  
          BEGIN EKEY? IF EKEY DUP 27 = IF EXIT 
        	ELSE 
        		MY-BUFFER DUP 80 ACCEPT    ( -- address u) 
        		SAVE-MEM 
        		LIST SCL-APPEND 
         	THEN
        THEN AGAIN ;  

 I *still* get garbage (as in the "drop swap type 1cpdc÷~}¿ÁˆD e c" above).
 Something is corrupting memory...No idea what. Humptydumpty suggest one thing (the EKEY) and Eoisabeth Rather suggest another. I'm lost.

 At least, you got me to see that, no, in fact, I do not need REFILL.

 Thanks, Albert!

 -- Hank Lenzi

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

#28553

This version gets thing to the linked list, has the problem of the code for ESC being written to the linked-list, and still writes gibberish alongside the saved stuff:

: NEW11  \ This doesn't have the "27 problem"
	       \ Output is still "dirty", with garbage alongside the input
          CR ." Write a word and press <ENTER> " 
          CR ." When finished press <ESC>" 
          CR ." To erase the whole line press <ESC> (if did not <ENTER>)" CR  
          begin ekey? if ekey dup 27 = if SAVE-MEM LIST SCL-APPEND ( drop  ) exit \ 
          else refill drop 1 word  
          then  
          then again ; 
 

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

#28587

On Wednesday, February 19, 2014 4:19:47 AM UTC+2, hank....@gmail.com wrote:
> This version gets thing to the linked list, has the problem of the code for ESC being written to the linked-list, and still writes gibberish alongside the saved stuff:
> 
> 
> 
> : NEW11  \ This doesn't have the "27 problem"
> 
> 	       \ Output is still "dirty", with garbage alongside the input
> 
>           CR ." Write a word and press <ENTER> " 
> 
>           CR ." When finished press <ESC>" 
> 
>           CR ." To erase the whole line press <ESC> (if did not <ENTER>)" CR  
> 
>           begin ekey? if ekey dup 27 = if SAVE-MEM LIST SCL-APPEND ( drop  ) exit \ 
> 
>           else refill drop 1 word  
> 
>           then  
> 
>           then again ;

Hi!

First thing go:
http://www.forth.org/literature.html
Then enter HTML link or download zipped html source.
At bottom go annex F ( http://www.taygeta.com/forth/dpansf.htm )
Now you'll have a list of forth-words to search for meaning.

Ok. Let's analyze your last version, after a convenient formatting.
For every forth-word go annex F and search for stack-effect and meaning.

: NEW11    
BEGIN
        ekey?   ( flag ; keyboard event is available or not ) 
        IF      ( ok, key pressed )
                ekey    ( key ; our key that pressed )
                dup     ( key key ; )
                27 =    ( key flag ; is esc pressed? )
                IF      ( 27 )
                        \ SAVE-MEM ( caddr1 u -- caddr2 u )
                        \ require pair 'caddr1 u' on stack
                        \ but we have whatever was on stack before NEW11
                        \ let name it garb-address
                        \ so on stack is ( garb-address 27 ) 
                        SAVE-MEM     ( heap-addr 27 ; garbage saved on heap )
                        LIST         ( heap-addr 27 list-addr )
                        \ Looking into FFL:
                        \ scl-append ( x scl -- = Append the cell data x in the list )
                        \ will append key=27 to linked list
                        SCL-APPEND   ( heap-addr )
                        ( drop  )
                        EXIT ( heap-addr )
                ELSE    ( key )
                        refill  ( key flag ; readed next line from file? )
                        drop    ( key )
                        \ From dpans:
                        \ counted-string-addr is the address of a transient
                        \ region containing the parsed word as a counted string.
                        1 word  ( key counted-string-addr ) 
                THEN
                \ Now counted-string-addr became garb-address
                \ for next round of loop   
        THEN
AGAIN
;

Maybe the mystery begin to reveal ...

First thing:
Scl-append will apend only one cell to list.
You cannot pass counted-string-addr because is a transient region.
You must save string from counted-string-addr to heap version of counted
string.

Second:
You must re-think input-loop to do what you really want
and have a balanced stack effect.

Don't be afraid, patience will be rewarded. :-)

Have a nice day,
humptydumpty

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

#28591

 
> Maybe the mystery begin to reveal ...
> 
(...)  Yes!
> 
> Don't be afraid, patience will be rewarded. :-)

 Thanks for showing me a little light!
 It's late, after day's work. I'll have to meditate on these pearls fo knowledge I have just received!
 What can I say! It's been quite a ride! Forth is *amazing*! The little things...the fixing of code...the immediate testing...the *different* ways of doing things... 
> 
> Have a nice day,
> 
> humptydumpty

 You too, humptydumpty!(if it's daytime in your timezone, may it be a *good* day to you!)

 -- Hank Lenzi

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

#28594

On Wednesday, February 19, 2014 5:24:10 PM UTC-7, hank....@gmail.com wrote:
> > Don't be afraid, patience will be rewarded. :-)
> 
>  Thanks for showing me a little light!
> 
>  It's late, after day's work. I'll have to meditate on these pearls fo knowledge I have just received!

Most of what you have received haven't been "pearls of knowledge" --- more like: "t***s of ignorance."

What you are trying to do is actually super-simple. I don't want to write your program for you, as you have to write it yourself to learn --- but you're letting people convince you that it is much more difficult than it is (REFILL ?!).

In LIST.4TH I have a word called READ-SEQ that takes the name of a file and returns a SEQ list (a list in which each node contains one field which is a string). How easy is that? As I said before, if the lines are comma-delimited then you can convert each node of the SEQ into a SEQ, so you have a list of lists. Also, as I said before, you can use ASSOCIATION.4TH to associate your codes with the readable strings that they represent. I really don't know how I could have possibly made this any easier.

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

#28605

On 20/02/2014 07:08, hughaguilar96@yahoo.com wrote:
> On Wednesday, February 19, 2014 5:24:10 PM UTC-7, hank....@gmail.com wrote:
>>> Don't be afraid, patience will be rewarded. :-)
>>
>>   Thanks for showing me a little light!
>>
>>   It's late, after day's work. I'll have to meditate on these pearls fo knowledge I have just received!
>
> Most of what you have received haven't been "pearls of knowledge" --- more like: "t***s of ignorance."
>
> What you are trying to do is actually super-simple. I don't want to write your program for you, as you have to write it yourself to learn --- but you're letting people convince you that it is much more difficult than it is (REFILL ?!).

I suppose this is a reference to me. For the record I'm not trying to 
persuade the OP to use REFILL, he asked a question in another discussion 
and I simply answered that question and one thing included the use of 
REFILL. I don't care whether he uses REFILL or whether he uses your 
novice package or the FFL - it's up to him. My reponse to Albert was to 
challenge some statements he posted about REFILL and that's because such 
misinformation should not be given to newcomers to Forth.

You are always moaning that nobody ever looks at or uses your novice 
package, here we had a novice who looked at it and wanted to use it but 
couldn't work out how to use it because it lacked documentation. Your 
response amongst other things was to tell him to study your slide rule 
program. So he went away and looked at the FFL which he is now using 
i.e. he is now another counter-example to your previous claims that 
"nobody uses the FFL". A sensible person would learn a lesson from that 
and write some user documentation.

>
> In LIST.4TH I have a word called READ-SEQ that takes the name of a file and returns a SEQ list (a list in which each node contains one field which is a string). How easy is that? As I said before, if the lines are comma-delimited then you can convert each node of the SEQ into a SEQ, so you have a list of lists. Also, as I said before, you can use ASSOCIATION.4TH to associate your codes with the readable strings that they represent. I really don't know how I could have possibly made this any easier.
>

Try writing some documentation with examples e.g. a tutorial.

-- 
Gerry

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

#28637

On Thursday, February 20, 2014 6:11:10 AM UTC-7, Gerry wrote:
> On 20/02/2014 07:08, hughaguilar96@yahoo.com wrote:
> > What you are trying to do is actually super-simple. I don't want to write your program for you, as you have to write it yourself to learn --- but you're letting people convince you that it is much more difficult than it is (REFILL ?!).
> 
> I suppose this is a reference to me. For the record I'm not trying to 
> persuade the OP to use REFILL, he asked a question in another discussion 
> and I simply answered that question and one thing included the use of 
> REFILL. I don't care whether he uses REFILL or whether he uses your 
> novice package or the FFL - it's up to him. My reponse to Albert was to 
> challenge some statements he posted about REFILL and that's because such 
> misinformation should not be given to newcomers to Forth.

This wasn't a reference to you or anybody else. I haven't been reading the discussion very closely, but skimming over it I was amazed to see REFILL being discussed. If you were challenging some statements that Albert posted, I can relate to that --- Albert is a fount of misinformation.

I'm just extremely frustrated with how everything gets blown up into a hugely complicated and confusing mess on comp.lang.forth. Hank wants a "flat database" (your basic sequential text file), but the C.L.F. crowd acts like reading a text file into a linked list has never been done and can only be speculated on. In any other language, this would be a trivial program that even a newbie would accomplish in a day.

I get the impression that most of the C.L.F. crowd enjoy being internet experts, but don't actually write programs. With somebody like Hank who admits to being a newbie, they dribble out their "pearls of knowledge" --- they have no intention of actually helping him though, but they want to drag out the discussion indefinitely, as the discussion is the end not the means (their end being to have the fun of being experts and having somebody look up to them). With somebody like myself who won't admit to being a newbie, they just attack and say that my code "sucks" (and now Albert and Julian have even taken to posting non-working code that they claim to be snippets of my novice package but which they just made up, which is incredibly dishonest even by C.L.F.'s low standards).

I enjoy writing Forth code, and it is easy for me. I don't really understand why the C.L.F. crowd don't feel the same way.

> You are always moaning that nobody ever looks at or uses your novice 
> package, here we had a novice who looked at it and wanted to use it but 
> couldn't work out how to use it because it lacked documentation. Your 
> response amongst other things was to tell him to study your slide rule 
> program. So he went away and looked at the FFL which he is now using 
> i.e. he is now another counter-example to your previous claims that 
> "nobody uses the FFL". A sensible person would learn a lesson from that 
> and write some user documentation.
> 
> > In LIST.4TH I have a word called READ-SEQ that takes the name of a file and returns a SEQ list (a list in which each node contains one field which is a string). How easy is that? As I said before, if the lines are comma-delimited then you can convert each node of the SEQ into a SEQ, so you have a list of lists. Also, as I said before, you can use ASSOCIATION.4TH to associate your codes with the readable strings that they represent. I really don't know how I could have possibly made this any easier.
 
> Try writing some documentation with examples e.g. a tutorial.

I never read tutorials, so I'm an unlikely candidate to write one. How many pages should I devote to explaining READ-SEQ? If I can't face the tedium of writing a tutorial, how could I expect anybody to read it? 

Also, why do you suggest that I provide examples, but you also criticize me for telling Hank to look at my example programs? I have multiple example programs in the novice package, most of which are small, and then the slide-rule program which is large (although a lot of space is taken up by scale definitions that can be skimmed over as they all employ the same basic mechanism).

All of this stuff seems so simple and obvious to me, that I can't really relate to anybody who needs a tutorial. If I wrote a tutorial, everybody would complain that they still don't understand, and that I need to write another 100 pages, and while I'm at it could I wipe their behinds for them as well...

ANS-Forth is a big failure. A guy like Hank spends $400+ on SwiftForth and he gets zilch in support. He gets Elizabeth Rather telling him to contort his program somehow to use PAD although he has more than one string in each record, and he gets a sales-pitch to buy "Forth Application Handbook" for $50 to learn about the "advanced data-structures," although it doesn't even provide FIELD (which is the basis for all data structures, easy or advanced).

I'm just writing my own language now. When it is done, it will be for machinists doing CAM work. They are intelligent industrious people --- they don't need anybody to wipe their behinds for them --- I expect them to be able to figure out how to use READ-SEQ without so much ado. If people can learn basic stuff like this on their own, then I will help them with the more advanced stuff, but I'm not going to waste my time writing a tutorial.

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

#28640

On Friday, February 21, 2014 7:10:54 AM UTC+2, hughag...@yahoo.com wrote:
> I haven't been reading the discussion very closely ...
> I'm just extremely frustrated with how everything gets blown up into a hugely complicated and confusing mess on comp.lang.forth. Hank wants a "flat database" (your basic sequential text file), but the C.L.F. crowd acts like reading a text file into a linked list has never been done and can only be speculated on. 

Hi!

If you read it very closely, you'll see that Hank wants to read input into a linked-list. I don't understand why, but a little exercise for him is necessary.

A beginner should grok basics, not use from start various packages.
He/she should experiment his own versions of code, read example code, understand it, experiment again, etc.
In other words, he/she must start think forth, not use "magically words"
hoping to do what he/she desire.

Have a nice day,
humptydumpty

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

#28673

On Thursday, February 20, 2014 11:42:51 PM UTC-7, humptydumpty wrote:
> On Friday, February 21, 2014 7:10:54 AM UTC+2, hughag...@yahoo.com wrote:
> 
> > I haven't been reading the discussion very closely ...
> 
> > I'm just extremely frustrated with how everything gets blown up into a hugely complicated and confusing mess on comp.lang.forth. Hank wants a "flat database" (your basic sequential text file), but the C.L.F. crowd acts like reading a text file into a linked list has never been done and can only be speculated on. 

> Hi!
> 
> If you read it very closely, you'll see that Hank wants to read input into a linked-list. I don't understand why, but a little exercise for him is necessary.

I'm not clear on what Hank wants. At first he said a "flat database," which means a seq text-file with typically one record per line and the fields either comma-delimited or at fixed offsets. Well, READ-SEQ pulls a seq text-file into a linked list, and the records can be split up into fields easily.

Now he seems to want to read data from the keyboard. I have GET-STR for that. All of this stuff is easy. 

Most likely, he doesn't have a clear plan for what he wants his program to do.
 
> A beginner should grok basics, not use from start various packages.
> He/she should experiment his own versions of code, read example code, understand it, experiment again, etc.
> In other words, he/she must start think forth, not use "magically words"
> hoping to do what he/she desire.

I understand what you are saying. In some languages we have "script kiddies" who just paste together other people's code, but who can't actually write programs themselves. This is not learning at all.

On the other hand though, writing every program totally from scratch is a big waste of time. The novice needs to have some success at writing a program, and to do this he needs a package of useful code to build on. As it is, the Forth novice spends a lot of time implementing very low-level code that would already be provided in any other language, and he never gets his application program done. He eventually gets frustrated as he realizes that he has been at it for weeks or months and has yet to succeed at even an easy program, and he gives up --- this isn't learning either.

You said that the novice should study example programs. Are these example programs supposed to be written totally from scratch? If so, they are going to be pretty trivial programs. I have non-trivial example programs in the novice package only because I had the basic stuff (linked lists, etc.) available to build on.

Anyway, it is all a moot point now. Hank has decided against the novice package. Apparently he is using FFL. But FFL is pretty thin on features, so he is going to ask questions about basic stuff such as reading the keyboard or reading a text file here on C.L.F. --- and the trolls are going to feed him misinformation in order to perpetuate his novice status indefinitely (in order to perpetuate their expert status indefinitely). But, not my concern anymore.

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

#28620

On Thursday, February 20, 2014 2:24:10 AM UTC+2, hank....@gmail.com wrote:

>  Thanks for showing me a little light!

You welcome!  Whenever have a question (little or big :-) about coding,
debugging, designing, etc.  you'll find someone here on clf to ask.

Enjoying forth too,
humptydumpty

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

#28558

On 19/02/2014 01:01, Albert van der Horst wrote:
> In article <f2ed5b12-6c7b-459c-9415-6038f64252d3@googlegroups.com>,
>   <hank.lenzi@gmail.com> wrote:
>> On Tuesday, February 18, 2014 7:48:12 PM UTC-3, Julian Fondren wrote:
>>> On Monday, February 17, 2014 9:54:16 PM UTC-6, hank....@gmail.com wrote:
>>>

[...]

>> Let me see if I expand on what I was thinking in a clear way: I thought
>> REFILL would capture, e.g., "CAPT25 30P 1PD" (all valid words in my
>> software), as a whole *line*.

It will if you type it in as a whole line. (unless you use ciforth - see 
below).

>
> The word you're looking for is ACCEPT, in older Forth's EXPECT.
> It waits until the user has completed a line.

As does REFILL in a properly implemented system.

>
> CREATE MY-BUFFER 80 ALLOT
> MY-BUFFER DUP 80 ACCEPT    ( -- address u)
>

That's an acceptable alternative to REFILL but has the drawback that you 
can't easily use WORD or PARSE on the returned string.

> If your system has a file descriptor 0 for standard input, it is almost
> the same than
> MY-BUFFER DUP 80  0 READ-FILE THROW
> "get me at most 80 characters to MY-BUFFER from the input stream."
>
> [ REFILL is used by the system to get the next line to compile (or interpret).
> It is used internally by WORD as per:
> "Gosh, nothing on this line. Let's get another one before parsing a word."

Nonsense, in ANS Forth WORD does *not* fetch another line of input if 
there is nothing left to parse, it simply returns an empty string. If 
ciforth's WORD fetches more input it is non-standard

>
> REFILL is a somewhat obscure word.

Nonsense, nothing obscure about it. It fetches a line of input from the 
current input source if that source can supply it.

You don't need it. ciforth has
>    : REFILL FALSE ;
> and is doing just fine. ]
>

That is a useless definiton of REFILL. ciforth can clearly accept 
console input otherwise ACCEPT wouldn't work - so what's the logic 
behind REFILL telling a lie?


-- 
Gerry

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

#28588

In article <le1ne8$s74$1@dont-email.me>,
Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
<SNIP>
>
>>
>> REFILL is a somewhat obscure word.
>
>Nonsense, nothing obscure about it. It fetches a line of input from the
>current input source if that source can supply it.

REFILL behaves differently if input from a string a block, the console
or a file. It fetches it to a buffer that is under control of the
Forth system, and can be accessed properly only by a protocol. It is a
system word and cannot by a novice be used for straightforward input
without great danger. Please note that the context is that I talk to
someone who is writing an application program.
Paint me green if obscure is not an appropriate expression.

>
>You don't need it. ciforth has
>>    : REFILL FALSE ;
>> and is doing just fine. ]
>>
>
>That is a useless definiton of REFILL. ciforth can clearly accept
>console input otherwise ACCEPT wouldn't work - so what's the logic
>behind REFILL telling a lie?

ciforth's REFILL doesn't lie. Because ciforth always reads in the
whole input source, its REFILL has nothing to do and just tells that
there is no more input available. (You're right that the system needs
a REFILL-TIB, but you never want to use it directly.)

There is some lack of ANSI conformity here, but it amounts to missing
words.

By the by has anyone a test set for REFILL?

>--
>Gerry

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]

#28590

On 19/02/2014 20:10, Albert van der Horst wrote:
> In article <le1ne8$s74$1@dont-email.me>,
> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
> <SNIP>
>>
>>>
>>> REFILL is a somewhat obscure word.
>>
>> Nonsense, nothing obscure about it. It fetches a line of input from the
>> current input source if that source can supply it.
>
> REFILL behaves differently if input from a string a block, the console
> or a file. It fetches it to a buffer that is under control of the
> Forth system, and can be accessed properly only by a protocol.

I don't know what you mean by this. The input returned by REFILL can be 
accessed by executing SOURCE e.g.

: get-line  ( -- caddr u )  refill 0= throw source ;

get-line will return the input that REFILL obtained whether the current 
input source is from the console, a string, a block or a file. GET-LINE 
is a simple definition not a protocol.

  It is a
> system word and cannot by a novice be used for straightforward input
> without great danger.

What danger? Who says it is a system word - it's defined in the standard 
as a word to obtain text from the current input source independent of 
what that source might be. ISTM that this makes it more of a user word 
than a system word.

Please note that the context is that I talk to
> someone who is writing an application program.
> Paint me green if obscure is not an appropriate expression.

I'll get my green pot of paint out.

>
>>
>> You don't need it. ciforth has
>>>     : REFILL FALSE ;
>>> and is doing just fine. ]
>>>
>>
>> That is a useless definiton of REFILL. ciforth can clearly accept
>> console input otherwise ACCEPT wouldn't work - so what's the logic
>> behind REFILL telling a lie?
>
> ciforth's REFILL doesn't lie. Because ciforth always reads in the
> whole input source,

unless it's keyboard input because it can't - it hasn't been typed yet. 
In that case it should accept whatever the user types as the next line 
of input. That's what every other ANS Forth system I've tried does. I 
also think you'll find that other Forth systems that read the whole of 
an input file for compilation/interpretation will, if REFILL is 
executed, return the next line of text that would have been 
interpreted/compiled. If they don't they are not ANS Forth compliant - 
neither is ciforth which is why I say ciforth's REFILL tells a lie 
(unless of course it is truly at the end of the file).

its REFILL has nothing to do and just tells that
> there is no more input available. (You're right that the system needs
> a REFILL-TIB, but you never want to use it directly.)

A user might want to do so e.g. a word has been defined using REFILL and 
the user wants to test it using the keyboard. Also a user might want 
keyboard input without having to use ACCEPT because WORD, PARSE or 
PARSE-NAME can be used on it which can't be directly done with whatever 
ACCEPT returns.

>
> There is some lack of ANSI conformity here, but it amounts to missing
> words.

No, I think you are mis-interpreting what REFILL should do.

>
> By the by has anyone a test set for REFILL?

My core extension tests for SAVE-INPUT and RESTORE-INPUT rely on REFILL 
working correctly when the input source is a file or a string. Nobody 
has yet reported that as being a faulty test. Testing REFILL on console 
input can't be done automatically any more than it can for ACCEPT


-- 
Gerry

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

#28602

In article <le3avs$apt$1@dont-email.me>,
Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>On 19/02/2014 20:10, Albert van der Horst wrote:
>> In article <le1ne8$s74$1@dont-email.me>,
>> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>> <SNIP>
>>>
>>>>
>>>> REFILL is a somewhat obscure word.
>>>
>>> Nonsense, nothing obscure about it. It fetches a line of input from the
>>> current input source if that source can supply it.
>>
>> REFILL behaves differently if input from a string a block, the console
>> or a file. It fetches it to a buffer that is under control of the
>> Forth system, and can be accessed properly only by a protocol.
>
>I don't know what you mean by this. The input returned by REFILL can be
>accessed by executing SOURCE e.g.
>
>: get-line  ( -- caddr u )  refill 0= throw source ;
>
>get-line will return the input that REFILL obtained whether the current
>input source is from the console, a string, a block or a file. GET-LINE
>is a simple definition not a protocol.

Nice, got you there. REFILL from a string will always fail and source
will be an empty string. For a block it will return the next block,
confusing as hell. Not only that but contrary to expectation it will
return 16 lines.

<SNIP>
>
>>
>> There is some lack of ANSI conformity here, but it amounts to missing
>> words.
>
>No, I think you are mis-interpreting what REFILL should do.

I would rephrase it likes this. I consider REFILL as it stands
a design error and don't want it in my Forth.

>
>>
>> By the by has anyone a test set for REFILL?
>
>My core extension tests for SAVE-INPUT and RESTORE-INPUT rely on REFILL
>working correctly when the input source is a file or a string. Nobody
>has yet reported that as being a faulty test. Testing REFILL on console
>input can't be done automatically any more than it can for ACCEPT

So the illusion that REFILL is somehow a component that can be tested
is scattered.

>
>--
>Gerry

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]

#28604

On 20/02/2014 12:10, Albert van der Horst wrote:
> In article <le3avs$apt$1@dont-email.me>,
> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>> On 19/02/2014 20:10, Albert van der Horst wrote:
>>> In article <le1ne8$s74$1@dont-email.me>,
>>> Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>>> <SNIP>
>>>>
>>>>>
>>>>> REFILL is a somewhat obscure word.
>>>>
>>>> Nonsense, nothing obscure about it. It fetches a line of input from the
>>>> current input source if that source can supply it.
>>>
>>> REFILL behaves differently if input from a string a block, the console
>>> or a file. It fetches it to a buffer that is under control of the
>>> Forth system, and can be accessed properly only by a protocol.
>>
>> I don't know what you mean by this. The input returned by REFILL can be
>> accessed by executing SOURCE e.g.
>>
>> : get-line  ( -- caddr u )  refill 0= throw source ;
>>
>> get-line will return the input that REFILL obtained whether the current
>> input source is from the console, a string, a block or a file. GET-LINE
>> is a simple definition not a protocol.
>
> Nice, got you there. REFILL from a string will always fail

Yes I knew that and shouldn't have included string there or in my later 
statement about tests.

and source
> will be an empty string.

No, look at the specification of SOURCE. Anyway it wouldn't in the above 
definition because an exception would be thrown and the input source 
restored to whatever it was before the string was evaluated.

  For a block it will return the next block,
> confusing as hell. Not only that but contrary to expectation it will
> return 16 lines.

So what, it is still the next block of text to be intepreted/compiled. 
Anyway I regard the use of blocks for source code as obsolete so I had 
no expectations about that.

>
> <SNIP>
>>
>>>
>>> There is some lack of ANSI conformity here, but it amounts to missing
>>> words.
>>
>> No, I think you are mis-interpreting what REFILL should do.
>
> I would rephrase it likes this. I consider REFILL as it stands
> a design error and don't want it in my Forth.

That's your prerogative and fine by me, but in that case it seems silly 
to define it as a synonym for FALSE. Better to not define it all so that 
a user is immediately told during compilation that it isn't defined 
instead of something failing when it is executed.


-- 
Gerry

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

#28613

In article <le4usn$85h$1@dont-email.me>,
Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>On 20/02/2014 12:10, Albert van der Horst wrote:
>>
>> I would rephrase it likes this. I consider REFILL as it stands
>> a design error and don't want it in my Forth.
>
>That's your prerogative and fine by me, but in that case it seems silly
>to define it as a synonym for FALSE. Better to not define it all so that
>a user is immediately told during compilation that it isn't defined
>instead of something failing when it is executed.

I agree with you there. So it isn't available in lina when you start it.

However some programs use REFILL such as the metacompilation of noforth.
Practically all of those programs that use REFILL work in ciforth after
loading the definition you find so offensive. noforth's metacompilation
is an example.

>--
>Gerry

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]

#28469

On 2/12/14 3:13 PM, hank.lenzi@gmail.com wrote:
...
>    Oh, linked list, as in data structure? There's an old Forth book I'm reading (Forth Applications, by S.D. Roberts), and he shows how to do linked lists but the book is kind of old (it has EXPECT, and uses screens...) Linked lists in Forth are kind of way over my head right now (me being a doctor...) but think I see what you mean. Do you mean to say to parse the triplets one word at a time, but then link them?
>
>    OTOH, I could just stack string addresses and count bytes and just pop them back too, right (hence the importance of allocating the heap, etc., as already discussed).
>
>    But, boy, would I like to see some linked list code in Forth! I'll check the SwiftForth documentation in more detail. Maybe there's some sort of utility there that I can simply use?
>
> (...)

I don't think it covers linked lists per se, but Forth Application 
Techniques (a tutorial that starts at the beginning but covers all the 
way to some fairly advanced stuff) has a lot of material on data 
structures that should be helpful to you.

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]

#28470

On Saturday, February 15, 2014 7:34:49 PM UTC-7, Elizabeth D. Rather wrote:
> On 2/12/14 3:13 PM, hank.lenzi@gmail.com wrote:
> >    But, boy, would I like to see some linked list code in Forth! I'll check the SwiftForth documentation in more detail. Maybe there's some sort of utility there that I can simply use?
> 
> I don't think it covers linked lists per se, but Forth Application 
> Techniques (a tutorial that starts at the beginning but covers all the 
> way to some fairly advanced stuff) has a lot of material on data 
> structures that should be helpful to you.

"Forth Application Techniques" doesn't cover linked lists or any kind of data-structures; it doesn't even provide FIELD, which is the basis for all data-structures. I wouldn't describe any of the Forth Inc. books as containing "fairly advanced stuff" --- the only one I recommend is "Thinking Forth," as it contains interviews with people who program in Forth (not Forth Inc. employees).

She has already scammed you out of over $400 for SwiftForth (it is only a matter of time before you abandon it for VFX), and now she is trying to scam you out of more money. 

Don't waste your money on Forth Inc.!!! Don't trust any salesperson who takes advantage of your newbieness to demand money from you! You should not have spent money when you were still a newbie and didn't know anything about the subject --- it is best to wait until you know at least the basics, before letting any slick salesperson talk you into handing over your hard-earned cash.

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

#28473

> She has already scammed you out of over $400 for SwiftForth (it is only a matter of time before you abandon it for VFX), and now she is trying to scam you out of more money. 
> 
 Hugh, I don't feel "scammed", I made a judgement call, based on what I perceived was a more "friendly" system, with better documentation (as *I* perceived it)...Like I said in another post, documentation is *huge*. It's no use developing software that'll stay only in the developer's head. Stuff is hard enough, daily life is hard enough that I should spend more hours than necessary to get stuff done. 

 I feel if a software developer doesn't care to put out there nice documentation, than I see no point in spending my time with his or her software, when I can find a better documented solutions. I mean, it's pretty obvious some people don't really care if their piece of software is going to be used or not, so it may be there's not really a point in even trying.

 Anyways, thanks for expressing your views.

 Cheers,

 -- Hank Lenzi

 

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

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

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

csiph-web