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

#28475

On Saturday, February 15, 2014 8:10:41 PM UTC-7, henry...@gmail.com wrote:
> > 
> > You want to convert an abbreviation string such as "SIMVA20" into a readable string such as "Simvastatin 20mg." Look in ASSOCIATION.4TH for code to do this. An association is a data structure that associates one string with another. Each node would contain two fields: the key field (SIMVA20) and the associated field (Simvastatin 20mg.). 
 
> Hi Hugh --
> 
>  I did look into your code - it's kind of hard to grok, from where I'm standing.
>  I did find a nice list implementation, from (Peter?) Salvi:
>  https://www.iit.bme.hu/~salvi/archive/snippets/linked-list.html
> 
>  Are you aware of it? It looks pretty nice.

I feel confident that anything that I write will be far ahead of anything that anybody else might write, so I never bother to look at other people's code at all.

My stuff is actually pretty simple and easy --- don't give up too easily! To grok ASSOCIATION.4TH you need to grok LLRB trees, and I found that difficult myself. You don't really need to grok ASSOCIATION.4TH to use it though --- just learn how to build a tree, look up nodes, traverse subsections, and so forth, without necessarily grokking the internal workings. 

Linked lists are so simple that you can grok them without difficulty --- start by learning LIST.4TH and totally grokking it, then upgrade to ASSOCIATION.4TH which is used very similarly although the internal workings are completely different.

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

#28479

on 16/02/2014 03:34:16,  wrote:
> On Saturday, February 15, 2014 8:10:41 PM UTC-7, henry...@gmail.com
> > wrote:
>> >
> > wrote:
>> > You want to convert an abbreviation string such as "SIMVA20" into a rea
> wrote: dable string such as "Simvastatin 20mg." Look in
> ASSOCIATION.4TH for code t o do this. An association is a data
> structure that associates one string wi th another. Each node would
> contain two fields: the key field (SIMVA20) and the associated field
> (Simvastatin 20mg.).
> 
>> Hi Hugh --
>>
>>  I did look into your code - it's kind of hard to grok, from where I'm st
> anding.
>>  I did find a nice list implementation, from (Peter?) Salvi:
>>  https://www.iit.bme.hu/~salvi/archive/snippets/linked-list.html
>>
>>  Are you aware of it? It looks pretty nice.
> 
> I feel confident that anything that I write will be far ahead of
> anything t hat anybody else might write, so I never bother to look at
> other people's c ode at all.

Programmers the world over at laughing. At you. 


> 
> My stuff is actually pretty simple and easy --- don't give up too
> easily! T o grok ASSOCIATION.4TH you need to grok LLRB trees, and I
> found that diffic ult myself. You don't really need to grok
> ASSOCIATION.4TH to use it though --- just learn how to build a tree,
> look up nodes, traverse subsections, an d so forth, without
> necessarily grokking the internal workings.
> 
> Linked lists are so simple that you can grok them without difficulty
> --- st art by learning LIST.4TH and totally grokking it, then upgrade
> to ASSOCIATI ON.4TH which is used very similarly although the internal
> workings are comp letely different.
> 

This is the umpteyuth time you've stated that you make no effort to read
other's code or validate your technques against other's techniques -- yet
you repeatedly insist that "novices" will find your code of use. The
evidence runs contrary to your assertions.

You and I have had a long discussion about the poor quality of the
implementation of popular sorts you wrote in your novice package, where
you have serious misunderstandings of how pointers work. You and others
have had discussions about how you didn't invented a tree you called a
"symtab", because it was well understood years before you dropped off the
teat; and how you encouraged novices to use it inappropriately because
its performane sucked.

I would advise caution before using your code.

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

#28482

On Sunday, February 16, 2014 2:48:34 AM UTC-7, Alex McDonald wrote:
> You and I have had a long discussion about the poor quality of the
> implementation of popular sorts you wrote in your novice package, where
> you have serious misunderstandings of how pointers work. 

My SORT works fine (it uses the HeapSort algorithm by default, although I also have a QuickSort version), and I'm pretty sure that I know how pointers work.

We haven't had any "long conversations" --- that would imply that I was interested in what you were saying and that there was an exchange of ideas --- actually, you're just a troll, and you lob weird accusations like this at me routinely.

> You and others
> have had discussions about how you didn't invented a tree you called a
> "symtab", because it was well understood years before you dropped off the
> teat; and how you encouraged novices to use it inappropriately because
> its performane sucked.

I invented the algorithm used in symtab. It was Passaniti who said that it "sucked" --- that was his terminology from his culture (he used comp.lang.forth to promote homosexuality) --- Passaniti isn't around anymore though, so why are you referencing him? --- I'd be happy to leave him in the past.

BTW: It is contradictory to say that it "sucked" and also to say that I didn't invent it and that it is well-known. You are not even good at being a troll!

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

#28496

In article <a2158ae3-4535-40a6-ab25-169143d72a00@googlegroups.com>,
 <hughaguilar96@yahoo.com> wrote:
 <SNIP>
>I invented the algorithm used in symtab. It was Passaniti who said that
>it "sucked" --- that was his terminology from his culture (he used
>comp.lang.forth to promote homosexuality) --- Passaniti isn't around
>anymore though, so why are you referencing him? --- I'd be happy to
>leave him in the past.

I do not remember that Passaniti used the term.
I do remember that Passaniti proved that symtab sucks, so there can
be no complaint if he did, except regarding rudeness.

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]

#28497

Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> In article <a2158ae3-4535-40a6-ab25-169143d72a00@googlegroups.com>,
> <hughaguilar96@yahoo.com> wrote:
> <SNIP>
>>I invented the algorithm used in symtab. It was Passaniti who said that
>>it "sucked"
> 
> I do not remember that Passaniti used the term.

What he actually said was, in part,

"Your symtab is too complicated for me to characterize the amount of
time it takes to lookup symbols, and you were too lazy to do as I
suggested and *measure* it.  A straight balanced binary tree would do
lookups in O(log2 N) time, but your symtab isn't balanced.  Your hope
is that most lookups will be in O(M) time for some small M, but that
(wrongly) assumes the frequency distribution matches the temporal
pattern of access, which I've shown isn't the case.  On top of this,
you're shifting nodes around based on frequency, so coming up with a
big-O measure of your symtab is going to be hard (maybe one of the
academics here can work that out).  In contrast, most real-world hash
tables have hash functions that have very good performance (that is,
produce few collisions).  That means that an open addressed hash table
will typically give you lookups in constant time close to O(1), up to
a load factor of about 75%.  A bad hash function can make that worse,
but even then, most real-world hash tables order collisions by putting
the most-recently used at the head of the chain.  The end result is
that even when hash tables have bad hash functions, they still exploit
the temporal pattern of access that your symtab does not.  So
practically, most hash table accesses typically will do lookups in
O(1) time, or O(2) time if the hash function is bad.  So your symtab
sucks if one cares about the efficiency of lookups."

and later,

"Yes, I said your code sucked.  That wasn't a off-the-cuff statement
and it wasn't just I who was critical of your code.  In my case, my
comments came as the result of an analysis using a real-world stream
of symbols where I showed that ordering the tree by frequency of
symbols resulted in longer search times than simpler data structures.
Further, your code makes no effort to exploit locality of reference,
which further reduces its effectiveness.  Finally, I (and others) also
noted that the memory consumption of your code was greater than
competitive data structures.  Put together, yes, your code sucks.  My
only regret in that assessment was that I shouldn't have been more
politically correct, because I didn't realize that your massive ego
was also massively fragile."

Andrew.


<91cf4b04-6772-4b4d-a780-e981f0c425ef@p19g2000vbq.googlegroups.com>
<73f14958-814a-48dc-b4a3-af428edf9e4d@i28g2000yqa.googlegroups.com>

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

#28502

Andrew Haley wrote:
> [quoting Passaniti] "My
> only regret in that assessment was that I shouldn't have been more
> politically correct, because I didn't realize that your massive ego
> was also massively fragile."

A recent study showed that Internet trolls do really have the personal 
disorders you would suggest they have, given their online behavior:

http://www.slate.com/articles/health_and_science/climate_desk/2014/02/internet_troll_personality_study_machiavellianism_narcissism_psychopathy.html

This study was apparently written by Captain Obvious ;-).

As the majority of trolls has a sadistic disorder, the "don't feed the 
trolls" rule really should be enforced: They are pleased by the pain they 
cause, and will continue to hurt other people, as long as they get positive 
feedback, where "positive" means the signals of pain from their victims.

From the frequent diatribes (with lots of personal insults) Hugh posts, I 
would suggest he's suffering from a borderline disorder.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#28499

on 16/02/2014 11:21:59,  wrote:
> On Sunday, February 16, 2014 2:48:34 AM UTC-7, Alex McDonald wrote:
>> You and I have had a long discussion about the poor quality of the
>> implementation of popular sorts you wrote in your novice package, where
>> you have serious misunderstandings of how pointers work.
> 
> My SORT works fine (it uses the HeapSort algorithm by default,
> although I a lso have a QuickSort version), and I'm pretty sure that I
> know how pointers work.

We had a long discussion about how your sorts moved records (fixed length
areas of memory) rather than adjusted a list of pointers, and was going
to be slow on anything other than a small number of short records due to
the amount of data being moved.

> 
> We haven't had any "long conversations" --- that would imply that I
> was int erested in what you were saying and that there was an exchange
> of ideas --- actually, you're just a troll, and you lob weird
> accusations like this at me routinely.
> 
>> You and others
>> have had discussions about how you didn't invented a tree you called a
>> "symtab", because it was well understood years before you dropped off the
>> teat; and how you encouraged novices to use it inappropriately because
>> its performane sucked.
> 
> I invented the algorithm used in symtab. It was Passaniti who said
> that it "sucked" --- that was his terminology from his culture (he
> used comp.lang.f orth to promote homosexuality) --- Passaniti isn't
> around anymore though, s o why are you referencing him? --- I'd be
> happy to leave him in the past.

Your present appears to be repeating the past. We've been over some of
the novice packages issues here before. You did not invent anything but
the name "symtab"; splay trees have been around a lot longer than that.

> 
> BTW: It is contradictory to say that it "sucked" and also to say that
> I did n't invent it and that it is well-known. You are not even good
> at being a t roll!
> 

To quote Passiniti: "Every day, programmers who are unaware of the work
of others often come up with sub-optimal implementations of well-known
algorithms." He was right, since what you rediscovered and sub optimally
implemented was in fact a splay tree, and its performance was
significantly less impressive than you claimed.

But you know that, since it was discussed at considerable length here on
clf. It was you who said then, and repeated in this thread now, that you
didn't read anything by others, and that you were convinced your work was
superior.

The areas I find less than useful in your library for novices are:

 Sorts of records
 Arrays 
 Counted string words that can buffer overflow and aren't re-entrant 
 "Optimisations" that are premature (all the 'word,' words) and use
state

Then there are the sorts, symtab and wierd use of terminology like
"toucher" and "definer".

The fact that you created this package is laudable. But you appear
unwilling to accept criticism of some of the package's features, and tend
to descend into rants, particularly nasty attacks on individuals, when
asked to justify some of your wilder claims. Not a post goes by without
an attack on Ms Rather, the poor woman. They are plainly driven by some
deep seated problem you need to get in control. You also have a Pavlovian
reaction to Passaniti, and to the word "sucks", seeing him and it as some
kind of homosexual conspiracy to attack your masculinaty, and you fall
into a rage at the very thought. Imagine I accused you of being a
pederast? You regularly use the word "toucher". Obscene! Stop promoting
your perversions on CLF! Should I get into such a rage and end every post
to you with such a slur?

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

#28510

On Monday, February 17, 2014 7:53:18 AM UTC-7, Alex McDonald wrote:
> on 16/02/2014 11:21:59,  wrote:
> > On Sunday, February 16, 2014 2:48:34 AM UTC-7, Alex McDonald wrote:
> >> You and I have had a long discussion about the poor quality of the
> >> implementation of popular sorts you wrote in your novice package, where
> >> you have serious misunderstandings of how pointers work.
 
> > My SORT works fine (it uses the HeapSort algorithm by default,
> > although I also have a QuickSort version), and I'm pretty sure that I
> > know how pointers work.

> We had a long discussion about how your sorts moved records (fixed length
> areas of memory) rather than adjusted a list of pointers, and was going
> to be slow on anything other than a small number of short records due to
> the amount of data being moved.

SORT works for either an array of records or an array of pointers to records --- the user has the option to do either.

For example, in LIST.4TH I have BIG-SORT that converts a list into an array of pointers to the nodes of the list, does SORT on that array of pointers, then converts the array of pointers back into a sorted list again.

On the other hand, it is often convenient for a programmer to have an array of records rather than an array of pointers to records. Of course, if the records are very large, then moving them around may be inefficient, so this has to be balanced against convenience. The programmer can do whatever he wants to do though --- I don't limit him to one way or the other --- it is his choice.

When you say that I have a "serious misunderstanding of how pointers work," you are just being a troll lobbing weird accusations at me. I've been pretty solid on how pointers work since I was a teenager programming the 6502 in the VIC-20 --- your accusation is not realistic --- who is really going to believe that at this late data I still don't know how pointers work? The same thing is true of Julian Fondren saying that my ,STR doesn't work --- for a troll, truth is not an issue --- the whole point seems to be just to poison the minds of people like Hank with the idea that my novice package is full of bugs. These aren't "discussions" --- these are attacks full of lies.

> Your present appears to be repeating the past. We've been over some of
> the novice packages issues here before. You did not invent anything but
> the name "symtab"; splay trees have been around a lot longer than that.

Symtab is not a splay-tree.

A splay-tree assumes that words that were recently searched for will be searched for again. By comparison, my symtab assumes that words have a relatively static frequency of how often they are searched for. For example, a word such as + will migrate closer to the root of the tree than a word such as D+ assuming that it is used more often. My symtab algorithm really has nothing in common with the splay-tree algorithm.

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

#28530

on 18/02/2014 04:48:51,  wrote:
> On Monday, February 17, 2014 7:53:18 AM UTC-7, Alex McDonald wrote:
>> on 16/02/2014 11:21:59,  wrote:
>> > On Sunday, February 16, 2014 2:48:34 AM UTC-7, Alex McDonald wrote:
>> >> You and I have had a long discussion about the poor quality of the
>> >> implementation of popular sorts you wrote in your novice package, wher
> e
>> >> you have serious misunderstandings of how pointers work.
> 
>> > My SORT works fine (it uses the HeapSort algorithm by default,
>> > although I also have a QuickSort version), and I'm pretty sure that I
>> > know how pointers work.
> 
>> We had a long discussion about how your sorts moved records (fixed length
>> areas of memory) rather than adjusted a list of pointers, and was going
>> to be slow on anything other than a small number of short records due to
>> the amount of data being moved.
> 
> SORT works for either an array of records or an array of pointers to
> record s --- the user has the option to do either.
> 
> For example, in LIST.4TH I have BIG-SORT that converts a list into an
> array of pointers to the nodes of the list, does SORT on that array of
> pointers, then converts the array of pointers back into a sorted list
> again.

Sigh. I really can't be arsed finding all the replies I made to you on
the subject of sorting. As with your symtab nonsense, you claimed
performance that you weren't willing to test. Others did it for you. 

And you have been told before that a merge sort is much faster and much
easier for lists. Only an idiot would do what you suggest, but apparently
you are that idiot.


> 
> On the other hand, it is often convenient for a programmer to have an
> array of records rather than an array of pointers to records. Of
> course, if the records are very large, then moving them around may be
> inefficient, so this has to be balanced against convenience. The
> programmer can do whatever he wants to do though --- I don't limit him
> to one way or the other --- it is his choice.
> 
> When you say that I have a "serious misunderstanding of how pointers
> work," you are just being a troll lobbing weird accusations at me.
> I've been pret ty solid on how pointers work since I was a teenager
> programming the 6502 i n the VIC-20 --- your accusation is not
> realistic --- who is really going t o believe that at this late data I
> still don't know how pointers work? The same thing is true of Julian
> Fondren saying that my ,STR doesn't work --- f or a troll, truth is
> not an issue --- the whole point seems to be just to p oison the minds
> of people like Hank with the idea that my novice package is full of
> bugs. These aren't "discussions" --- these are attacks full of lie s.

I didn't realise that Julian Fondren had joined the long list of folks
you dislike. More to the point, what's he got to do with my point?

> 
>> Your present appears to be repeating the past. We've been over some of
>> the novice packages issues here before. You did not invent anything but
>> the name "symtab"; splay trees have been around a lot longer than that.
> 
> Symtab is not a splay-tree.
> 
> A splay-tree assumes that words that were recently searched for will
> be sea rched for again. By comparison, my symtab assumes that words
> have a relativ ely static frequency of how often they are searched
> for. For example, a wor d such as + will migrate closer to the root of
> the tree than a word such as D+ assuming that it is used more often.
> My symtab algorithm really has not hing in common with the splay-tree
> algorithm.
> 

Double sigh. You were taken through all this before, and your claim for
its superior performance for a whole range of use cases was dismissed. 

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

#28478

On 16/02/2014 04:10, henry.lenzi@gmail.com wrote:
>>
>> You want to convert an abbreviation string such as "SIMVA20" into a readable string such as "Simvastatin 20mg." Look in ASSOCIATION.4TH for code to do this. An association is a data structure that associates one string with another. Each node would contain two fields: the key field (SIMVA20) and the associated field (Simvastatin 20mg.).
>>
>
> Hi Hugh --
>
>   I did look into your code - it's kind of hard to grok, from where I'm standing.
>   I did find a nice list implementation, from (Peter?) Salvi:
>
>   https://www.iit.bme.hu/~salvi/archive/snippets/linked-list.html
>
>   Are you aware of it? It looks pretty nice.
>
>   -- Hank Lenzi
>

Hi,
that's a nice pointer, thanks!
Lists crop up ever so often. If you do a search on clf for its existing 
live span, you'll find probably more. For instance:
https://groups.google.com/forum/#!topicsearchin/comp.lang.forth/subject$3Alist$20AND$20subject$3Ahandling%7Csort:date%7Cspell:true

You could also try the user forum of your preferred Forth system. Most 
systems have one (VFX?). There might be system specific code (snippets) 
available there.

-r

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

#28481

On Saturday, February 15, 2014 8:10:41 PM UTC-7, henry...@gmail.com wrote:
>  I did find a nice list implementation, from (Peter?) Salvi:
>  https://www.iit.bme.hu/~salvi/archive/snippets/linked-list.html
> 
>  Are you aware of it? It looks pretty nice.

Well, I read through it. This MAPC does roughly the same thing as my EACH does:

: mapc ( xt lst-addr -- )
    begin ?dup while 2dup car swap execute cdr repeat drop ;

MAPC is a screwed-up implementation however. It is holding its internal data on the data-stack. This means that any data the user has on the data-stack will not be accessible. The xt-function ("toucher" in my documentation terminology) will not have access to the function's data that called MAPC. By comparison, my EACH holds its internal data on the return-stack during the EXECUTE, so that the xt-function has access to the data that is on the data-stack. There are examples of doing this in LIST.4TH as well as commentary.

Apparently, that code was written by a Lisper (notice the Lisp terminology such as CAR and CDR) who was trying to port some Lisp ideas over to Forth. Also apparently however, the guy doesn't actually use Forth --- otherwise he would have discovered the problem with MAPC covering up the data on the data-stack with its own internal data.

I wouldn't put too much stock into any code like this that has been made public, but which has never been used in a non-trivial program.

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

#28484

On Sunday, February 16, 2014 7:10:41 AM UTC+4, henry...@gmail.com wrote:
 
>  I did find a nice list implementation, from (Peter?) Salvi:
> 
>  https://www.iit.bme.hu/~salvi/archive/snippets/linked-list.html
> 
>  Are you aware of it? It looks pretty nice.
> 
>  -- Hank Lenzi

One more link I've discovered recently on github. Something called 
Forth Foundation Library - a lot of interesting stuff including double and 
single linked lists:

https://github.com/ayrnieu/ffl 

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

#28488

On Sunday, February 16, 2014 11:09:21 AM UTC-7, Alexander Skobelev wrote:
> One more link I've discovered recently on github. Something called 
> Forth Foundation Library - a lot of interesting stuff including double and 
> single linked lists:
> 
> https://github.com/ayrnieu/ffl

The last time that I looked at FFL, it had the same bug that was in the code discussed above (its version of EACH put its internal data on the data-stack on top of the user's data). Now however, this problem seems to have been fixed:

: snl-execute      ( i*x xt snl -- j*x = Execute xt for every node in list )
  snl-first@                 \ walk = first
  BEGIN
    nil<>?                   \ while walk<>nil do
  WHILE
    2>r 
    2r@ swap execute         \  execute xt with node
    2r>
    snn-next@                \  walk = walk->next
  REPEAT
  drop
;

This most likely got fixed in response to my pointing out the problem. Does anybody know the history on FFL problems getting fixed? All in all, I have no interest in FFL --- if they borrow some ideas from my novice package, I don't really care.

This is less efficient than my EACH however because it is doing a 2>R 2R@ and 2R> at every iteration. They should have borrowed my code rather than just my idea.

Also, we can find a node that matches, but we can't find the node previous to the node that matches --- so they are still not up to the capability of my novice package. I just glanced over their source-code so I don't know what else they may be missing.

Also, we still have that weird naming convention of FFL --- this is the primary reason why I'm not interested in getting involved in FFL. Who is in charge of FFL anyway? Is this somebody who would talk to me, or somebody who would say that my code "sucks" without looking at it?

This is the correct link:
https://code.google.com/p/ffl/source/browse/trunk/ffl/snl.fs

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

#28508

> One more link I've discovered recently on github. Something called 
> 
> Forth Foundation Library - a lot of interesting stuff including double and 
> 
> single linked lists:
> 
> 
> 
> https://github.com/ayrnieu/ffl

 Yes, very nice! (although, I wish it was BSDed or LGPLed). 
 The documentation was clear enough that I got it working.
 I was able to get a little something working here, using the FFL.
 I can get medications word-my-word, allocate them to heap, save them in a linked-list.
 The problem is, there seem to be some junk saved...For instance, when I get the "c-addr u" from the linked-list to the stack and TYPE it, some trash comes along with it (weird characters), such as:  "1CPD25PARSE-AREA ½ 2" (actually, they can't be posted on Usenet using Google's Groups). 

\ We need Julian Fronde's words for heap allocation:
: ALLOCATED ( u -- u c-addr ) 
  dup allocate throw ;
: SAVE-INTO ( c-addr1 u c-addr2 -- c-addr2 u ) 
  SWAP SAVE ;
: SAVE-MEM ( c-addr1 u -- c-addr2 u )
  allocated save-into ;

\ Initialize the linked-list
SCL-NEW VALUE LIST

\ The stack this function refers to would be the world lists
\ collected by REFILL. Doesn't quite work on a whole line of input, such
\ as "CAPT25 30P 1PD", but does its job when used with the "NL" function
\ bellow, when used for processing words one-by-one. See "NL".
: (SAVE\APPEND) 
	DEPTH 0 DO 
		LIST SCL-APPEND
	LOOP ;

\ The idea is the the same as the above function.
: (SAVE-MEM) 
		\ STACK'S ALWAYS GONNA BE AN ODD NUMBER 
	DEPTH 1- 0 DO SAVE-MEM LOOP
;

: NL  
              \ USE: Write a word <ENTER><ESC>
              \ This will save c-addr u, after "conversion" from PAD's address
              \ to heap memory, on nodes of the linked-list.
              \ *ALMOST* worked when attempting to process a whole line of
              \ input (e.g., "CAPT25 30P 1PD <ENTER><ESC>"
              \ It converted just one pair of ( c-addr1 u1 -- c-addr2 u2 )
	      \ Seems to work --- SUBTLE BUG: nodes  :27 160177504 49 4771960 51 4771960 32 - GOTTA GET RID OF "27" ("ESC")
	      \ Also, PAD bug ---------------------------^^^^^^^^^----^^^^^^^----^^^^^^^
	      \ If you do it one-by-one it works, but then you gotta have a FORTH word to 
	      \ get rid every third item processed
              \ for instance, the linked-list dump:
              \ 27 136726984 32 27 136725864 51 27 136725584 49
              \ There's always the "27" escape code.
	      \ So there's always gotta be a drop after processing the strings
	      \ USE: Enter a valid prescription word and <ENTER>. <ESC> when finished.
	      \ If you make a mistake, <ESC> then write "CLEAR-LIST"
          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) (SAVE\APPEND) exit 
          else refill drop 1 word 
          then 
          then again ;

 To reconstruct a word, you must get them from linked-list to the stack.
 Suppose the stack length is 6, get c-addr and u back like this:
 5 LIST SCL-GET ( not destructive. SCL-DELETE is destructive. List is 0-indexed )

 4 LIST SCL-GET
 SWAP \ because we got c-addr and u in a "wrong" order
 TYPE


 SO, things that failed:
 1) Could not throw a whole line of valid "prescription words" to REFILL.
 2) Could not save to heap using iteration (via (SAVE\MEM) word).
 3) There's garbage after TYPEing the word. No idea where it comes from. 
    Nor how to solve it.

 Thing that worked:
 1) Get input word by word.
 2) Convert the address obtain from PAD and allocating string to heap.
 3) Store the string (actually, "c-addr u") on a linked-list.
 4) Retrieve string back from the linked-list data structure.

 Anyways, even though I'm not done yet, it seems I'm on the right path (it being the following: I want to get the prescription from the command line and the write it to file. Right now, we already have our mini-language for prescription that "just works", but it involves editing the file).

 I'd like to thank everyone who's expressed some idea and opinion here on comp.lang.forth. You know who you are.

 Cheers,
 -- Hank Lenzi



 

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

#28511

On 2/17/14 5:54 PM, hank.lenzi@gmail.com wrote:
>
>> One more link I've discovered recently on github. Something called
>>
>> Forth Foundation Library - a lot of interesting stuff including double and
>>
>> single linked lists:
>>
>>
>>
>> https://github.com/ayrnieu/ffl
>
>   Yes, very nice! (although, I wish it was BSDed or LGPLed).
>   The documentation was clear enough that I got it working.
>   I was able to get a little something working here, using the FFL.
>   I can get medications word-my-word, allocate them to heap, save them in a linked-list.
>   The problem is, there seem to be some junk saved...For instance, when I get the "c-addr u" from the linked-list to the stack and TYPE it, some trash comes along with it (weird characters), such as:  "1CPD25PARSE-AREA ½ 2" (actually, they can't be posted on Usenet using Google's Groups).

That symptom is usually caused by mixing fixed-length and 
different-length strings (I avoid the term "variable length" because 
some people interpret this to mean the length of *a* string can vary). 
You can design your program to either use strings of different lengths 
(most conveniently stored as "counted strings") *or* strings of all the 
same length either ACCEPTed or stored into a region pre-initialized to 
blanks. You'd use -TRAILING to type one out.

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]

#28549

 
> 
> That symptom is usually caused by mixing fixed-length and 
> 
> different-length strings 

 (...)

 I'm lost. What do you mean? Where did I do that?

> Cheers,
> 
> Elizabeth
>
 TIA
 -- Hank Lenzi

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

#28538

On Tuesday, February 18, 2014 5:54:16 AM UTC+2, hank....@gmail.com wrote:
> > One more link I've discovered recently on github. Something called 
> 
> > 
> 
> > Forth Foundation Library - a lot of interesting stuff including double and 
> 
> > 
> 
> > single linked lists:
> 
> > 
> 
> > 
> 
> > 
> 
> > https://github.com/ayrnieu/ffl
> 
> 
> 
>  Yes, very nice! (although, I wish it was BSDed or LGPLed). 
> 
>  The documentation was clear enough that I got it working.
> 
>  I was able to get a little something working here, using the FFL.
> 
>  I can get medications word-my-word, allocate them to heap, save them in a linked-list.
> 
>  The problem is, there seem to be some junk saved...For instance, when I get the "c-addr u" from the linked-list to the stack and TYPE it, some trash comes along with it (weird characters), such as:  "1CPD25PARSE-AREA ½ 2" (actually, they can't be posted on Usenet using Google's Groups). 
> 
> 
> 
> \ We need Julian Fronde's words for heap allocation:
> 
> : ALLOCATED ( u -- u c-addr ) 
> 
>   dup allocate throw ;
> 
> : SAVE-INTO ( c-addr1 u c-addr2 -- c-addr2 u ) 
> 
>   SWAP SAVE ;
> 
> : SAVE-MEM ( c-addr1 u -- c-addr2 u )
> 
>   allocated save-into ;
> 
> 
> 
> \ Initialize the linked-list
> 
> SCL-NEW VALUE LIST
> 
> 
> 
> \ The stack this function refers to would be the world lists
> 
> \ collected by REFILL. Doesn't quite work on a whole line of input, such
> 
> \ as "CAPT25 30P 1PD", but does its job when used with the "NL" function
> 
> \ bellow, when used for processing words one-by-one. See "NL".
> 
> : (SAVE\APPEND) 
> 
> 	DEPTH 0 DO 
> 
> 		LIST SCL-APPEND
> 
> 	LOOP ;
> 
> 
> 
> \ The idea is the the same as the above function.
> 
> : (SAVE-MEM) 
> 
> 		\ STACK'S ALWAYS GONNA BE AN ODD NUMBER 
> 
> 	DEPTH 1- 0 DO SAVE-MEM LOOP
> 
> ;
> 
> 
> 
> : NL  
> 
>               \ USE: Write a word <ENTER><ESC>
> 
>               \ This will save c-addr u, after "conversion" from PAD's address
> 
>               \ to heap memory, on nodes of the linked-list.
> 
>               \ *ALMOST* worked when attempting to process a whole line of
> 
>               \ input (e.g., "CAPT25 30P 1PD <ENTER><ESC>"
> 
>               \ It converted just one pair of ( c-addr1 u1 -- c-addr2 u2 )
> 
> 	      \ Seems to work --- SUBTLE BUG: nodes  :27 160177504 49 4771960 51 4771960 32 - GOTTA GET RID OF "27" ("ESC")
> 
> 	      \ Also, PAD bug ---------------------------^^^^^^^^^----^^^^^^^----^^^^^^^
> 
> 	      \ If you do it one-by-one it works, but then you gotta have a FORTH word to 
> 
> 	      \ get rid every third item processed
> 
>               \ for instance, the linked-list dump:
> 
>               \ 27 136726984 32 27 136725864 51 27 136725584 49
> 
>               \ There's always the "27" escape code.
> 
> 	      \ So there's always gotta be a drop after processing the strings
> 
> 	      \ USE: Enter a valid prescription word and <ENTER>. <ESC> when finished.
> 
> 	      \ If you make a mistake, <ESC> then write "CLEAR-LIST"
> 
>           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) (SAVE\APPEND) exit 
> 
>           else refill drop 1 word 
> 
>           then 
> 
>           then again ;
> 
> 
> 
>  To reconstruct a word, you must get them from linked-list to the stack.
> 
>  Suppose the stack length is 6, get c-addr and u back like this:
> 
>  5 LIST SCL-GET ( not destructive. SCL-DELETE is destructive. List is 0-indexed )
> 
> 
> 
>  4 LIST SCL-GET
> 
>  SWAP \ because we got c-addr and u in a "wrong" order
> 
>  TYPE
> 
> 
> 
> 
> 
>  SO, things that failed:
> 
>  1) Could not throw a whole line of valid "prescription words" to REFILL.
> 
>  2) Could not save to heap using iteration (via (SAVE\MEM) word).
> 
>  3) There's garbage after TYPEing the word. No idea where it comes from. 
> 
>     Nor how to solve it.
> 
> 
> 
>  Thing that worked:
> 
>  1) Get input word by word.
> 
>  2) Convert the address obtain from PAD and allocating string to heap.
> 
>  3) Store the string (actually, "c-addr u") on a linked-list.
> 
>  4) Retrieve string back from the linked-list data structure.
> 
> 
> 
>  Anyways, even though I'm not done yet, it seems I'm on the right path (it being the following: I want to get the prescription from the command line and the write it to file. Right now, we already have our mini-language for prescription that "just works", but it involves editing the file).
> 
> 
> 
>  I'd like to thank everyone who's expressed some idea and opinion here on comp.lang.forth. You know who you are.
> 
> 
> 
>  Cheers,
> 
>  -- Hank Lenzi

Hi!

I think is a good habit to 'dump' than to to 'type',
when forth-ing.  You'll get a better picture about 
what is happening.

Something to think: SCL store a single cell in a linked list.
You will have to store a pair 'char-address unsigned-length'
that you allocate and store on heap. How would you do that?

On 'NL' loop: stack effect of sequence 'ekey dup 27 ='
is 'usigned-key-event flag'; flag is consumed by conditional
and key-event just pollute data-stack.

Advice: 
1. Write proper stack comment for every word you'll define
even it is obvious. It will help you on design and debugging.
2. Starting forthers should adopt vertical style of writing
definitions, with comment on stack effect on nearly all lines.
 
Have a nice time,
humptydumpty

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

#28546

> Hi!
> 
 Hey, Humpty Dumpty!
> 
> I think is a good habit to 'dump' than to to 'type',
> 
> when forth-ing.  You'll get a better picture about 
> 
> what is happening.

 Nice tip! Will do! 

> 
> Something to think: SCL store a single cell in a linked list.
> 
> You will have to store a pair 'char-address unsigned-length'
> 
> that you allocate and store on heap. How would you do that?
> 

 I did this here:
: (SAVE-MEM) 

         DEPTH 1- 0 DO SAVE-MEM LOOP 

 At least I think I did...This is the role of SAVE-MEM. It takes c-addr1 u1 from REFILL and WORD, and then allocates heap and saves c-addr2 u2.
 This isn't right?


> 
> On 'NL' loop: stack effect of sequence 'ekey dup 27 ='
> 
> is 'usigned-key-event flag'; flag is consumed by conditional
> 
> and key-event just pollute data-stack.

 Oh, oh! BTW, *how* do you know that? Is that in the ANS-Forth standard?
 Do you have any suggestions? I'm kinda stuck right now...

> 
> Advice: 
> 
> 1. Write proper stack comment for every word you'll define
> 
> even it is obvious. It will help you on design and debugging.
> 
> 2. Starting forthers should adopt vertical style of writing
> 
> definitions, with comment on stack effect on nearly all lines.
> 

   Definitely solid advice, I should have done. The reason I didn't is because I don't really know how REFILL works...

> 
> Have a nice time,
> 
> humptydumpty

 Thanks humptydumpty!
 -- Hank Lenzi

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

#28540

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/

> 
>  The documentation was clear enough that I got it working.
> 
>  I was able to get a little something working here, using the FFL.
> 
>  I can get medications word-my-word, allocate them to heap, save them in a linked-list.
> 

Cool!

>
> : (SAVE-MEM) 
> 
> 		\ STACK'S ALWAYS GONNA BE AN ODD NUMBER 
> 
> 	DEPTH 1- 0 DO SAVE-MEM LOOP
> 
> ;
> 

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.

So what is the point of doing it multiple times?  If run twice, it would just replace the same string twice.  It wouldn't affect strings below the top string on the stack.

Also, since the purpose of SAVE-MEM is to save you from overwriting buffers, isn't it too late to do this by the time you have multiple strings on the stack?

So I find this (SAVE-MEM) to be pretty mysterious.

> 
> : NL  
>           begin ekey? if ekey dup 27 = if (SAVE-MEM) (SAVE\APPEND) exit 
> 

(SAVE-MEM) is always invoked with the stack looking like ( c-addr u 27 -- )

Although I see where you adjust DEPTH above to try to discount the 27, aren't you actually saving a 'string' ( u 27 ) ?  Maybe you've adjusted SAVE-MEM as well, and are only actually saving the more sensible ( c-addr 27 ) , which will have garbage at the end whenever the input is less than 27 characters in length.

You probably want to DROP the 27 after the IF instead... er, or rather, why are you DUPing it in the first place?  Where do you use EKEY's return if it's not 27?

In any case, I think you'll find that things go awry before you save the string to the list, rather than after you get it from the list.


-- Julian

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

#28548

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*.

 So I would enter: "CAPT25 30P 1PD <ENTER><ESC>" and I *hoped* that REFILL would get that whole line. I was wrong on how refill worked.

 By trial and error, I found that doing it word by word, that is, "CAPT25<ENTER><ESC>", then "30P<ENTER><ESC>", then finally "1PD<ENTER><ESC>" worked, in the sense that SAVE-MEM "converted" the PAD addresses, and in the sense that the c-addr u pairs were save in the linked-list.

> So what is the point of doing it multiple times?  If run twice, it would just replace the same string twice.  It wouldn't affect strings below the top string on the stack.
> 
 
 Yes, that SAVE-MEM in a DO LOOP is senseless. The purpose was, of course, iterate through all the address, like (I think) I explained.
> 
> Also, since the purpose of SAVE-MEM is to save you from overwriting buffers, isn't it too late to do this by the time you have multiple strings on the stack?
> 
 Yup, it's too late. But like I said, I can't pass more than one "medication word" at a time to SAVE-MEM (via (SAVE-MEM))

> So I find this (SAVE-MEM) to be pretty mysterious.

 It's just buggy. I just left it there in order to clarify my original intent.
 
> 
> > : NL  
> 
> >           begin ekey? if ekey dup 27 = if (SAVE-MEM) (SAVE\APPEND) exit 
> 
> > 
> 
> 
> 
> (SAVE-MEM) is always invoked with the stack looking like ( c-addr u 27 -- )
> 
> 
> 
> Although I see where you adjust DEPTH above to try to discount the 27, aren't you actually saving a 'string' ( u 27 ) ?  Maybe you've adjusted SAVE-MEM as well, and are only actually saving the more sensible ( c-addr 27 ) , which will have garbage at the end whenever the input is less than 27 characters in length.
> 
> 
> 
> You probably want to DROP the 27 after the IF instead... er, or rather, why are you DUPing it in the first place?  Where do you use EKEY's return if it's not 27?
> 
> 
> 
> In any case, I think you'll find that things go awry before you save the string to the list, rather than after you get it from the list.
> 
>
> 
> -- Julian

 Julian, many thanks again, what can I say? I got think hard about these issues you raise. You've been *very* helpful.

 -- Hank Lenzi

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

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

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

csiph-web