bug in VFX

[Hugh Aguilar]

I posted this already:
https://groups.google.com/g/comp.lang.forth/c/Fmr2UH5FeoE
I had a typo in the header though and said: "Bugs in SwiftForth."
Stephen Pelc's excuse for not responding is most likely that
he didn't think the thread had anything to do with VFX.

The bug is that this ANS-Forth compliant code causes VFX to crash:
------------------------------------------
: lit, ( val -- ) \ runtime: -- val
postpone literal ;
------------------------------------------
POSTPONE LITERAL works, but calling LIT, does not work.
NN pointed out that this bug can be worked-around by putting an
ALIGN in front of the POSTPONE LITERAL in the LIT, definition.
The ALIGN is not needed in front of a POSTPONE LITERAL that is
in the hand-written macro itself.

I think that Stephen Pelc purposely introduced this bug into VFX
to break my novice-package. I'm the only person who uses LIT,
etc. --- everybody else just says POSTPONE LITERAL etc. when
hand-writing macros.

I don't actually need to hand-write macros anymore because I now
have an early-binding MACRO: definer that (unlike Anton Ertl's macro)
supports literal numbers as well as immediate words such as
[CHAR] C" S" POSTPONE etc. that remove data from the input stream.

I think Stephen Pelc introduced this bug into VFX to break my
novice-package, because he knew that I would be blamed when the
novice-package fails. Even if he fixes this bug in VFX, he will then just
introduce another more subtle bug into VFX to break something
else in the novice-package. I might not notice this sabotage without
doing a complete test of the entire novice-package every time that
a new VFX version is released. He has to be careful though, because
he might accidentally break somebody else's legacy VFX code and
that person will blame him because the legacy program never changed
and suddenly it stops working when recompiled with the new VFX version.

So, if your legacy VFX programs fail under the new VFX version,
you are most likely collateral damage in Stephen Pelc's effort to
prove that I'm an incompetent Forth programmer. Be careful to stay
on Stephen Pelc's good side, or he will purposely break your legacy
programs and not tell you how to work around the VFX bug.

[Jurgen Pitaske]

It might be a valid question to find out who uses this
novice-package
I wonder.

ALL NOVICE PACKAGE USERS please comment.

[Jurgen Pitaske]

and according to the other thread mentioned,
we might be talking about a non-problem anyway:

> Can I suggest the following change :

> : lit, ( val -- ) \ runtime: -- val

> align postpone literal ;
>
> Does this fix the problem Hugh ?

That seems to fix the problem.
This explains why MAYBE sometimes works and sometimes doesn't.
The code in LIT, is sometimes aligned and sometimes not. although
that is weird too --- I would expect the code in the word created by MAYBE
to always be aligned on a paragraph boundary to reduce cache-thrashing.

I haven't actually taken the time to use SEE to look at the code generated, or
to look at the code in the compiler that generates this code.
It is not really my job to debug VFX for Stephen Pelc.

[Jach Feng]

jpit...@gmail.com 在 2023年1月19日 星期四下午2:51:57 [UTC+8] 的信中寫道：

I had borrowed some codes ( include the Lit, :-) from Hugh's novice package to create a sturct data type in SwiftForth to interface the C library many years ago. I'm still using it today.

[Jurgen Pitaske]

So, are your products/ designs / projects now stopped
as MPE has brought out an improved version of VFX.

I assume you could use the old VFX version anyway?

And as you state you use it with Swiftforth it does not matter anyway.

[Hugh Aguilar]

Any use of VFX is stopped now because Stephen Pelc can't be trusted to maintain
ANS-Forth compatibility. He purposely introduces a bug in LIT, to break my
novice package, but he risks breaking other people's ANS-Forth code too.

As I said above, Stephen Pelc has been caught introducing this LIT, bug, so he may fix it,
but then introduce a more subtle bug to break my novice package that I wouldn't
catch immediately --- of course, the risk for him is that he breaks somebody else's code too.

On Friday, January 13, 2023 at 2:58:53 AM UTC-7, Kerr-Mudd, John wrote:
> On Thu, 12 Jan 2023 20:21:21 -0800 (PST)
> Hugh Aguilar <hughag...@gmail.com> wrote:
> > I still think that Stephen Pelc introduced the bug for the purpose of
> > breaking my novice package. Stephen Pelc hates me because I wrote
> []
> And it took that long.

I wrote an MSP-430 assembler. It is documented here:
https://board.flatassembler.net/topic.php?t=21841
Most likely, Stephen Pelc became aware of this, and he felt that I was intruding
upon his claimed territory (he sells an MSP-430 development system),
so that is why he introduced the LIT, bug to break my novice-package and stop
me from continuing with MSP-430 work --- he wants any user of my MSP-430
assembler to find that it crashes, and of course to blame me for this on the
assumption that I don't test my software before distributing it.

I don't necessarily download the latest and greatest version of VFX immediately
upon the its release. I'm not even aware of a new version being released because
I just continue using the version that I've got --- so I don't know that Stephen Pelc
has pulled the rug out from under my feet with his new version --- users of my
novice package may have the new version and not know that there is a new bug
that wasn't in the old version and which I wasn't aware of.

> --
> Bah, and indeed Humbug.

Kerr-Mudd, John --- your tagline effectively declares you to be a troll.
You never make any contribution to comp.lang.forth except to scoff at
other people's contributions, denouncing them as humbugs.

P.S. to Jach Feng --- if you want a new version of the novice package with the LIT,
bug fixed (using NN's suggested fix), drop me a line and I will send it to you.
Also, if you are doing anything with the MSP-430 I can send you my assembler too.
I'm also in the process of writing an STM8 assembler, but it is not finished.

[Jurgen Pitaske]

Could you please stop attacking commercial Forth companies.
People are just laughing about your troll behaviour.
And as you can see, nobody else is interested anyway.
If there is an issue, people will probably discuss it with MPE directly,
as they can then get into details to find a solution quickly.

[Hans Bezemer]

On Saturday, January 28, 2023 at 11:29:32 PM UTC+1, hughag...@gmail.com wrote:
> Any use of VFX is stopped now because Stephen Pelc can't be trusted to maintain
> ANS-Forth compatibility. He purposely introduces a bug in LIT, to break my
> novice package, but he risks breaking other people's ANS-Forth code too.

Ok - THINK! Because he can introduce bugs in other peoples code too, do you think this
is clever behavior for a vendor? Somebody whose livelihood literally DEPENDS on people
buying his product?

And if he WOULD BE, why not simply change compiler? If I would suspect myself sabotaging
my code, would the most logical behavior not be to stop using 4tH?

And again - there are plenty of very good Forth compilers. Even non-commercial ones, like
CIForth or Lina or iForth. These Dutchies may be walking around in cloggies and may have been
hit by a wing of a windmill once or twice while going outside, but they write some mean
compilers.

Hans Bezemer

[Hugh Aguilar]

On Sunday, January 29, 2023 at 12:49:00 AM UTC-7, jpit...@gmail.com wrote:
> Could you please stop attacking commercial Forth companies.
> People are just laughing about your troll behaviour.
> And as you can see, nobody else is interested anyway.
> If there is an issue, people will probably discuss it with MPE directly,
> as they can then get into details to find a solution quickly.

What Juergen Pintaske is saying, is that when VFX users discover bugs
in VFX, they need to contact Stephen Pelc directly at MPE, rather than
post these bug reports on comp.lang.forth. If Stephen Pelc considers
these VFX users to be worthy, then he will provide them with a bug fix.
He will expect them to not post these VFX bug fixes on comp.lang.forth.

If Stephen Pelc does not consider you to be worthy, he will not provide you
with a bug fix, but he will leave you to struggle alone at debugging VFX to
get your VFX code running again. Good luck with that! It is difficult enough
to debug your own code, but much more difficult if the compiler has bugs too.

Why would Stephen Pelc consider you to be unworthy of getting a VFX bug fix?
One obvious reason, is that you are still using the evaluation version of VFX
and haven't yet paid him for the professional version.
Mostly though, I think that Stephen Pelc is opposed to anybody using VFX
to compete against MPE. He most likely knows that I wrote an MSP-430
assembler. He wants his customers to buy his MSP-430 cross-compiler ($$$),
and he doesn't want anybody to use my free MSP-430 assembler on VFX instead.

Another reason that Stephen Pelc may consider VFX users to be unworthy
of receiving VFX bug fixes, is that they are refusing to provide him with the
source-code for their VFX programs. He needs source-code!

I have noticed that there is a lot of interest on comp.lang.forth in disassembly
and/or decompiling of Forth programs. This is an example:
https://groups.google.com/g/comp.lang.forth/c/OJkqt9wwXc0
This is another example:
https://groups.google.com/g/comp.lang.forth/c/6unZAh_D0jA/m/zQNf_04FAAAJ
Obviously, the reason why the comp.lang.forth experts need to disassemble
and/or decompile Forth programs, is that they don't have the source-code.
Obviously, the reason that they don't have the source-code is that the programmer
who wrote the source-code doesn't want them to steal his intellectual property.

I don't provide source-code unless I have some reason to believe that the person will
make a positive contribution, rather than steal my code and claim that he wrote it.
I posted documentation for my MSP-430 assembler (HJA430) here:
https://board.flatassembler.net/topic.php?t=21841
I did not provide source-code. There is a guy on that forum called Revolution who
is very focused on obtaining source-code from real programmers. He wants me to
give him my source-code so that I can be an "early pioneer" in MSP-430 assembly.
This is so maintenance-programmers can take over the HJA430 project. They will say:
"Well, there was some guy who was an early pioneer in the HJA430 project, but his code
was just a crude prototype --- then real programmers (us!) took over to make it viable."
An example of this being done is the Menuet OS that got stolen. The pirates slapped
their own copyright notice on the source-code two weeks after downloading it.
They called it the Kolibri OS and completely excluded the original programmer.
Now they have a big website to show off their super-duper salesmanship skills:
https://kolibrios.org/en/

The problem with software is that, after it is written, it appears to be easy and obvious.
People look at the source-code and say:
"This is very straightforward non-clever programming. Anybody could have written this!"
Then they make some minor modifications and start saying that they wrote it all.
Maintenance programmers want to do 1% of the work and claim 100% of the credit.
Of course, the obvious example of this is my MFX that I wrote at Testra.
Testra now claims that they wrote this long before I showed up and that I had
nothing to do with it. Testra can't stop me from telling the truth though; saying
that I wrote MFX myself without any help. I never signed an NDA; they can't sue me.

Designing software requires brains. Debugging software requires effort.
Writing software is easy, but you have to have a good design before you start,
and you have to get your paper-tiger debugged after you write it to make it work.
Maintenance programmers contribute neither brains nor effort.
Maintenance programmers are carrion-eaters.
Testra has had a parade of MFX maintenance programmers after I left,
but all of them failed to understand MFX; none of them made a positive contribution.
Three decades later, Testra continues to use my MFX as I wrote it.
They had to upgrade UR/Forth to work on the modern Windows OS in order to
keep MFX going decade after decade --- still running on UR/Forth!

[Hugh Aguilar]

On Thursday, January 19, 2023 at 12:20:09 AM UTC-7, jpit...@gmail.com wrote:
> On Thursday, 19 January 2023 at 06:51:57 UTC, Jurgen Pitaske wrote:
> > On Thursday, 19 January 2023 at 03:34:13 UTC, hughag...@gmail.com wrote:
> > > The bug is that this ANS-Forth compliant code causes VFX to crash:
> > > ------------------------------------------
> > > : lit, ( val -- ) \ runtime: -- val
> > > postpone literal ;
> > > ------------------------------------------
> > > POSTPONE LITERAL works, but calling LIT, does not work.
> > > NN pointed out that this bug can be worked-around by putting an
> > > ALIGN in front of the POSTPONE LITERAL in the LIT, definition.
> > > The ALIGN is not needed in front of a POSTPONE LITERAL that is
> > > in the hand-written macro itself.

> and according to the other thread mentioned,
> we might be talking about a non-problem anyway:
>
> > Can I suggest the following change :
> > : lit, ( val -- ) \ runtime: -- val
> > align postpone literal ;
> >
> > Does this fix the problem Hugh ?
>
> That seems to fix the problem.

I said that this *seems* to fix the problem.
It doesn't actually fix the problem in every case.
There are other circumstances in which the ALIGN doesn't help
and VFX still crashes. I have a lot words that use POSTPONE LITERAL
internally. I have tried hunting them all down and "fixing" them with
an ALIGN but some of them still cause VFX to crash.

On Sunday, January 29, 2023 at 12:49:00 AM UTC-7, jpit...@gmail.com wrote:
> And as you can see, nobody else is interested anyway.
> If there is an issue, people will probably discuss it with MPE directly,
> as they can then get into details to find a solution quickly.

So what is the solution???
You found the solution "quickly," so don't keep it to yourself. Tell us!
Inquiring minds want to know!

The problem with trying to fix bugs in VFX with hacky "fixes" such as
putting ALIGN in front of the POSTPONE LITERAL is that there is no
explanation for why this works, or any guarantee that this will always work.
I would need to have the source-code for VFX to figure out why VFX has
this bug and what can be done to fix the bug (not just put a band-aid on
the problem with ALIGN and not have any explanation for why this works
sometimes but not every time). I would also need to have a lot more than
24 hours in each day --- or I would need to get paid by Stephen Pelc to debug
VFX for him --- as it currently stands, I have neither the time to debug VFX
nor adequate information about how VFX works internally.

If Stephen Pelc put this bug into VFX purposely, in order to defeat me,
he has succeeded! I don't know how to fix the bug. Stephen Pelc is the winner!

Hans Bezemer says that Stephen Pelc did not introduce this bug purposefully.
This implies that Stephen Pelc is just plain incompetent. VFX worked in the past,
and now it doesn't work. Incompetance is a realistic explanation.
Thanks for pointing that out, Hans! I would never have guessed such an explanation.
Stephen Pelc is getting old. Senility and/or alcoholism are problems at his age.
Also, the only "programmer" that he employs is Peter Knaggs who is so incompetent
that he failed to implement a linked list:
https://groups.google.com/g/comp.lang.forth/c/cMa8wV3OiY0/m/INBDVBh0BgAJ
I don't think that Peter Knaggs is a programmer at all. A linked list should be easy!
I think that Stephen Pelc's multi-billion-dollar multi-national actually consists only
of Stephen Pelc and his dog Barto, and neither of them are any good at programming.

[Hans Bezemer]

I cannot be sure what exactly caused the bug in VFX. But given all possibilities, it seems
UNLIKELY he caused it on purpose. Just to bug you. It's simply applying Occams razor.

But why does a clever boy like you depends on somebody elses compiler? That's what
I can't figure out. Almost everybody down here uses his own. The one they built and
raised and eventually fell in love with.

Hans Bezemer <3 4tH

[dxforth]

On 4/02/2023 10:51 am, Hans Bezemer wrote:
>
> But why does a clever boy like you depends on somebody elses compiler? That's what
> I can't figure out. Almost everybody down here uses his own. The one they built and
> raised and eventually fell in love with.

Maintaining the narrative of the victim is what's important.

[Hugh Aguilar]

So far, Stephen Pelc's support has been primarily from Hans Bezemer, DXforth
and Juergen Pintaske.

Hans Bezemer enjoys flinging insults at me. First he calls me a "chirping bird,"
and now he calls me a "clever boy."
Hans' 4th that he fell in love with is a toy byte-code interpreter written in C.
He doesn't know what Harvard Architecture is. He doesn't know what copy-on-write
is. He doesn't really know anything about programming. He makes educational videos.

DXforth said this earlier:
On Thursday, January 12, 2023 at 5:44:22 PM UTC-7, dxforth wrote:
> On 12/01/2023 10:35 pm, albert wrote:
> > However if you do bother about ANS/ISO , then you can reap great benefit
> > from the efforts within MPE to deliver a compiler that be standard.
> > Even if you are not a paying customer.
> The Standard and what it permits is too complicated for the average user
> to understand. Implementers too, it would seem. ANS dug a hole so deep
> it challenges everyone.

This is just DXforth's endless stream of drivel about how much he hates the
idea of a Forth standard, and how this puts his awesome creativity in a box.
So far, his awesome creativity has been to write a Z80 Forth (almost certainly
he used the source-code from Loelliger's book for this). His greatest achievment
is the END macro that he has been bragging about for decades:
: END POSTPONE THEN POSTPONE EXIT ; IMMEDIATE
He tried for a long time to say that I support him in his hatred for the idea of a Forth
standard, but he eventually stopped because of the obvious problem that I am a strong
proponent of having a Forth standard --- the Forth community should start any time!
He gets a thrill out of mocking me by using the term "disambiguifier" for various
kindergarten-level Forth that he has written that has nothing to do with disambiguifiers.
He really doesn't know anything about the subject.

Juergen Pintaske, of course, endlessly spams this forum with advertisements
for books that were written in the 1980s that he now (4 decades later) claims
that he is the coauthor of. He also has his "A Start with Forth" book that is just
an over-grown sales pamphlet for VFX. He knows nothing about Forth programming!

Stephen Pelc's support base is composed entirely of pompous fake-experts.
The bottom line is that VFX is failing to compile ANS-Forth compliant code that
it used to compile correctly (SwiftForth still does compile this correctly).
I'm not a major "victim" here because I can dump VFX and use a different compiler.
The major victims are the MPE customers who have a large investment in VFX
and who expected VFX to continue to compile ANS-Forth code correctly.

I have always relied on VFX. The failure of VFX to compile the ANS-Forth
novice-package is an impetus for me to finally just write my own Forth system.
I'm also looking into Ilya Tarasov's Ibris Forth (I'm likely the only person here
who knows where the name "Ibris" comes from and thinks that it is a cool name).
Forth has some kind of future that Stephen Pelc and his bug-ridden VFX
will not be included in. Stephen Pelc was always a negative contributor to Forth
because he purposely crippled Forth-200x in order to make VFX look good
in comparison. So, good riddeance to Stephen Pelc and his salesman Juergen Pintaske!

[Jurgen Pitaske]

F O R T H K I L L E R H U G H A Q U I S H I T T I S B A C K

has escaped from his Mental Home again.
There was so much peace and quiet here
when he could not escape as of Corona.

Now he dumps his shit on CLF again.

There seems to be no work in Taxi Driving and Plumbing anymore either ...

Is there anybody here that gives a **** about the orgasms he generates while producing this shit?
At least it is visible that he is getting old.
It takes him a lot longer now.

And his brain is fortunately retiring,
as he does not remember the facts anymore.
For many years I have nothing to do with MPE / VFX anymore.
And it had been all documented here. But he is getting brain dead.

But a good point to remind me of the Forth Bookshelf I created,
and which will still be there when he is 6 foot under -
and I am quite proud of the work I did there.

Some of these books might be a bit dated,
but are there any better ones?
And they are still bought by people who are interested in Forth;
OK, there are only very few people,
as this guy tries to force them all away from here;

and number 5 - A Start with Forth -
is to my knowledge the newest Forth Documentation generated.
And I collected it and published it.

My knowledge of Forth is rather limited, just the basics;
does it matter?
But I enjoyed the bits I learnt
with the help of many here

and in the German Forth community
where such an idiot would just be excluded.

My Forth Bookshelf:
This is part of the current Forth Bookshelf and some other books and can be found at
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM

Is there any interest?
Well, look at the ones that are included in the top 100 of the Compiler Books:
BESTSELLERS IN COMPILER DESIGN.
https://www.amazon.com/gp/bestsellers/books/3970/ref=pd_zg_hrsr_b_1_5_last#5
Today only 3 of these books are there, but 3% is not bad, and it seems only one other Forth book.
Sometimes it goes up to 10% or more.
Not bad for a language like Forth.

1 Charles Moore - Forth - The Early Years: Background information about the
beginnings of this Computer Language
2 Charles Moore - Programming A Problem Oriented Language: Forth - how the
internals work
3 Leo Brodie - Starting Forth -The Classic
4 Leo Wong – Juergen Pintaske – Stephen Pelc FORTH LITE TUTORIAL: Code
tested with free MPE VFX Forth, SwiftForth and Gforth
5 Juergen Pintaske – A START WITH FORTH - Bits to Bites Collection
– 12 Words to start, then 35 Words, Javascript Forth on the Web, more
( 6 Stephen Pelc - Programming Forth: Version July 2016 )
7 Brad Rodriguez - Moving Forth / TTL CPU / B.Y.O. Assembler
8 Tim Hentlass - Real Time Forth

9 Chen-Hanson Ting - Footsteps In An Empty Valley issue 3
10 Chen-Hanson Ting - Zen and the Forth Language: EFORTH for the
MSP430G2552 from Texas Instruments
11 Chen-Hanson Ting - eForth and Zen - 3rd Edition 2017: with 32-bit
86eForth v5.2 for Visual Studio 2015
12 Chen-Hanson Ting - eForth Overview
13 Chen-Hanson Ting - FIG-Forth Manual Document /Test in 1802 IP
14 Chen-Hanson Ting - EP32 RISC Processor IP: Description and
Implementation into FPGA – ASIC tested by NASA
15 Chen-Hanson Ting – Irriducible Complexity
16 Chen-Hanson Ting - Arduino controlled by eForth
17 Chen-Hanson Ting – eForth as Arduino Sketch – no Programmer needed

( 18 Burkhard Kainka - Learning Programming with MyCo: )
Learning Programming easily - independent of a PC (Forth code to follow soon)
( 19 Burkhard Kainka - BBC Micro:bit: Tests Tricks Secrets Code, Additional MicroBit )
information when running the Mecrisp Package
( 20 Burkhard Kainka – Thomas Baum – Web Programming ATYTINY13 )
21 Georg Heinrichs - The ATTINY Project – Why Forth?
22 Dr. Karl Meinzer - IPS, a Forth-like language for Space
Juergen Pintaske, publisher, July 2020

[Jurgen Pitaske]

Oh, and just for completeness that his brain is going bananas:

He had one another post:
https://groups.google.com/g/comp.lang.forth/c/Fmr2UH5FeoE

Where he blames Swiftforth for having the VFX bug.
Well, then he called it a typo and started this one here.
Thank you very much for proving my point.
Sad to hear, but there we are.

[Hans Bezemer]

Double standards here. If I call Hugh 'a clever boy' he takes it for an insult, but if I call
myself 'a clever boy' he says I call myself an expert!

But anyways, you may call 4tH a 'toy compiler' - but at least I got my own compiler.
So I never have to complain the author put in a bug just to annoy me. I trust the guy
who made it, you know. Unconditionally, that is. Yeah, I'm a real humanitarian.

Hans Bezemer

[none albert]

In article <c8a05d29-d76c-4d43...@googlegroups.com>,

Hugh Aguilar <hughag...@gmail.com> wrote:
>I'm also looking into Ilya Tarasov's Ibris Forth (I'm likely the only
>person here
>who knows where the name "Ibris" comes from and thinks that it is a cool name).
>Forth has some kind of future that Stephen Pelc and his bug-ridden VFX
>will not be included in. Stephen Pelc was always a negative contributor to Forth
>because he purposely crippled Forth-200x in order to make VFX look good
>in comparison. So, good riddeance to Stephen Pelc and his salesman
>Juergen Pintaske!

I studied the code that the VFX compiler generates and I'm impressed.
Calling VFX "bug-ridden" makes you look like Trump.
I'm disappointed that you don't name me among the supporters of VFX.
Stephen Pelc has a valid business interest into Forth-200x and
he has contributed to the discussion. Standards are compromises and
it is no more than normal than that one of the two most important
commercial applications is taken into account.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

[dxforth]

On 5/02/2023 4:48 am, Hugh Aguilar wrote:
>
> DXforth said this earlier:
> On Thursday, January 12, 2023 at 5:44:22 PM UTC-7, dxforth wrote:
>> On 12/01/2023 10:35 pm, albert wrote:
>>> However if you do bother about ANS/ISO , then you can reap great benefit
>>> from the efforts within MPE to deliver a compiler that be standard.
>>> Even if you are not a paying customer.
>> The Standard and what it permits is too complicated for the average user
>> to understand. Implementers too, it would seem. ANS dug a hole so deep
>> it challenges everyone.
>
> This is just DXforth's endless stream of drivel about how much he hates the
> idea of a Forth standard, and how this puts his awesome creativity in a box.

I've not stopped anyone from using ANS/200x or from joining you in your 'standard
in opposition'. Nor has anyone. Any lack of success on those fronts lies at the
feet of their creators and not invented enemies. When the simplest explanation
is lack of interest, I go with that.

[Lorem Ipsum]

Wow! I literally don't know what to say. Hugh makes a couple of posts, and all the other nut cases start their jabbering again.

Sometimes I have to wonder about myself. I must be crazy to be any part of this nuthouse. I think I need to learn C++.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

[Hans Bezemer]

We love you too, Rick. ;-)

Hans Bezemer CLF <3 Rick

[dxforth]

On 6/02/2023 3:32 pm, Lorem Ipsum wrote:
>
> Wow! I literally don't know what to say. Hugh makes a couple of posts, and all the other nut cases start their jabbering again.
>
> Sometimes I have to wonder about myself. I must be crazy to be any part of this nuthouse. I think I need to learn C++.

You're saying you came to c.l.f. to learn Forth? Oy vey! How well did that
work out?

[Hans Bezemer]

On Monday, February 6, 2023 at 10:33:54 AM UTC+1, dxforth wrote:
> > Sometimes I have to wonder about myself. I must be crazy to be any part of this nuthouse. I think I need to learn C++.
> You're saying you came to c.l.f. to learn Forth? Oy vey! How well did that
> work out?

True. I learned Forth using this combo:
- Lots of text books (sorry - no internet in the days);
- Lots of trial and error (I call it "being raised by the compiler");
- Wil Baden;
- Occasional perls I find either here, Rosetta code or in FD.

I still think - seriously - too little stuff is posted here. And I can understand. There is no fun
in being beaten down (without alternative) when you're posting code. I loved the "I can write
the fastest SQRT" though. We should do that more often.

Hans Bezemer

P.S. I still love the rewritten CONCAT implementation. I don't mind being beaten down when it
results in better code. Hey, you may lose a few teeth, but at least you get a free beer!

[dxforth]

And even when no better solution is offered (few critics want to be that
invested), their gut reaction can still be honest and enough to spur one
to re-think the problem/proposition. I see c.l.f. as a sounding board.
Expecting it to be font of all wisdom (or even just interested), one is
likely to leave disappointed. So don't use it for that.

[Hugh Aguilar]

On Saturday, February 4, 2023 at 12:49:52 PM UTC-7, none albert wrote:
> In article <c8a05d29-d76c-4d43...@googlegroups.com>,
> Hugh Aguilar <hughag...@gmail.com> wrote:
> >I'm also looking into Ilya Tarasov's Ibris Forth (I'm likely the only
> >person here
> >who knows where the name "Ibris" comes from and thinks that it is a cool name).
> >Forth has some kind of future that Stephen Pelc and his bug-ridden VFX
> >will not be included in. Stephen Pelc was always a negative contributor to Forth
> >because he purposely crippled Forth-200x in order to make VFX look good
> >in comparison. So, good riddeance to Stephen Pelc and his salesman
> >Juergen Pintaske!

> I studied the code that the VFX compiler generates and I'm impressed.
> Calling VFX "bug-ridden" makes you look like Trump.

My novice-package worked fine in the past, and it still works on SwiftForth.
I made a lot of effort to ensure that the novice-package was fully ANS-Forth
compliant. Now it crashes on VFX in multiple places. This seems to be
POSTPONE LITERAL but I haven't delved into it deeply enough to be sure.
I really don't have time to debug VFX for Stephen Pelc, and I don't have the
source-code to VFX anyway --- Stephen Pelc needs to debug his bug-ridden VFX.
You "studied" VFX code??? Most likely you don't know what POSTPONE is.

I could just go back to the old version of VFX that still worked.
Hopefully Stephen Pelc still has this available on his MPE website.

> I'm disappointed that you don't name me among the supporters of VFX.

Okay.
You can make a spectacle of yourself on your knees for Stephen Pelc.
You are henceforth considered to be fully the peer of Juergen Pintaske,
Hans Bezemer and DXforth. You've earned it! Be pround of your achievement!

> Stephen Pelc has a valid business interest into Forth-200x and
> he has contributed to the discussion. Standards are compromises and
> it is no more than normal than that one of the two most important
> commercial applications is taken into account.

It is only normal for astroturf projects (corporate marketing gimmicks
promoted as being grassroots projects to lure in the foolish).

Stephen Pelc is in the business of selling VFX.
He wants Forth-200x to be crippled so he can tell his customers:
"You need to pay for VFX to get a useful Forth system. Forth-200x is
a toy language intended to teach novices the basics of Forth, so they can
apply for work as VFX programmers and at least know about DUP SWAP etc..
Play with gForth for a while, then upgrade to VFX when you have the money."

Rquotations are more important to the future of Forth than the Forth-200x standard.
Stephen Pelc accepted the Paysan-faked quotations into Forth-200x. That was
purposeful crippling of Forth-200x --- that is all that anybody needs to know about him.

> Don't praise the day before the evening. One swallow doesn't make spring.
> You must not say "hey" before you have crossed the bridge. Don't sell the
> hide of the bear until you shot it. Better one bird in the hand than ten in
> the air. First gain is a cat spinning. - the Wise from Antrim -

This goofy pseudo-philosophic blather definitely make you a peer of DXforth.
He is always spouting nonsense like this too.

[dxforth]

You could do with a one-line sig. It would leave room for something new.

[Jach Feng]

Lorem Ipsum 在 2023年2月6日 星期一中午12:32:19 [UTC+8] 的信中寫道：

Don't "think", just go ahead and learn C++. It may help your winkled mind from crazy:-)

--Jach

[Hugh Aguilar]

On Monday, February 6, 2023 at 10:27:02 PM UTC-7, Jach Feng wrote:
> Lorem Ipsum 在 2023年2月6日 星期一中午12:32:19 [UTC+8] 的信中寫道：
> > On Saturday, February 4, 2023 at 1:40:24 PM UTC-5, jpit...@gmail.com wrote:
> > > My knowledge of Forth is rather limited, just the basics;
> > > does it matter?

Yes, it does matter.

> > Sometimes I have to wonder about myself. I must be crazy to be any part of this nuthouse. I think I need to learn C++.

> Don't "think", just go ahead and learn C++. It may help your winkled mind from crazy:-)

Jach, you are not being realistic.
If Rick Collins wasn't smart enough to learn Forth, he isn't going to be smart enough
to learn C or C++. People of his skill level are normally provided with a simple
scripting language such as BASIC or Lua. This is why the BASIC Stamp was popular.

I don't think that anybody on comp.lang.forth is smart enough to learn Forth.
None of them are actually programming in Forth --- this is why none of them noticed
that VFX has serious bugs in POSTPONE LITERAL (and possibly any use of POSTPONE).
This is also why Stephen Pelc has enthusiastic supporters of his bug-ridden VFX who
hate me because I have pointed out that VFX has bugs and will no longer compile my
novice-package that is fully ANS-Forth compliant --- they aren't bothered by bugs in VFX
because they aren't using VFX to write Forth code anyway --- the bugs in VFX aren't
a problem for those who spend their time promoting VFX but who never have to
actually make any Forth code work on VFX.

Getting code to actually work is the difficult part of programming, so many "programmers"
avoid ever being put in a position where they have to do this --- this is why comp.lang.forth
is full of super-duper programming experts who never do any programming.

I put effort into writing my MSP-430 assembler, and now Stephen Pelc has sabotaged
my novice-package by releasing this new bug-ridden version of VFX that no longer
compiles my novice-package that I have been using under VFX for many years.
I think that he introduced these bugs on purpose to stop me from using VFX
to write code for the MSP-430 that would be in competition with his MSP-430
cross-compiler. Stephen Pelc is not the friend of the Forth community --- he considers
the Forth community to be his competition --- he sabotages the Forth community.

[dxforth]

On 8/02/2023 12:01 pm, Hugh Aguilar wrote:
>
> I don't think that anybody on comp.lang.forth is smart enough to learn Forth.
> None of them are actually programming in Forth --- this is why none of them noticed
> that VFX has serious bugs in POSTPONE LITERAL (and possibly any use of POSTPONE).

Your complaint is nobody has recently used the Novice Pack else they would have
noticed. That's very likely correct.

> Getting code to actually work is the difficult part of programming, so many "programmers"
> avoid ever being put in a position where they have to do this --- this is why comp.lang.forth
> is full of super-duper programming experts who never do any programming.

That's why the Novice Pack was created - to eliminate the difficulties. In telling
programmers they have neither the time nor need to re-invent the wheel, one is
creating the "super-duper programming experts" who have no experience they can rely
on or call their own because everything has come second-hand.

[Jan Coombs]

On Wed, 8 Feb 2023 14:54:06 +1100
dxforth <dxf...@gmail.com> wrote:

> In telling
> programmers they have neither the time nor need to re-invent the wheel, one is
> creating the "super-duper programming experts" who have no experience they can rely
> on or call their own because everything has come second-hand.

True, ISTR that Elizabeth Rather said it is easier to teach a person with system/domain specific product experience to write Forth than to teach a forth expert to pick up the domain specific knowledge.

Jan Coombs
--

[Anton Ertl]

Jan Coombs <jan4comp....@murray-microft.co.uk> writes:
>True, ISTR that Elizabeth Rather said it is easier to teach a person with system/domain specific product experience to write Forth than to teach a forth expert to pick up the domain specific knowledge.

That is certainly true for her: She is an expert in teaching Forth.

In general, if the programming part is simple, the approach outlined
above may work out. If the requirements on the programming are not so
simple, a domain expert with only a short programming education will
get the domain part right, but is likely to get in trouble in the
programming. Such jobs require the collaboration of a domain expert
and a programming expert.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

[Hugh Aguilar]

DXforth is a typical troll.
He routinely twists a person's words to seem as if he said something
that he did not say (usually the exact opposite of what he did say).
DXforth does to get a response from the person, then he twists this response
again to something else --- he continues doing this so long as he continues
to get responses --- this is the "troll game" that we see so often on comp.lang.forth
(and a big part of why I have lost interest in comp.lang.forth).

DXforth has his Z80 Forth that is most likely copied out of Loelliger's book:
"Threaded Interpretive Languages" (I read the book when I was still in high-school).
DXforth provides comp.lang.forth with an endless stream of drivel in which he
claims that his awesome creativity must never be put in a box by any Forth standard
or code-library, because he can write super-efficient programs that are "exactly right"
due to him writing them entirely from scratch (Elizabeth Rather says the same thing).
DXforth is a clown --- I want him to stop pestering me --- I want him to just go away.
Elizabeth Rather has gone away --- good riddance!

On Tuesday, February 7, 2023 at 8:54:10 PM UTC-7, dxforth wrote:
> On 8/02/2023 12:01 pm, Hugh Aguilar wrote:
> >
> > I don't think that anybody on comp.lang.forth is smart enough to learn Forth.
> > None of them are actually programming in Forth --- this is why none of them noticed
> > that VFX has serious bugs in POSTPONE LITERAL (and possibly any use of POSTPONE).

> Your complaint is nobody has recently used the Novice Pack else they would have
> noticed. That's very likely correct.

This is obviously not what I said. DXforth is a liar trying to put words in my mouth.
I said that nobody is doing any programming in VFX or they would have noticed
the bug in the new version VFX as soon as it came out (of, if they are programming
in VFX, they aren't using POSTPONE most likely because it is too advanced for them).

The point of this thread is that the new version of VFX has serious bugs.
The silence from Stephen Pelc is deafening!
Stephen Pelc obviously put these bugs in VFX to prevent my novice-package from working.
The bugs are in POSTPONE which is a crucial part of my early-binding MACRO: that
depends upon the disambiguifiers to be ANS-Forth compliant.
Stephen Pelc totally lied when he said that the disambiguifiers don't work.
The disambiguifiers fix the bug in ANS-Forth that makes FIND and tick ambiguous
and unusable on all of the words in ANS-Forth (51 of them) whose definition includes
the statement: "Interpretation semantics for this word are undefined."
https://groups.google.com/g/comp.lang.forth/c/T-yYkpVwYew/m/tNE4Q9aNDwAJ

> > Getting code to actually work is the difficult part of programming, so many "programmers"
> > avoid ever being put in a position where they have to do this --- this is why comp.lang.forth
> > is full of super-duper programming experts who never do any programming.

> That's why the Novice Pack was created - to eliminate the difficulties. In telling
> programmers they have neither the time nor need to re-invent the wheel, one is
> creating the "super-duper programming experts" who have no experience they can rely
> on or call their own because everything has come second-hand.

This is obviously not what I have ever said.
The novice-package was created to provide building blocks for writing programs,
so the programmer can concentrate on writing his program, rather than dinking around
with implementing data-structures that were invented decades ago.
I'm not writing people's programs for them.
The novice-package is not for script kiddies who want their program already written
for them, and who will then write simple scripts on top of the program.
People have to be able to write their own programs or the novice-package won't help them.

The novice package speeds up writing programs (certainly for me, as I don't have time
to reimplement basic data-structures over and over again). For example, I wrote my
<SWITCH with FAST-SWITCH> and SLOW-SWITCH> quickly using the novice-package.
Later on, for the sake of efficiency, I did go back and rewrite the code for doing a
binary-search to be "exactly right for the application.' Note however, that I did this
*after* I had the program working --- if I had to do this on my first attempt at writing
the program I would have likely become bogged down in writing the binary-search
which would have been a huge distraction from writing the SLOW-SWITCH> code.
Note also that Gerry Jackson has failed to write anything comparable to SLOW-SWITCH>
because he copied Michael Gassenenko's code that only had something comparable
to my FAST-SWITCH> and was not robust so it couldn't be upgraded to support
a sparse array, which is what SLOW-SWITCH> does. There is a big difference between
using a code-library (what I do) and copying somebody else's code (what Gerry Jackson
does, and what Elizabeth Rather described as: Having a lot of old programs in one's
back pocket, then reworking these old programs as slightly different new programs.)

As another example, I wrote HJA430 (my MSP-430 assembler) quickly because the
novice-package provided adequate data-structures (the bit-field struct helped a lot
in constructing the opcode). The code is straightforward and simple.
I was able to focus my mind on new ideas, such as implementing code blocks
(similar to C's code blocks but better). The assembler would have been much more
complicated if I had had to write everything from scratch without the novice-package.

The novice-package also makes these programs more efficient. Elizabeth Rather believes
that data-structures that are "exactly right for the application" will be super-efficient compared
to general-purpose data-structures that work for any application. She is wrong.
I put effort into making my novice-package efficient.
This is more effort than any application programmer is going to put in when writing
an application under deadline --- he can't tell the boss: "I will get started on my
assigned task as soon as I finish writing an array-definer and array-sort that is exactly right for
this application. I will start on the assigned task next week, unless something else comes up."

To keep his job he has to tell the boss that the task is finished at the end of the day:
"I have already finished the assigned task. I used a bubble-sort on the array of structs,
so it is slow as molasses, but Forth code is expected to be inefficient, so who cares?
Or:
"I have already finished the assigned task using an array definer provided
in the book: 'Starting Forth.' I also used Wil Baden's array-sort code, both of which
require the array element to be one-cell in size. An array of cells is really the wrong
data-structure for holding sorted structs and supporting insertion or removal of elements.
I finished my task quickly enough, but it will need to be rewritten from scratch by somebody
who knows more about Forth than what was described in: 'Starting Forth.'"
Or:
"I have already finished the assigned task. I used the novice-package so it is efficient."

[Hugh Aguilar]

On Wednesday, February 8, 2023 at 10:58:22 AM UTC-7, Anton Ertl wrote:
> Jan Coombs <jan4comp....@murray-microft.co.uk> writes:
> >True, ISTR that Elizabeth Rather said it is easier to teach a person with system/domain specific product experience to write Forth than to teach a forth expert to pick up the domain specific knowledge.

> That is certainly true for her: She is an expert in teaching Forth.
>
> In general, if the programming part is simple, the approach outlined
> above may work out. If the requirements on the programming are not so
> simple, a domain expert with only a short programming education will
> get the domain part right, but is likely to get in trouble in the
> programming. Such jobs require the collaboration of a domain expert
> and a programming expert.

What Anton Ertl said is true.

[dxforth]

On 9/02/2023 6:42 am, Hugh Aguilar wrote:
>
> DXforth provides comp.lang.forth with an endless stream of drivel in which he
> claims that his awesome creativity must never be put in a box by any Forth standard
> or code-library, because he can write super-efficient programs that are "exactly right"
> due to him writing them entirely from scratch (Elizabeth Rather says the same thing).

It's Moore who said it:

"all the programmers in the world are out there inventing for you, the general solution
[...] I have demonstrated in the past, ad nauseam, applications where I can reduce the
amount of code by 90% percent and in some cases 99%. It can be done, but in a case by
case basis."

And on the premise that the programmer should to do the thinking, Forth was created.
That's in stark contrast to most languages. It's perhaps testimony to the resilience
of Forth and its users that despite all the offers of 'an easier way' they prefer to
do it themselves. Which includes you. You claim the right to think for yourself but
would deny others the same. Leaders are like that.

[dxforth]

On 9/02/2023 6:42 am, Hugh Aguilar wrote:
>

> DXforth has his Z80 Forth that is most likely copied out of Loelliger's book:
> "Threaded Interpretive Languages" (I read the book when I was still in high-school).

Why the endless references to Loelliger? Let me guess. You read the book and decided
you would write a forth for your Kaypro. But as with all the forths you have threatened
to write you never got around to it and their ghosts haunt you.

[dxforth]

Never knew you were both so aligned in your thinking. With all this good
will there may be hope for 200x yet :) BTW what makes a programming expert?
ISTM many well-known programmers originally came from other domains.

[Hans Bezemer]

On Wednesday, February 8, 2023 at 8:42:14 PM UTC+1, Hugh Aguilar wrote:
> DXforth is a typical troll.

> DXforth is a clown --- I want him to stop pestering me --- I want him to just go away.

Ad hominem - so I'll just ignore that. Why do you want him to go away? I thought you'd
lost interest in c.l.f. - and yet: here we are.

> > Your complaint is nobody has recently used the Novice Pack else they would have
> > noticed. That's very likely correct.

I think I'd subscribe to that. It's a massive package and I don't really see the benefits of
it in my usual programming. But that's just me. Why don't you put it up in Github and see
how many people pick it up and discuss it? It would be real easy to end that discussion
with some actual numbers.

> The point of this thread is that the new version of VFX has serious bugs.

I only heard of one so far.

> Stephen Pelc obviously put these bugs in VFX to prevent my novice-package from working.
> The bugs are in POSTPONE which is a crucial part of my early-binding MACRO: that
> depends upon the disambiguifiers to be ANS-Forth compliant.
> Stephen Pelc totally lied when he said that the disambiguifiers don't work.
> The disambiguifiers fix the bug in ANS-Forth that makes FIND and tick ambiguous
> and unusable on all of the words in ANS-Forth (51 of them) whose definition includes
> the statement: "Interpretation semantics for this word are undefined."
> https://groups.google.com/g/comp.lang.forth/c/T-yYkpVwYew/m/tNE4Q9aNDwAJ

Well, if the standards state "Interpretation semantics for this word are undefined" then
that's the end of the line. You state yourself that's due to "a bug in ANS Forth". Hence,
if a compiler is ANS compliant, it will contain that "bug". So what is exactly bugging you:
the "bug" in ANS or the "bug" in VFX "not conforming to ANS. I lost track.

> The novice-package was created to provide building blocks for writing programs,
> so the programmer can concentrate on writing his program, rather than dinking around
> with implementing data-structures that were invented decades ago.
> I'm not writing people's programs for them.
> The novice-package is not for script kiddies who want their program already written
> for them, and who will then write simple scripts on top of the program.
> People have to be able to write their own programs or the novice-package won't help them.

Are we having a "naming problem" here? If the novice package is not targeted to newbies
or experts, what's its target audience?

> The novice package speeds up writing programs (certainly for me, as I don't have time
> to reimplement basic data-structures over and over again). For example, I wrote my
> <SWITCH with FAST-SWITCH> and SLOW-SWITCH> quickly using the novice-package.
> Later on, for the sake of efficiency, I did go back and rewrite the code for doing a
> binary-search to be "exactly right for the application.' Note however, that I did this
> *after* I had the program working --- if I had to do this on my first attempt at writing
> the program I would have likely become bogged down in writing the binary-search
> which would have been a huge distraction from writing the SLOW-SWITCH> code.
> Note also that Gerry Jackson has failed to write anything comparable to SLOW-SWITCH>
> because he copied Michael Gassenenko's code that only had something comparable
> to my FAST-SWITCH> and was not robust so it couldn't be upgraded to support
> a sparse array, which is what SLOW-SWITCH> does. There is a big difference between
> using a code-library (what I do) and copying somebody else's code (what Gerry Jackson
> does, and what Elizabeth Rather described as: Having a lot of old programs in one's
> back pocket, then reworking these old programs as slightly different new programs.)

Well, speed is your personal "thing". I know that different techniques scale differently.
E.g. a table to look up some options at the start of a program won't really benefit from
implementing a blindingly fast perfect hash algorithm. Even in its most primitive O(n)
form it's so fast users won't notice. Up to about 100 entries (in 4tH) CASE..OF will
beat any other lookup mechanism (apart from "direct access"). Binary searches will give
a decent performance for a wide range of values. Combined with hashes it's my preferred
technique for getting a good balance between speed, allocated memory and ease
of use (for the programmer).

I can't speak for others, but I got a number of datastructures that cater for that. I
recently analyzed a sizeable repository using a couple of 4tH programs in 15s. That's
hardly two gulps of coffee. Do you really think speeding that up 100 fold will significantly
change my working day?

> I was able to focus my mind on new ideas, such as implementing code blocks
> (similar to C's code blocks but better). The assembler would have been much more
> complicated if I had had to write everything from scratch without the novice-package.

Everybody has the tools he or she is comfortable with. I recently had a discussion about
the use of a REGEX package. Personally, I rarely use it. I have my own tools - and proved
this approach was viable. And that's the end of it. I'm not saying my approach should
rule the world. I'm saying "it works" - and should add: "for me". I don't think people should
be out to convert the world to THEIR approach, when other approaches are just as viable.
If it works for you: fine. If it works for others: even better. But never claim there are no
other viable alternatives.

> The novice-package also makes these programs more efficient. Elizabeth Rather believes
> that data-structures that are "exactly right for the application" will be super-efficient compared
> to general-purpose data-structures that work for any application. She is wrong.

Well, have you ever considered that she may not be wrong, but that sometimes "good is good
enough"? I like beating Python or Ruby over the head with their abysmal performance like any
other man, but I have to admit that sometimes other properties than just raw speed are more
important. And especially package-wise Python beats ANY Forth compiler.

> I put effort into making my novice-package efficient.

That's worth some praise.

> This is more effort than any application programmer is going to put in when writing
> an application under deadline --- he can't tell the boss: "I will get started on my
> assigned task as soon as I finish writing an array-definer and array-sort that is exactly right for
> this application. I will start on the assigned task next week, unless something else comes up."

True. That's why - in spite of the Forth myth that "one doesn't need libraries" I wrote
500+ of them. You'll see a whole bunch of includes in many of my programs. I
never regretted that. Recently I added LibreOffice Calc generation to a program of mine
by just adding one more "INCLUDE". Works like a charm. I can do the same for .XLS,
.RTF, .HTML or LaTeX. I need that more often for work than a "quick switch". But that's
me. That's my line of work. You don't have to agree with me.

> To keep his job he has to tell the boss that the task is finished at the end of the day:
> "I have already finished the assigned task. I used a bubble-sort on the array of structs,
> so it is slow as molasses, but Forth code is expected to be inefficient, so who cares?

In my experience delivery dates are more important in business than any other property.
It just has to work and it has to be released yesterday. That's why IMHO abstracted
functionality works (aka libs).

> "I have already finished the assigned task using an array definer provided
> in the book: 'Starting Forth.' I also used Wil Baden's array-sort code, both of which
> require the array element to be one-cell in size. An array of cells is really the wrong
> data-structure for holding sorted structs and supporting insertion or removal of elements.

4tH has index based sorting routines. It can handle ANY type of structure and does
the job "in place". I recently used it to sort a double cell array. Although Wil Badens
routines are just fine for many tasks, sometimes you don't want to deal with an extra
index array. I built a whole bunch of sorting routines on that protocol, so one can swap
routines by just including another lib.

> "I have already finished the assigned task. I used the novice-package so it is efficient."

More likely: "I've already finished the assigned task because even someone brainless
can use Python - and it's got a massive amount of libs I can pull in so I can pretend
I'm very computer literate. Never mind it runs for 15 minutes to finish the task". And note
I detest Python! You'll find me dead on my keyboard writing a Python program..

Hans Bezemer

[dxforth]

On 10/02/2023 2:40 am, Hans Bezemer wrote:
> On Wednesday, February 8, 2023 at 8:42:14 PM UTC+1, Hugh Aguilar wrote:
>> DXforth is a typical troll.
>> DXforth is a clown --- I want him to stop pestering me --- I want him to just go away.
> Ad hominem - so I'll just ignore that. Why do you want him to go away? I thought you'd
> lost interest in c.l.f. - and yet: here we are.
>
>>> Your complaint is nobody has recently used the Novice Pack else they would have
>>> noticed. That's very likely correct.
> I think I'd subscribe to that. It's a massive package and I don't really see the benefits of
> it in my usual programming. But that's just me. Why don't you put it up in Github and see
> how many people pick it up and discuss it? It would be real easy to end that discussion
> with some actual numbers.

I think it's very tricky writing something with the expectation others will use it.
In Forth the odds are the same as winning the lottery. I'll happily squirrel away
small routines I think I may one day need, but asking me to buy into a mindset that's
not my own isn't going to happen. I suspect that's true for most forthers. If we're
prepared to split over things like a standard, then it shouldn't come as a surprise.
If I see someone using their routines in their daily work they have my applause
because the former is all that matters.

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>BTW what makes a programming expert?

From <https://en.wikipedia.org/wiki/Expert>:

|An expert is somebody who has a broad and deep understanding and
|competence in terms of knowledge, skill and experience through
|practice and education in a particular field.

[Hans Bezemer]

On Friday, February 10, 2023 at 11:21:43 AM UTC+1, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
> >BTW what makes a programming expert?
> From <https://en.wikipedia.org/wiki/Expert>:
>
> |An expert is somebody who has a broad and deep understanding and
> |competence in terms of knowledge, skill and experience through
> |practice and education in a particular field.

Anton, I *really* like the way you're thinking, man! A good definition is
generally accepted - and agreeing on the definition is a prerequisite for
starting any sensible discussion.

However, in this case I'm afraid the dispute will focus on what constitutes
a "broad and deep understanding and competence". Without any criteria for
establishing that I'm afraid we're back to square one.

Because the person in question can (and probably will) state that "your
understanding and competence is neither broad nor deep enough".
(Where "your" is the placeholder for the particular opponent he addresses
at that particular moment - could be any of us).

Hans Bezemer

[Marcel Hendrix]

On Friday, February 10, 2023 at 3:05:37 PM UTC+1, Hans Bezemer wrote:
> On Friday, February 10, 2023 at 11:21:43 AM UTC+1, Anton Ertl wrote:
> > dxforth <dxf...@gmail.com> writes:

[..]

>Because the person in question can (and probably will) state that "your
>understanding and competence is neither broad nor deep enough".

One is not an expert by declaring to be one, but because *others*
are of that opinion. That solves it.

-marcel

[Hans Bezemer]

It's a bit post-modern, but by definition any criteria are chosen and hence
profoundly arbitrary. I can live with it. Now, can we start the roasting? ;-)

Hans Bezemer

[Zbig]

I discovered today SmithForth https://dacvs.neocities.org/SF/ https://www.youtube.com/watch?v=a1UWxa2g9Us

Maybe this one will be nicer host for „novice package”? Not examined it yet, though.

[Anton Ertl]

Hans Bezemer <the.bee...@gmail.com> writes:
>On Friday, February 10, 2023 at 11:21:43 AM UTC+1, Anton Ertl wrote:
>> dxforth <dxf...@gmail.com> writes:
>> >BTW what makes a programming expert?
>> From <https://en.wikipedia.org/wiki/Expert>:
>>
>> |An expert is somebody who has a broad and deep understanding and
>> |competence in terms of knowledge, skill and experience through
>> |practice and education in a particular field.

...

>However, in this case I'm afraid the dispute will focus on what constitutes
>a "broad and deep understanding and competence". Without any criteria for
>establishing that I'm afraid we're back to square one.

Considering the original issue, it's the manager of the project who
has to decide if the project requires a programming expert on the
team, and if so, who is competent enough to be the programming expert.
Likewise for domain expertise.

Those interested in programming expertise (and expertise in general)
may find <https://norvig.com/21-days.html> interesting. My takeaway
from that is that if you take, say, a mechanical engineer without
programming background and let Elizabeth Rather teach them Forth for a
few weeks, the ME will not be programming experts after that, no
matter how good Elizabeth Rather teaches.

This reminds me of the course "Roboter" (robots) I took as a CS
student. The course was held from an ME group and there were ME
students and CS students on the course. We got our grade (for four
semester-hours, which typically takes 150 hours of work) by
programming a robot in a BASIC-like language. My group consisted of
two CS students (don't remember if we also had an ME student in the
group, if so, he was not able to contribute), and we completed the
task with little preparation in 2 hours (with a time limit of four),
while the ME-only groups where having a much harder time, and I could
see why it was a 4 semester-hour course for them. My guess is that
this happened to be easy for the CS people, because the ME part was
easy even for us, and the CS part was easy for us, but not for the ME
students; if the task had been to do something that requires solving
some more involved ME problem and a bit of easy programming, the table
would have been reversed.

[dxforth]

On 11/02/2023 10:10 am, Anton Ertl wrote:
> Hans Bezemer <the.bee...@gmail.com> writes:
>> On Friday, February 10, 2023 at 11:21:43 AM UTC+1, Anton Ertl wrote:
>>> dxforth <dxf...@gmail.com> writes:
>>>> BTW what makes a programming expert?
>>> From <https://en.wikipedia.org/wiki/Expert>:
>>>
>>> |An expert is somebody who has a broad and deep understanding and
>>> |competence in terms of knowledge, skill and experience through
>>> |practice and education in a particular field.
> ...
>> However, in this case I'm afraid the dispute will focus on what constitutes
>> a "broad and deep understanding and competence". Without any criteria for
>> establishing that I'm afraid we're back to square one.
>
> Considering the original issue, it's the manager of the project who
> has to decide if the project requires a programming expert on the
> team, and if so, who is competent enough to be the programming expert.
> Likewise for domain expertise.

Yes but one can't 'dial an expert'. Even Marcel's reputation-based
expertise is risky if it's not first-hand knowledge. How many boards of
companies have come unstuck because they chose a CEO based on reputation.
Cultivating reputation is one of the oldest tricks. There was a case
several years ago of an expert (medical IIRC) whose reputation derived
entirely from publishing papers in journals. So many of them that his
name was on everyone's lips. Problem was it was all smoke and mirrors.

[none albert]

In article <c6683797-07da-40eb...@googlegroups.com>,

Hans Bezemer <the.bee...@gmail.com> wrote:
>On Friday, February 10, 2023 at 11:21:43 AM UTC+1, Anton Ertl wrote:
>> dxforth <dxf...@gmail.com> writes:
>> >BTW what makes a programming expert?
>> From <https://en.wikipedia.org/wiki/Expert>:
>>
>> |An expert is somebody who has a broad and deep understanding and
>> |competence in terms of knowledge, skill and experience through
>> |practice and education in a particular field.
>Anton, I *really* like the way you're thinking, man! A good definition is
>generally accepted - and agreeing on the definition is a prerequisite for
>starting any sensible discussion.
>
>However, in this case I'm afraid the dispute will focus on what constitutes
>a "broad and deep understanding and competence". Without any criteria for
>establishing that I'm afraid we're back to square one.

You buy a dictionary, that is words defined with the help of other words.
There is no going around that.

<SNIP>
>
>Hans Bezemer
>

Groetjes Albert
--

[Hans Bezemer]

On Saturday, February 11, 2023 at 9:42:46 AM UTC+1, none albert wrote:
> >However, in this case I'm afraid the dispute will focus on what constitutes
> >a "broad and deep understanding and competence". Without any criteria for
> >establishing that I'm afraid we're back to square one.
> You buy a dictionary, that is words defined with the help of other words.
> There is no going around that.

It's true that dictionaries and encyclopedias are a good source for well-established
and generally accepted definitions. The object of a good definition is to make the
distinction between "this is one and this is not one". We have to accept though that
outside the realm of science lots of concepts have a loose meaning - and are
consequently used quite loosely. Dictionaries reflect that.

Definitions can be classified in three ways (in order of diminishing strength):
- An intensional definition lists the necessary properties of of a concept. In other
words, you have to tick a number of boxes. In other words: all the members of this
set share the same properties;
- An extensional definition lists ALL members of that set by their identifiers;
- An ostensive definition lists one or more members of that set. Also called "definition
by pointing".

The definition of the expert listed is intensional - it lists the properties of members of
this set. The problem of intensional definitions is that you may introduce concepts
that have to be defined by themselves. In this case: what constitutes "broad and deep
understanding and competence"? Since that remains undefined we have a possible
source of discussion. And now the ugly face of the "loose meanings" rises its head.

You may have an entirely different concept of what "broad and deep understanding
and competence" than I do. I once had a problem with the optimizer of MariaDB. I'd
gotten all the EXPLAIN dumps and I couldn't figure out why it behaved like that. "No
problem" a co-worker said "We got this guy coming in and he knows EVERYTHING
about MariaDB. He's really a top expert."

So the guy came in, I explained the problem to him, showed him the dumps and he
sighed "This is way, way over my head". Well, I don't consider myself to be anywhere
near an expert on SQL-DBs, since I know there are guys who are better. And in my
rulebook, if I know someone who is better than me, I don't consider myself to be an
expert. But opinions differ ;-)

And that's why it's hard to classify anyone or anything with any confidence
without ironclad criteria.

Psychologists hate me. I'm unable to make any of their tests without bombarding
them with questions they cannot answer. If even you don't know, how can I ever
answer them with any confidence. If you require me to "guess" all I need is a dice.

Hans Bezemer

[dxforth]

On 11/02/2023 10:46 pm, Hans Bezemer wrote:
>
> Psychologists hate me. I'm unable to make any of their tests without bombarding
> them with questions they cannot answer. If even you don't know, how can I ever
> answer them with any confidence. If you require me to "guess" all I need is a dice.

Why should they hate you - did you imagine you beat them? :)

[Hans Bezemer]

Psychologists hate anything that exposes them as a "cargo cult science". Ask Feynman.

Hans Bezemer

[Hugh Aguilar]

On Saturday, February 11, 2023 at 4:46:28 AM UTC-7, Hans Bezemer wrote:
> On Saturday, February 11, 2023 at 9:42:46 AM UTC+1, none albert wrote:
> > >However, in this case I'm afraid the dispute will focus on what constitutes
> > >a "broad and deep understanding and competence". Without any criteria for
> > >establishing that I'm afraid we're back to square one.
> > You buy a dictionary, that is words defined with the help of other words.
> > There is no going around that.
> It's true that dictionaries and encyclopedias are a good source for well-established
> and generally accepted definitions. The object of a good definition is to make the
> distinction between "this is one and this is not one". We have to accept though that
> outside the realm of science lots of concepts have a loose meaning - and are
> consequently used quite loosely. Dictionaries reflect that.
>
> Definitions can be classified in three ways (in order of diminishing strength):
> - An intensional definition lists the necessary properties of of a concept. In other
> words, you have to tick a number of boxes. In other words: all the members of this
> set share the same properties;
> - An extensional definition lists ALL members of that set by their identifiers;
> - An ostensive definition lists one or more members of that set. Also called "definition
> by pointing".
>
> The definition of the expert listed is intensional - it lists the properties of members of
> this set. The problem of intensional definitions is that you may introduce concepts
> that have to be defined by themselves. In this case: what constitutes "broad and deep
> understanding and competence"? Since that remains undefined we have a possible
> source of discussion. And now the ugly face of the "loose meanings" rises its head.

The silence from Stephen Pelc is deafening!

He isn't going to fix the bug (or bugs) in VFX that prevent VFX from compiling
ANS-Forth code. His bug specifically hits my early-binding MACRO: that I was able to
write in ANS-Forth. Everybody else, including him, have failed. I only succeeded
because I had my disambiguifiers to fix the problem in ANS-Forth of FIND not working.
Now my heavy use of POSTPONE no longer works under VFX, although it did work
previously, and it still works under SwiftForth. This is why Stephen Pelc introduced
the POSTPONE bug into VFX.

In comp.lang.forth, any thread that involves technical issues related to Forth will
quickly get hijacked by pseudo-intellectual blither-blather. The comp.lang.forth trolls
enjoy debates that allow them to represent themselves as big programming experts
without requiring them to do any programming. This debate on the definition
of 'expert' is pretty typical of comp.lang.forth. By debating the definition of 'expert'
the trolls presume that they are experts (how would a troll know what an expert is
without being an expert?). Presumably the purpose of this discussion is to conclude
that I'm not an expert. Defeated again! Bugs remain in VFX and Stephen Pelc wins!
"And now the ugly face of the 'loose meanings' rises its head." lol

[dxforth]

What profession doesn't lay claim to have 'science' behind it? It's a free
pass to acceptance. It's the new God. It wasn't always so. I suspect we're
conditioned to accept whatever society has told us to accept and science is
currently it. I'm not against facts but most of our problems appear to be
psychological ones for which science has no answer.

[Brian Fox]

On Saturday, February 11, 2023 at 6:44:43 PM UTC-5, Hugh Aguilar wrote:
> The silence from Stephen Pelc is deafening!

Maybe it has something to do with the fact the Stephen has retired to the south of Spain.
There can come a time in ones life where Forth is not the most important thing.
:-)

[Jurgen Pitaske]

As his facebook says:
Managing Director at Microprocessor Engineering Ltd
1982 to present.

So, we all somehow missed his 40 years of MD of MPE.
Belated congratulations from me anyway.

And see his life in the South here
https://www.facebook.com/stephen.pelc.7/about

Is this comparable to the person who was fired from Testra
probably about 40 years ago ...

[Lorem Ipsum]

Try to tell that to Jurgen!

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

[Hugh Aguilar]

That isn't true.
Stephen Pelc came out with this recent bug-ridden version of VFX.
If he has time to come out with a new version, he has time to fix the bugs in it.
He isn't fixing the bugs in VFX though, which means that he wants the bugs in VFX.

I think that he put the bugs into VFX purposefully to sabotage my novice-package.
I'm just glad that I never paid for the professional version of VFX, but continued
using the free evaluation version. I can only imagine the anguish of MPE customers
who paid good money for this bug-ridden VFX, only to be told that Stephen Pelc
is retired in southern Spain and no longer considers Forth to be important.

[dxforth]

Not everyone is going to respond to an invitation to a show-down on main
street! In a c.l.f. post (a few months ago?) Stephen said he would
continue to maintain VFX despite the move to Spain. Based on an email
reply I received from Stephen two weeks ago, he is still accepting bug
reports. A recent post on the VFX forum suggests he may be currently
busy migrating servers.

[Jurgen Pitaske]

I find it laughable that an idiot here, called Hugh Aguilar,
can throw shit at the company MPE for at least 10 years
that I was here
- and this is acceptable for many.

MPE is one of the few Forth companies left and should be supported.
MPE and the people there are not the only ones who moved out of the UK after Brexit.
And Stephen described some of the reasons why anyway.
And independent of this
- MPE decides what they like. This is what you call a business.
Rather than a plumber and taxi driver.

And about bugs in a new version:
tell me one software that had a new version out and no issues come up.

And even if there is an issue regarding this package that nobody really uses -
show your competence and sort it out.

In these times when everything is in the media,
on facebook and elsewhere:
ONLY THE FORTKILLER HUGH AGUILAR HAS COME OUT WITH A POTENTIAL ISSUE.
So, no issues anywhere else.
I can only laugh and laugh.

It looks like unintentional
PAYBACK TIME FOR HIM AFTER THROWING SO MUCH SHIT AT ANYBODY HERE.
AND EVERYBODY LIES ANYWAY if it does not fit..

[Jurgen Pitaske]

You are really a rather disturbed brain.
It was rather nice when you stayed away from here.

[Hans Bezemer]

On Sunday, February 12, 2023 at 12:44:43 AM UTC+1, Hugh Aguilar wrote:
> The silence from Stephen Pelc is deafening!
> He isn't going to fix the bug (or bugs) in VFX that prevent VFX from compiling
> ANS-Forth code.

Did anyone ever tell you you are like a broken record player? You return to the same
issue over and over again without adding any additional arguments like some entitled
princess complaining the Porsche 911 she got from daddy for her sixteenth birthday
doesn't have the right shade of pink. By your own admission - you're not even a paying
customer.

> In comp.lang.forth, any thread that involves technical issues related to Forth will
> quickly get hijacked by pseudo-intellectual blither-blather.

As a matter of fact, it's just stuff from a freshman's textbook. Quite basic. It's relevant
for e.g. setting up a language standard like ANS Forth - so it becomes as unambiguous
as possible. That you don't understand it and is hence unimportant is just a fallacy of
incredulity - and frankly, quite insulting to the people who built this knowledge and use
it on a daily basis in their professional work.

The comp.lang.forth trolls
> enjoy debates that allow them to represent themselves as big programming experts
> without requiring them to do any programming.

Well, given the number of vicious "ad hominem" from your side, I would like to reconsider
who the troll is here. And frankly, if that's all you have to discuss here, I'd be happy to
see a c.l.f. without you. Because besides these attacks, you seem to have very little to
contribute.

What's the last time you posted some interesting code here? Apart from your brilliant
"NOVICE" package that nobody seems to be using. You know, no matter hoe smart you
are, no matter how clever your code is, the bottom line is, code is only valuable when it
is used.

Now let's put forward some of the things people have done here:
(1) They wrote their own compiler;
(2) They voted on extensions to the standard;
(3) They submitted extensions to the standard;
(4) They wrote (parts of) the standard;
(5) They contributed code to this forum;
(6) They wrote articles on Forth;
(7) They wrote papers on Forth;
(8) They wrote tutorials on Forth;
(9) They made presentations on Forth;
(10) They are respected by their peers for their knowledge.

So Hugh, how many boxes do you tick? And what makes you assume that you are an
expert on Forth - or are entitled to bear that title proudly among your peers? What
have you actually contributed to the world?

> Presumably the purpose of this discussion is to conclude that I'm not an expert.

You can presume all you want. That doesn't mean that it's true. The point is, you
maneuvered yourself there by insisting that the label "expert" is important. That
means you're probably very dependent on the opinions of the people you are
consistently antagonizing.

I'm not. I don't care what you or others think. I never have. I'm merely having fun in
what I'm doing - and have been doing so for the last 30 years - and whatever you think,
it has no relevance in my life, because it won't make me change my ways. Not in the
slightest. If that had been of any importance to me I would have stopped doing it
for years.

You on the other hand, are craving for attention and recognition. You're screaming
for it from the top of your lungs.

Hans Bezemer

[Lorem Ipsum]

It's nice when people like you don't respond. You talk about others being monkeys throwing shit, then you pick it up and throw it around some more.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

[Jurgen Pitaske]

You are probably right.
I really do admire the highly intelligent and inspring summary of your comments here in this thread:

It is very regrettable though to see that 2 lines is the maximum you can produce.

1
Lorem Ipsum
6 Feb 2023, 04:32:19 (7 days ago)
Wow! I literally don't know what to say. Hugh makes a couple of posts, and all the other nut cases start their jabbering again.

Sometimes I have to wonder about myself. I must be crazy to be any part of this nuthouse. I think I need to learn C++.

2
Lorem Ipsum
unread,
12 Feb 2023, 21:59:01 (10 hours ago)

Try to tell that to Jurgen!

Rick C.

3

[Hugh Aguilar]

On Monday, February 13, 2023 at 12:41:01 AM UTC-7, Hans Bezemer wrote:
> On Sunday, February 12, 2023 at 12:44:43 AM UTC+1, Hugh Aguilar wrote:
> > The silence from Stephen Pelc is deafening!
> > He isn't going to fix the bug (or bugs) in VFX that prevent VFX from compiling
> > ANS-Forth code.
> Did anyone ever tell you you are like a broken record player? You return to the same
> issue over and over again without adding any additional arguments like some entitled
> princess complaining the Porsche 911 she got from daddy for her sixteenth birthday
> doesn't have the right shade of pink. By your own admission - you're not even a paying
> customer.

Stephen Pelc's VFX is failing to compile legal ANS-Forth code.
See this page: https://www.mpeforth.com/software/pc-systems/vfx-forth-common-features/
The liar Stephen Pelc describes VFX as: "ANS standard Forth with many extensions."
If he is going to abandon ANS-Forth compliance, he should admit this publicly.
Stop lying to his potential customers that VFX is ANS-Forth compliant.
Anybody who paid for VFX should demand their money back because of Stephen Pelc's
false and deceptive advertising.
Stephen Pelc knows very little about ANS-Forth from a technical perspective,
and he doesn't care because he wants VFX to be the only Forth system available.

> The comp.lang.forth trolls
> > enjoy debates that allow them to represent themselves as big programming experts
> > without requiring them to do any programming.

> Now let's put forward some of the things people have done here:

> (2) They voted on extensions to the standard;
> (3) They submitted extensions to the standard;
> (4) They wrote (parts of) the standard;

> (6) They wrote articles on Forth;
> (7) They wrote papers on Forth;
> (8) They wrote tutorials on Forth;
> (9) They made presentations on Forth;
> (10) They are respected by their peers for their knowledge.

All of these are what I described above --- pseudo-intellectual blither-blather
that allows the fake experts to represent themselves as big programming experts

without requiring them to do any programming.

On Monday, February 13, 2023 at 12:41:01 AM UTC-7, Hans Bezemer wrote:
> (1) They wrote their own compiler;

Your 4TH is a byte-code VM written in C.
This doesn't qualify you as a Forth expert --- you are a perpetual novice.

On Monday, February 13, 2023 at 12:41:01 AM UTC-7, Hans Bezemer wrote:
> (5) They contributed code to this forum;

All of the code posted on comp.lang.forth is crap.

For example, we have Bernd Paysan's fake quotations that don't have access
to the parent function's local variables.

As another example, we have Anton Ertl's early-binding macro facility that lacks
support for literal numbers or support for words that extract data from the
input stream (words such as: [CHAR] ['] / ( S" C" ." ABORT" POSTPONE etc.).

As yet another example, we have Wil Baden's string-stack.
He doesn't know what COW (copy-on-write) is. You don't know either.
Nobody on comp.lang.forth knows basic programming concepts such as this.

[Hans Bezemer]

On Saturday, February 18, 2023 at 4:53:13 AM UTC+1, Hugh Aguilar wrote:
> Stop lying to his potential customers that VFX is ANS-Forth compliant.

You're not a paying customer, pal.

> Anybody who paid for VFX should demand their money back because of Stephen Pelc's
> false and deceptive advertising.

Which automatically excludes you.

> Stephen Pelc doesn't care because he wants VFX to be the only Forth system available.
With people like you - who don't write their own compiler - he MIGHT get there.

> All of these are what I described above --- pseudo-intellectual blither-blather
> that allows the fake experts to represent themselves as big programming experts
> without requiring them to do any programming.

If you're not happy, make a better list, which may be objectively scored - and defend why
it is a better list. I'm NOT getting an answer here, I know it.

> On Monday, February 13, 2023 at 12:41:01 AM UTC-7, Hans Bezemer wrote:
> > (1) They wrote their own compiler;
> Your 4TH is a byte-code VM written in C.

Yes - and you didn't produce anything at all in that regard. I win!

> For example, we have Bernd Paysan's fake quotations that don't have access
> to the parent function's local variables.

People who use local variables are sissies ;-)

> As yet another example, we have Wil Baden's string-stack.

You got three string stacks of mine as well.

> He doesn't know what COW (copy-on-write) is. You don't know either.

I know that overcomplicating code is your personal hobby.

Ok, I've been throwing around enough insults today. I feel rejuvenated, like I'm back
in the schoolyard again. Your turn!

Hans Bezemer

[dxforth]

On 18/02/2023 2:53 pm, Hugh Aguilar wrote:
> ...

> On Monday, February 13, 2023 at 12:41:01 AM UTC-7, Hans Bezemer wrote:
>> (5) They contributed code to this forum;
>
> All of the code posted on comp.lang.forth is crap.
>
> For example, we have Bernd Paysan's fake quotations that don't have access
> to the parent function's local variables.
>
> As another example, we have Anton Ertl's early-binding macro facility that lacks
> support for literal numbers or support for words that extract data from the
> input stream (words such as: [CHAR] ['] / ( S" C" ." ABORT" POSTPONE etc.).
>
> As yet another example, we have Wil Baden's string-stack.
> He doesn't know what COW (copy-on-write) is. You don't know either.
> Nobody on comp.lang.forth knows basic programming concepts such as this.

Speaking of code posted on c.l.f. Even a novice might baulk at a float-to-string
routine that can't display numbers to the precision of the system. Then there's
the limitation stemming from the use of F>D and the inability to handle INF/NAN.
Here's a possible solution to the first problem. The remainder I leave to you.

: ~# ( Da -- Db ) \ needs ~#SOFT set
0 10 um/mod >r 10 um/mod r> rot
~#soft if
dup if false to ~#soft else drop exit then
then
[char] 0 + hold ;

pi 15 0 <scientific> type 3.14159265358979 ok

Previously:

pi 15 0 <scientific> type INTEGER_OVERFLOW at 004998D6 ~# +39
Registers Dstack esp+ Rstack
EAX E76A2483 00011DB9 0000 00499F80 <scientific> +785
EBX 0000000A E76A2483 0004 7FFFFFF2
ECX 0000002C 00011DB9 0008 8000000F
EDX 00011DB9 E76A2483 000C 00439DEC <<locals>> 4
ESI 00422814 00368000 0028 0041D1B7 WORD-INTERPRETER +24
EDI 00414000 76B300F9 002C 0041D248 (INTERPRETING) +73
EBP 0019FF60 00368000 0030 0041D36B INTERPRET +28
ESP 00197EF0 76B300E0 0034 0041D4DF (QUIT) +16
EFL 00210206 0019FFDC 0038 0041530F CATCH +64
EIP 004998D6 77E17BBE 003C 00197F2C
00368000 0040 00414000
995A2255 0044 00422814 %SwiftForth\src\kernel\win32\start.f +9
00000000 0048 0019FF70
00000000 004C 00000000
00368000 0050 00000000
00000000 0054 00000000
00000000 0058 00000000
00000000 005C 00467884 SIMPLE-GUI +5
00000000 0060 00424E54 %SwiftForth\src\kernel\win32\start.f +9801
00000000 0064 FFFF037F

[Hugh Aguilar]

On Sunday, February 19, 2023 at 6:58:45 PM UTC-7, dxforth wrote:
> On 18/02/2023 2:53 pm, Hugh Aguilar wrote:
> > ...
> > On Monday, February 13, 2023 at 12:41:01 AM UTC-7, Hans Bezemer wrote:
> >> (5) They contributed code to this forum;
> >
> > All of the code posted on comp.lang.forth is crap.
> >
> > For example, we have Bernd Paysan's fake quotations that don't have access
> > to the parent function's local variables.
> >
> > As another example, we have Anton Ertl's early-binding macro facility that lacks
> > support for literal numbers or support for words that extract data from the
> > input stream (words such as: [CHAR] ['] / ( S" C" ." ABORT" POSTPONE etc.).
> >
> > As yet another example, we have Wil Baden's string-stack.
> > He doesn't know what COW (copy-on-write) is. You don't know either.
> > Nobody on comp.lang.forth knows basic programming concepts such as this.
> Speaking of code posted on c.l.f. Even a novice might baulk at a float-to-string
> routine that can't display numbers to the precision of the system. Then there's
> the limitation stemming from the use of F>D and the inability to handle INF/NAN.
> Here's a possible solution to the first problem. The remainder I leave to you.

I've never taken advice from a maintenance programmer, and I never will.
I figure things out for myself.
I would appreciate it if you keep your advice to yourself, smirking troll!

The bottom line is that Stephen Pelc advertises VFX as being ANS-Forth
compliant, but VFX fails to compile ANS-Forth code.

[dxforth]

On 21/02/2023 9:10 am, Hugh Aguilar wrote:
> On Sunday, February 19, 2023 at 6:58:45 PM UTC-7, dxforth wrote:
>> On 18/02/2023 2:53 pm, Hugh Aguilar wrote:
>>> ...
>>> On Monday, February 13, 2023 at 12:41:01 AM UTC-7, Hans Bezemer wrote:
>>>> (5) They contributed code to this forum;
>>>
>>> All of the code posted on comp.lang.forth is crap.
>>>
>>> For example, we have Bernd Paysan's fake quotations that don't have access
>>> to the parent function's local variables.
>>>
>>> As another example, we have Anton Ertl's early-binding macro facility that lacks
>>> support for literal numbers or support for words that extract data from the
>>> input stream (words such as: [CHAR] ['] / ( S" C" ." ABORT" POSTPONE etc.).
>>>
>>> As yet another example, we have Wil Baden's string-stack.
>>> He doesn't know what COW (copy-on-write) is. You don't know either.
>>> Nobody on comp.lang.forth knows basic programming concepts such as this.
>> Speaking of code posted on c.l.f. Even a novice might baulk at a float-to-string
>> routine that can't display numbers to the precision of the system. Then there's
>> the limitation stemming from the use of F>D and the inability to handle INF/NAN.
>> Here's a possible solution to the first problem. The remainder I leave to you.
>
> I've never taken advice from a maintenance programmer, and I never will.
> I figure things out for myself.

You had 14 years to figure it out.

> The bottom line is that Stephen Pelc advertises VFX as being ANS-Forth
> compliant, but VFX fails to compile ANS-Forth code.

Bottom line is Stephen accepts bug reports and even corrections. That's more
than can be said of certain drama queens.

[Hans Bezemer]

On Tuesday, February 21, 2023 at 3:16:38 AM UTC+1, dxforth wrote:
> > I've never taken advice from a maintenance programmer, and I never will.
> > I figure things out for myself.
> You had 14 years to figure it out.

Well, the "maintenance programmer" has his own Forth compiler. The "maintenance
programmer" wrote lots of code (most significantly in number representation) that
are thankfully used by lots of people in the Forth community. If that is the difference
between and "expert" and a "maintenance programmer", I take the "maintenance
programmer" every time.

You see, Hugh, in my world I don't actually care what other people think of people,
what education they have or how many years they spend in the field. I only care
for the crafts and knowledge they bring to the table.

And that's the bottom line. You'd probably do a great job as chairman of the board.
They don't get a lot of work done either, but they compensate that by (bad) talking
a LOT!

Hans Bezemer

[none albert]

In article <c71eeceb-54f8-4ab1...@googlegroups.com>,

Hugh Aguilar <hughag...@gmail.com> wrote:
>I've never taken advice from a maintenance programmer, and I never will.
>I figure things out for myself.

In the 40 years I have worked with all kind of industries, the truth
is you have to build on work of others 80% of the time.
I guess I am a 80% maintenance programmer.

Small wonder that you can't find a job with such attitude.

[Hugh Aguilar]

Here is another bug in VFX:
--------------------------------------
: ttt ( n -- ) 0 <# #S #> ; ok

1234567890 ttt 2dup type 1234567890 ok-2
2dup type 1234567892 ok-2
--------------------------------------

I told Stephen Pelc about this bug many years ago. He never fixed it.
He is stupidly using <# #> internally to print the stack depth (the "ok-2").
<# #> uses a static global pad. So, the string returned by TTT gets over-written.
The next time that I TYPE this string it has been over-written by the '2'.
Stephen Pelc doesn't care about fixing bugs --- he just considers VFX to be
a cash cow that can be milked forever, with no further effort on his part.

As far back as 1984 when I first learned Forth on the Vic-20 (HES Forth),
I was aware of the problem with using global variables such as the <# #> pad
or PAD etc.. In those days, Forth was still taken seriously. It was possible to
find Forth programmers just by speaking to any driver with the bumper sticker:
"Forth love if honk then"
I pointed out to a college student at Isla Vista the problem with Forth-83
storing temporary data in PAD and the <# #> pad that are global. He said that
the Vic-20 had only 5KB of RAM available, so this kludge was necessary. He also
said that Forth-83 had a lot of known problems, but these problems would be fixed
in the upcoming Forth standard. What I didn't know at the time (most likely he and the
rest of the Forth community didn't know either), was that Charles Moore had been
kicked out of Forth Inc. in 1982, leaving Elizabeth Rather in charge. All of the bugs
in the Forth-83 standard are there because Elizabeth Rather is a typical maintenance
programmer who tries to keep old software going forever despite not understanding
how the software works. She didn't understand that Charles Moore made the <# #>
pad and PAD static globals because he was programming a 1970s vintage computer
with only a few KB of RAM and/or because he was programming an application under
a deadline and didn't have time to do the job right. Gross ignorance of basic programming
is why she put this bad idea in Forth-83. Her Forth-83 standard was just an effort to declare
PolyForth to be the standard. She knew nothing about Forth programming!

I been told in 1984 that a new Forth standard would soon arrive to fix the many
known problems in Forth-83. ANS-Forth finally arrived in 1994. Elizabeth Rather was still
in charge, and so ANS-Forth had all of the same problems as Forth-83, plus a raft of
new problems (ANS-Forth was ambiguous about almost everything, and FIND didn't
work anymore). The only purpose of ANS-Forth was to declare UR/Forth to be
non-standard and kill UR/Forth despite the fact that it was the flagship of Forth.
Elizabeth Rather assumed that when UR/Forth was killed, the legions of UR/Forth
programmers would cheerfully switch to Forth Inc., despite the fact that SwiftForth
hadn't been written yet due to Forth Inc. not employing any Forth programmers.
What actually happened is that the legions of UR/Forth programmers switched to C.
Eventually SwiftForth came out and it was a bug-ridden mess. Locals would crash
SwiftForth as late as version-2 of SwiftForth. This bug didn't get caught because
Elizabeth Rather said: "I hate locals! :-)" Also, ANS-Forth had LOCALS| rather than
the de facto standard of { ... } developed at John Hopkins, and LOCALS| had the
local names backwards so it was pretty much useless. Because of these problems
nobody at Forth Inc. ever used locals and the bug in SwiftForth locals didn't get noticed.
A system crash should be easy to notice, but that slipped past the Forth Inc. geniuses.

Now we have Forth-200x that Ilya describe as being the galvanized corpse of ANS-Forth.
ANS-Forth was just an effort to standardize Charles Moore's MicroForth written for
the PDP-11 that had an extreme shortage of registers. So, Forth-200x represents the
state of the art in Forth programming as done by Charles Moore in the 1970s.
Dolly isn't the only sheep that has ever been cloned! We have Forth-200x too!

Anyway, getting back to Stephen Pelc's stupid bug in <# #> shown above, I fixed this
myself many years ago. I have a circular buffer for strings. I got this idea from
UR/Forth. I wrote it from scratch though because I don't use other people's code.
I rewrote <# #> etc. to use this circular string-buffer. I also rewrote WORD to use this
circular string-buffer. Also, C" and S" in interpretive mode use this circular buffer.
This doesn't totally fix the problem because the circular buffer eventually wraps around,
but it fixes the problem at a practical level. It is best to move these strings to the heap
with HSTR if they are to be kept permanently, but if they are only going to be used
temporarily they can stay in the circular buffer because it doesn't wrap around for
quite some time. Now I have my STRING-STACK.4TH though, that holds all of its
strings in the heap indefinitely, so my circular string-buffer is deprecated.

Stephen Pelc almost never fixes bugs.
I reported another bug in VFX in which he was using word-lists for local variable names,
which screwed up any use of word-lists in words that had local variables.
I fixed this myself too by rewriting all of the word-list code in ANS-Forth.
Eventually Stephen Pelc fixed the bug in VFX with a lot of grumbling.
He doesn't care about ANS-Forth compliance. He doesn't know anything about ANS-Forth.
He just wants VFX to be a cash cow with little or no effort on his part.

Stephen Pelc is never going to fix this bug in POSTPONE LITERAL that I'm pointing out.
I think that he inserted this bug into VFX purposefully to sabotage my novice-package.

[dxforth]

On 22/02/2023 3:33 am, Hugh Aguilar wrote:
>
> Here is another bug in VFX:
> --------------------------------------
> : ttt ( n -- ) 0 <# #S #> ; ok
>
> 1234567890 ttt 2dup type 1234567890 ok-2
> 2dup type 1234567892 ok-2
> --------------------------------------
>
> I told Stephen Pelc about this bug many years ago. He never fixed it.
> He is stupidly using <# #> internally to print the stack depth (the "ok-2").
> <# #> uses a static global pad. So, the string returned by TTT gets over-written.
> The next time that I TYPE this string it has been over-written by the '2'.

I have exactly this 'bug' in DX-Forth which now automatically displays
stack contents. ANS states data in the numeric output buffer is temporary
and subject to being overwritten. It's been this way for over 50 years
and countless applications. I like the idea forth is respectful of
resources. It encourages users to be similarly thoughtful.

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>On 22/02/2023 3:33 am, Hugh Aguilar wrote:
>>
>> Here is another bug in VFX:
>> --------------------------------------
>> : ttt ( n -- ) 0 <# #S #> ; ok
>>
>> 1234567890 ttt 2dup type 1234567890 ok-2
>> 2dup type 1234567892 ok-2
>> --------------------------------------

...

>I have exactly this 'bug' in DX-Forth

Buggery loves company?

There are systems without this bug:

SwiftForth i386-Linux 3.11.0 23-Feb-2021

: ttt ( n -- ) 0 <# #S #> ; ok
1234567890 ttt 2dup type 1234567890 ok

2dup type 1234567890 ok

Gforth 0.7.9_20230209
...

: ttt ( n -- ) 0 <# #S #> ; ok

1234567890 ttt 2dup type 1234567890 ok 2
2dup type 1234567890 ok 2

OTOH:
SwiftForth x64-Linux 4.0.0-RC52 20-Sep-2022

: ttt ( n -- ) 0 <# #S #> ; ok
1234567890 ttt 2dup type 1234567890 ok

2dup type 1234567811 ok

(I have not checked more recent RCs).

>ANS states data in the numeric output buffer is temporary
>and subject to being overwritten.

No. What Forth-94 and Forth-2012 state is:

|The data space regions identified by PAD, WORD, and #> (the pictured
|numeric output string buffer) may be transient. Their addresses and
|contents may become invalid after:
|
| * a definition is created via a defining word;
| * definitions are compiled with : or :NONAME;
| * data space is allocated using ALLOT, , (comma), C, (c-comma), or ALIGN.
|
|The previous contents of the regions identified by WORD and #> may be
|invalid after each use of these words. Further, the regions returned
|by WORD and #> may overlap in memory. Consequently, use of one of
|these words can corrupt a region returned earlier by a different
|word. The other words that construct pictured numeric output strings
|(<#, #, #S, HOLD, HOLDS, XHOLD) may also modify the contents of these
|regions. Words that display numbers may be implemented using pictured
|numeric output words. Consequently, . (dot), .R, .S, ?, D., D.R, U.,
|U.R could also corrupt the regions.

None of these conditions happened here. Some may argue that the
system may use one of the words that may overwrite the pictured
numeric output string buffer internally at any place, but that would
mean that the standard gives no guarantee at all about the contents of
the buffer, which would make <# # #S HOLD #> etc. unusable in standard
programs; standardizing these words would make no sense.

So, the conclusion is that the second TYPE in the example above must
output 1234567890 on a standard system with a large-enough cell size.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

[dxforth]

On 22/02/2023 9:34 pm, Anton Ertl wrote:
> ...

> There are systems without this bug:

It's not a bug to print a number as part of the QUIT loop. It's an entitlement.

[Anton Ertl]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>SwiftForth x64-Linux 4.0.0-RC52 20-Sep-2022
>: ttt ( n -- ) 0 <# #S #> ; ok
>1234567890 ttt 2dup type 1234567890 ok
>2dup type 1234567811 ok

I tried to reproduce this for a bug report, but now every time I input

: ttt ( n -- ) 0 <# #S #> ;

1234567890 ttt 2dup type
2dup type

I get

: ttt ( n -- ) 0 <# #S #> ; ok
1234567890 ttt 2dup type 1234567890 ok
2dup type 1234567890 ok

Strange.

[Heinrich Hohl]

SwiftForth also had this bug (or peculiarity) for some time.
It was fixed in SwiftForth-3.7.1 (13-Feb-2018).

SF revision history: https://www.forth.com/swiftforth/revs/

Henry

[Hans Bezemer]

On Wednesday, February 22, 2023 at 1:06:59 PM UTC+1, Anton Ertl wrote:
> : ttt ( n -- ) 0 <# #S #> ; ok
> 1234567890 ttt 2dup type 1234567890 ok
> 2dup type 1234567890 ok
> Strange.

It's IMHO not strange. Obviously VFX uses the buffer to generate the number of stack items
still remaining. Hence: 0 => 2 (that's the number that is generated).

I don't know how Gforth does it, because it *seems* to use the same system:

see prompt-ok
: prompt-ok " ok"
type depth
?DUP-IF space #0 dec.r
THEN
fdepth
?DUP-IF " f:" type #0 dec.r
THEN
rp0 @ rp@ - cell/ #-22 +
?DUP-IF " r:" type #0 dec.r
THEN ; ok
see dec.r
: dec.r
base @ >r decimal .r r> base ! ; ok
see .r
: .r
>r s>d r> d.r ; ok
see d.r
: d.r
>r tuck dabs <<# #s rot sign #> r> over - spaces type #>> ; ok
see <<#
: <<#
holdend @ holdptr @ - hold holdptr @ holdend ! ; ok

1234567890 ttt 2dup . . 10 140514140281800 ok 2
holdend ? holdptr ? 140514140281810 140514140281800 ok 2

Maybe Anton can explain ;-)

Hans Bezemer

[Anton Ertl]

Hans Bezemer <the.bee...@gmail.com> writes:
>On Wednesday, February 22, 2023 at 1:06:59 PM UTC+1, Anton Ertl wrote:
>> : ttt ( n -- ) 0 <# #S #> ; ok
>> 1234567890 ttt 2dup type 1234567890 ok
>> 2dup type 1234567890 ok
>> Strange.
>
>It's IMHO not strange.

It's strange that my first test of SwiftForth 4.0.0 RC52 produced a
wrong result, but I could not reproduce that behaviour later.

>Obviously VFX uses the buffer to generate the number of stack items
>still remaining. Hence: 0 => 2 (that's the number that is generated).
>
>I don't know how Gforth does it, because it *seems* to use the same system:

Gforth supports nestable use of the HOLD area. From
<https://gforth.org/manual/Formatted-numeric-output.html>:

Gforth additionally supports nested usage of this buffer, allowing,
e.g., to nest output from the debugging tracer ~~ inside code dealing
with the hold area: <<# starts a new nest, #> produces the result
string, and #>> unnests: the hold area for the nest is reclaimed, and
#> now produces the string for the next-outer nest. All of Gforth’s
higher-level numeric output words use <<# ... #> ... #>> and can be
nested inside other users of the hold area.
...
|<<# ( – ) gforth-0.5 “less-less-number-sign”
|
|Start a hold area that ends with #>>. Can be nested in each other and
|in <#. Note: if you do not match up the <<#s with #>>s, you will
|eventually run out of hold area; you can reset the hold area to empty
|with <#.
|
|#> ( xd – addr u ) core “number-sign-greater”
|
|Complete the pictured numeric output string by discarding xd and
|returning addr u; the address and length of the formatted string. A
|Standard program may modify characters within the string. Does not
|release the hold area; use #>> to release a hold area started with
|<<#, or <# to release all hold areas.
|
|#>> ( – ) gforth-0.5 “number-sign-greater-greater”
|
|Release the hold area started with <<#.
|
|Here are some examples of using pictured numeric output:
|
|: my-u. ( u -- )
| \ Simplest use of pns.. behaves like Standard u.
| 0 \ convert to unsigned double
| <<# \ start conversion
| #s \ convert all digits
| #> \ complete conversion
| TYPE SPACE \ display, with trailing space
| #>> ; \ release hold area

I introduced <<# .. #>> in response to a bug report (AT-XY destroyed
the HOLD area) and posted on 1999-02-21 (24th anniversary yesterday)
about it here. I also posted about this feature here later, with a
total of 55 occurences in my postings, but AFAIK no system picked it
up.

[dxforth]

On 23/02/2023 5:32 am, Anton Ertl wrote:
> ...

> I introduced <<# .. #>> in response to a bug report (AT-XY destroyed
> the HOLD area) and posted on 1999-02-21 (24th anniversary yesterday)
> about it here. I also posted about this feature here later, with a
> total of 55 occurences in my postings, but AFAIK no system picked it
> up.

Looks more like an omission on the part of ANS than a bug. AT-XY
definitely falls into the category of 'things that output numbers'.
That no other system has picked up <<# .. #>> suggests they have
other, perhaps simpler, ways of handling potential conflicts e.g.
>SYSPAD >QPAD >PAD to name but three.

[none albert]

In article <2023Feb2...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>dxforth <dxf...@gmail.com> writes:
>>On 22/02/2023 3:33 am, Hugh Aguilar wrote:
>>>
>>> Here is another bug in VFX:
>>> --------------------------------------
>>> : ttt ( n -- ) 0 <# #S #> ; ok
>>>
>>> 1234567890 ttt 2dup type 1234567890 ok-2
>>> 2dup type 1234567892 ok-2
>>> --------------------------------------
>...
>>I have exactly this 'bug' in DX-Forth
>
>Buggery loves company?
>
>There are systems without this bug:
>
>SwiftForth i386-Linux 3.11.0 23-Feb-2021
>: ttt ( n -- ) 0 <# #S #> ; ok
>1234567890 ttt 2dup type 1234567890 ok
>2dup type 1234567890 ok
>
>Gforth 0.7.9_20230209
>...
>: ttt ( n -- ) 0 <# #S #> ; ok
>1234567890 ttt 2dup type 1234567890 ok 2
>2dup type 1234567890 ok 2

<SNIP>

>None of these conditions happened here. Some may argue that the
>system may use one of the words that may overwrite the pictured
>numeric output string buffer internally at any place, but that would
>mean that the standard gives no guarantee at all about the contents of
>the buffer, which would make <# # #S HOLD #> etc. unusable in standard
>programs; standardizing these words would make no sense.
>
>So, the conclusion is that the second TYPE in the example above must
>output 1234567890 on a standard system with a large-enough cell size.

lina -a
-1 1 RSHIFT 0 <# #S #> 2DUP
OK
TYPE
9223372036854775807 OK
TYPE
9223372036854775807 OK

ciforth passes this test. However ...
if you ask ciforth to do DO-DEBUG i.e. to print its stack content
with each ok, then it clobbers the static area.
WANT DO-DEBUG

S[ ] OK -1 1 RSHIFT 0 <# #S #>
S[ 4256305 19 ] OK 2DUP TYPE
9223372036854256319

Makes sense, but how to assess this situation?
>
>- anton

[none albert]

There is a simple solution that make the problem goes way.
Or rather it doesn't exist in the first place.

I introduced the FORMAT tool comparable with the % tools of mpe forth.
This carefully copies outputs of <# #> (here (D.R) ) to a static
buffers of its own.
This 1 screen tool has multiple uses (for e.g. defining classes).

( FORMAT FORMAT&EVAL .FORMAT ) \ AH&CH C2feb15
DATA CRS$ 4096 ALLOT \ ":2" WANTED
NAMESPACE FORMAT-WID FORMAT-WID DEFINITIONS
: c CRS$ $C+ ; : n ^J c ; : r ^M c ; \ Add single char's
: d S>D 0 (D.R) CRS$ $+! ; \ Add INT as a string.
: s CRS$ $+! ; \ Add a STRING as such.
PREVIOUS DEFINITIONS
\ Format the first part of STRING, up till %, leave REST.
: _plain &% $/ CRS$ $+! ;
\ Format X with first word of STRING, up till BL, leave REST.
: _format BL $/ 2SWAP >R >R 'FORMAT-WID >WID (FIND) NIP NIP
DUP 0= 51 ?ERROR EXECUTE R> R> ;
\ Format X1 .. Xn using the format STRING.
: FORMAT 0 CRS$ ! BEGIN DUP WHILE _plain DUP IF _format THEN
REPEAT 2DROP CRS$ $@ ;
: FORMAT&EVAL FORMAT EVALUATE ; : .FORMAT FORMAT TYPE ;

Using this wordset for AT-XY has no problems of the kind
mentioned, e.g.
: AT-XY 1+ SWAP 1+ SWAP "%e [%dd ;%dd H" .FORMAT ;

You must be aware if any tools use static buffers.
The strategy must be. If you don't use the buffer
right away, you have to copy the string to an
application buffer that is totally under your control.
This equally applies to the <# # #S #> wordset of course.
2DUP should wave a red flag, and you must expected it to
fail if you're not careful.

And if you wonder, there are other means to make a
string permanent in ciforth
"APEGAAR" $,
possibly followed by >ALLOC that store a string in ALLOCATE d memory.

[dxforth]

On 23/02/2023 9:11 pm, albert wrote:
> In article <tt6a0l$1ktpa$1...@dont-email.me>, dxforth <dxf...@gmail.com> wrote:
>> On 23/02/2023 5:32 am, Anton Ertl wrote:
>>> ...
>>> I introduced <<# .. #>> in response to a bug report (AT-XY destroyed
>>> the HOLD area) and posted on 1999-02-21 (24th anniversary yesterday)
>>> about it here. I also posted about this feature here later, with a
>>> total of 55 occurences in my postings, but AFAIK no system picked it
>>> up.
>>
>> Looks more like an omission on the part of ANS than a bug. AT-XY
>> definitely falls into the category of 'things that output numbers'.
>> That no other system has picked up <<# .. #>> suggests they have
>> other, perhaps simpler, ways of handling potential conflicts e.g.
>>> SYSPAD >QPAD >PAD to name but three.
>
> There is a simple solution that make the problem goes way.
> Or rather it doesn't exist in the first place.
>
> I introduced the FORMAT tool comparable with the % tools of mpe forth.
> This carefully copies outputs of <# #> (here (D.R) ) to a static
> buffers of its own.

The formatter still alters the HOLD buffer by virtue of (D.R) - no?
In which case the issue of AT-XY corrupting it remains.

[Stephen Pelc]

On 19 Jan 2023 at 04:34:11 CET, "Hugh Aguilar" <hughag...@gmail.com>
wrote:

> The bug is that this ANS-Forth compliant code causes VFX to crash:
> ------------------------------------------
> : lit, ( val -- ) \ runtime: -- val
> postpone literal ;
> ------------------------------------------

For the moment define LIT, as

: lit, ( val -- ) \ runtime: -- val
postpone literal ; doNotSin

An upcoming version of VFX may/will use a different fix and will not require
DONOTSIN.

Stephen

--
Stephen Pelc, ste...@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612,
+34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

[Brian Fox]

On Thursday, February 23, 2023 at 7:53:49 AM UTC-5, Stephen Pelc wrote:
>
> For the moment define LIT, as
>
> : lit, ( val -- ) \ runtime: -- val
> postpone literal ; doNotSin
>
> An upcoming version of VFX may/will use a different fix and will not require
> DONOTSIN.
>
> Stephen

LOL. Very cute word name.
I get verklempt just reading the directive "doNotSin"

[dxforth]

Wishful thinking.

[Zbig]

> > An upcoming version of VFX may/will use a different fix and will not require
> > DONOTSIN.
> >
> > Stephen
> LOL. Very cute word name.

SIN DROP would be more „Forthish”. ;]

[Hugh Aguilar]

On Thursday, February 23, 2023 at 5:53:49 AM UTC-7, Stephen Pelc wrote:
> On 19 Jan 2023 at 04:34:11 CET, "Hugh Aguilar" <hughag...@gmail.com>
> wrote:
>
> > The bug is that this ANS-Forth compliant code causes VFX to crash:
> > ------------------------------------------
> > : lit, ( val -- ) \ runtime: -- val
> > postpone literal ;
> > ------------------------------------------
>
> For the moment define LIT, as
>
> : lit, ( val -- ) \ runtime: -- val
> postpone literal ; doNotSin
>
> An upcoming version of VFX may/will use a different fix and will not require
> DONOTSIN.
>
> Stephen

I made my novice-package fully ANS-Forth compliant.
This was a sin???

I use POSTPONE LITERAL a lot. For example, my early-binding MACRO: supports literal numbers (unlike Anton Ertl's attempt at writing an early-binding macro). I'm supposed to hunt down every use of POSTPONE LITERAL to apply this patch? What exactly are the rules for when the patch is needed? Is this any colon word that has POSTPONE LITERAL inside of it?

Right now my MSP430 assembler has stopped working under VFX, although it had been working fine previously. All of my code that uses the novice package has stopped working under VFX.
Continuing with VFX seems like a bad idea --- all that you have offered is the suggestion that I
rewrite the novice package using this patch, and that someday you may fix this bug that you
introduced in the latest VFX version, but no guarantee that there won't be new bugs introduced.

Why did you introduce the bug?
You knew that you were introducing a bug because you provided this DoNotSin patch
to fix the bug. What purpose did the bug have other than to sabotage my novice package?
Obviously, the "sin" that you were referring to was for anybody to use the novice package.
Now you have been caught, so you have publicly described this DoNotSin patch, but you
weren't planning on describing the bug-fix publicly --- you were hoping to not get caught.

Only a fool would ever trust you again --- your credibility is gone --- you got caught!
Your market base consists entirely of worms who squirm in verklempt at your "cute" tricks.

You said:
> An upcoming version of VFX may/will use a different fix and will not require
> DONOTSIN.

Are you planning on describing this bug fix publicly?
More likely, you will provide the bug fix only to the verklempt worms --- your sycophants.

[dxforth]

On 25/02/2023 4:07 pm, Hugh Aguilar wrote:
>
> Are you planning on describing this bug fix publicly?
> More likely, you will provide the bug fix only to the verklempt worms --- your sycophants.

When may we expect your fix for the f/p output bug in the novice pack?

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>On 23/02/2023 5:32 am, Anton Ertl wrote:
>> ...
>> I introduced <<# .. #>> in response to a bug report (AT-XY destroyed
>> the HOLD area) and posted on 1999-02-21 (24th anniversary yesterday)
>> about it here. I also posted about this feature here later, with a
>> total of 55 occurences in my postings, but AFAIK no system picked it
>> up.
>
>Looks more like an omission on the part of ANS than a bug.

Not to me.

>AT-XY
>definitely falls into the category of 'things that output numbers'.

Probably depends on the environment. But anyway, given that the
solution is as simple as using <<# and #>>, there is no reason for
AT-XY to destroy the hold buffer.

>That no other system has picked up <<# .. #>> suggests they have
>other, perhaps simpler, ways of handling potential conflicts e.g.
>>SYSPAD >QPAD >PAD to name but three.

If they have found these ways, these ways seem to have the flaw that
most of the system implementors don't use them. Otherwise we would
not be discussing this issue.

By contrast, I just used <<# .. #> .. #>> in all the system words
that before had used <# .. #> .., and things work like a charm,
without . Adding a stack depth indication in the status prompt did
not require fiddling with >SYSPAD or something, as Hans Bezemer
noticed.

Your comments inspired me to test various systems on Linux with an
xterm with

page 456789. <# #s #> 1 2 at-xy type cr bye

The PAGE and AT-XY seemed to work fine on all systems. The output at
that position was:

Gforth: 456789
iforth: 456789
lxf:
sf64: 456782
vfx64: 456782

If lxf, sf64, or vfx64 use the other ways you suggest, they don't seem
to work.

[Anton Ertl]

albert@cherry.(none) (albert) writes:
>lina -a
>-1 1 RSHIFT 0 <# #S #> 2DUP
>OK
>TYPE
>9223372036854775807 OK
>TYPE
>9223372036854775807 OK
>
>ciforth passes this test. However ...
>if you ask ciforth to do DO-DEBUG i.e. to print its stack content
>with each ok, then it clobbers the static area.
>WANT DO-DEBUG
>
>S[ ] OK -1 1 RSHIFT 0 <# #S #>
>S[ 4256305 19 ] OK 2DUP TYPE
>9223372036854256319
>
>Makes sense, but how to assess this situation?

As far as the standard is concerned, the latter program is not a
standard program because of "WANT DO-DEBUG", and it apparently turns
the system into a non-standard system.

[Anton Ertl]

albert@cherry.(none) (albert) writes:
>I introduced the FORMAT tool comparable with the % tools of mpe forth.
>This carefully copies outputs of <# #> (here (D.R) ) to a static
>buffers of its own.
>This 1 screen tool has multiple uses (for e.g. defining classes).
>
>( FORMAT FORMAT&EVAL .FORMAT ) \ AH&CH C2feb15
>DATA CRS$ 4096 ALLOT \ ":2" WANTED
>NAMESPACE FORMAT-WID FORMAT-WID DEFINITIONS
>: c CRS$ $C+ ; : n ^J c ; : r ^M c ; \ Add single char's
>: d S>D 0 (D.R) CRS$ $+! ; \ Add INT as a string.
>: s CRS$ $+! ; \ Add a STRING as such.
>PREVIOUS DEFINITIONS
>\ Format the first part of STRING, up till %, leave REST.
>: _plain &% $/ CRS$ $+! ;
>\ Format X with first word of STRING, up till BL, leave REST.
>: _format BL $/ 2SWAP >R >R 'FORMAT-WID >WID (FIND) NIP NIP
> DUP 0= 51 ?ERROR EXECUTE R> R> ;
>\ Format X1 .. Xn using the format STRING.
>: FORMAT 0 CRS$ ! BEGIN DUP WHILE _plain DUP IF _format THEN
> REPEAT 2DROP CRS$ $@ ;
>: FORMAT&EVAL FORMAT EVALUATE ; : .FORMAT FORMAT TYPE ;
>
>Using this wordset for AT-XY has no problems of the kind
>mentioned, e.g.
> : AT-XY 1+ SWAP 1+ SWAP "%e [%dd ;%dd H" .FORMAT ;

For comparison:

: <# ( -- ) \ core less-number-sign
holdbuf-end dup holdptr ! holdend ! ;

: #> ( xd -- addr u ) \ core number-sign-greater
2drop holdptr @ holdend @ over - ;

: <<# ( -- ) \ gforth less-less-number-sign

holdend @ holdptr @ - hold
holdptr @ holdend ! ;

: #>> ( -- ) \ gforth number-sign-greater-greater
count chars bounds holdptr ! holdend ! ;

: #n ( n -- ) [: 0 #s 2drop ;] #10 base-execute ;
: #n; ( n -- ) [: 0 #s 2drop ';' hold ;] #10 base-execute ;
: #esc[ ( -- ) '[' hold #esc hold ;
: vt100-at-xy ( u1 u2 -- ) \ facility at-x-y
1+ swap 1+ <<# 'H' hold #n; #n #esc[ #0. #> type #>> ;

You may wonder about #N #N; #ESC[, but they are used multiple times:

2 #n
11 #n;
4 #esc[

And while we are at it:

9 <# (possibly some should be replaced with <<# ... #>>
23 #>
15 <<#
15 #>>

>You must be aware if any tools use static buffers.
>The strategy must be. If you don't use the buffer
>right away, you have to copy the string to an
>application buffer that is totally under your control.

Works great for lxf, SwiftForth and VFX.

[Hugh Aguilar]

On Tuesday, February 21, 2023 at 5:29:49 AM UTC-7, none albert wrote:
> In article <c71eeceb-54f8-4ab1...@googlegroups.com>,
> Hugh Aguilar <hughag...@gmail.com> wrote:
> >I've never taken advice from a maintenance programmer, and I never will.
> >I figure things out for myself.
> In the 40 years I have worked with all kind of industries, the truth
> is you have to build on work of others 80% of the time.
> I guess I am a 80% maintenance programmer.

In my experience, there is no such thing as an 80% maintenance programmer.
There are only 99.9% maintenance programmers. The require somebody smart
to write 99.9% of the code, then they do 0.1% of the code and claim 99% credit.

We had this insult flung at me earlier:

On Sunday, February 19, 2023 at 6:58:45 PM UTC-7, dxforth wrote:
> Speaking of code posted on c.l.f. Even a novice might baulk at a float-to-string
> routine that can't display numbers to the precision of the system. Then there's
> the limitation stemming from the use of F>D and the inability to handle INF/NAN.
> Here's a possible solution to the first problem. The remainder I leave to you.

When DXforth says, "The remainder I leave to you," he is implying that he is to be
credited with 99% of the novice package, and the remainder will be left to me.
This is very typical for maintenance programmers, that they try to claim credit
for 99% of the work. Any bugs found will be blamed on the original programmer.
The original programmer is granted 1% of the credit so there will be a dumping
ground for any bugs that are found.

The liar Tom Hart said that MFX was written long before I showed up at
Testra and that I had nothing to do with it. He was accusing me of being a soulless
maintenance programmer who wrote 0.1% of the code and then tried to claim
99% of the credit. He was lying. I will never forgive him for this lie.

I can't associate with soulless maintenance programmers such as DXforth,
Albert van der Horst, Hans Bezemer, etc.. This just gives Tom Hart the
opportunity to say: "Birds of a feather stick together." Guilt by association!

I don't provide the novice-package to the general public anymore.
None of the smirky trolls on comp.lang.forth (including DXforth) are authorized
to have a copy of the novice package. If you have an old copy of the novice package,
delete it from your computer. That is my intellectual property --- not yours!

Maintenance programmers don't deserve to be given source-code
for the same reason that coyotes don't deserve to be given fresh meat.
Let them eat rotten carrion --- that is what Gerry Jackson was doing when he
put his copyright notice on Michael Gassenenko's SWITCH construct without
understanding how it worked (most importantly, without understanding why
it only does what my FAST-SWITCH> does but can not do what my SLOW-SWITCH>
does for tables that have too large of a range to realistically be sparse tables).

[dxforth]

On 26/02/2023 3:36 am, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>> On 23/02/2023 5:32 am, Anton Ertl wrote:
>>> ...
>>> I introduced <<# .. #>> in response to a bug report (AT-XY destroyed
>>> the HOLD area) and posted on 1999-02-21 (24th anniversary yesterday)
>>> about it here. I also posted about this feature here later, with a
>>> total of 55 occurences in my postings, but AFAIK no system picked it
>>> up.
>>
>> Looks more like an omission on the part of ANS than a bug.
>
> Not to me.

That's because you don't want to consider it.

>> AT-XY
>> definitely falls into the category of 'things that output numbers'.
>
> Probably depends on the environment. But anyway, given that the
> solution is as simple as using <<# and #>>, there is no reason for
> AT-XY to destroy the hold buffer.

There's plenty of reason. AT-XY is a console output function that
has all the implications of ...

"Words that display numbers may be implemented using pictured numeric

output words. Consequently, . (dot), .R, .S, ?, D., D.R, U., and U.R

could also corrupt the regions."

That you invented <<# and #>> is all very well but it's no reason to
burden implementers with things they don't need to have or do. When
you have a better rationale as to why AT-XY must not corrupt the HOLD
buffer other than it wasn't included in the list above, let me know.

> ...

> Your comments inspired me to test various systems on Linux with an
> xterm with
>
> page 456789. <# #s #> 1 2 at-xy type cr bye
>
> The PAGE and AT-XY seemed to work fine on all systems. The output at
> that position was:
>
> Gforth: 456789
> iforth: 456789
> lxf:
> sf64: 456782
> vfx64: 456782
>
> If lxf, sf64, or vfx64 use the other ways you suggest, they don't seem
> to work.

It's not possible to draw any conclusions of intent from such tests.

[dxforth]

On 26/02/2023 10:26 am, Hugh Aguilar wrote:
> On Tuesday, February 21, 2023 at 5:29:49 AM UTC-7, none albert wrote:
>> In article <c71eeceb-54f8-4ab1...@googlegroups.com>,
>> Hugh Aguilar <hughag...@gmail.com> wrote:
>>> I've never taken advice from a maintenance programmer, and I never will.
>>> I figure things out for myself.
>> In the 40 years I have worked with all kind of industries, the truth
>> is you have to build on work of others 80% of the time.
>> I guess I am a 80% maintenance programmer.
>
> In my experience, there is no such thing as an 80% maintenance programmer.
> There are only 99.9% maintenance programmers. The require somebody smart
> to write 99.9% of the code, then they do 0.1% of the code and claim 99% credit.
>
> We had this insult flung at me earlier:
> On Sunday, February 19, 2023 at 6:58:45 PM UTC-7, dxforth wrote:
>> Speaking of code posted on c.l.f. Even a novice might baulk at a float-to-string
>> routine that can't display numbers to the precision of the system. Then there's
>> the limitation stemming from the use of F>D and the inability to handle INF/NAN.
>> Here's a possible solution to the first problem. The remainder I leave to you.

These are all known issues - the most obvious of which was easiest to resolve.

> When DXforth says, "The remainder I leave to you," he is implying that he is to be
> credited with 99% of the novice package, and the remainder will be left to me.

If by your calculation two lines of code represents 99% of the novice package,
then it must be very good code indeed.

> The liar Tom Hart said that MFX was written long before I showed up at
> Testra and that I had nothing to do with it.

I don't believe I saw that among Tom's comments. What I read was:

"He [Hugh] wrote our Forth compiler for the processor
that we implemented in a Lattice PLD.

He did a good job on it,
we are still using it with a few bug fixes and minor modifications.

He had nothing to do with the processor itself,
that was all designed by John Hart and Steve Brault.

The PLD version was based upon our original Forth Engine done long before
we ever ran across Hugh"

> He was accusing me of being a soulless
> maintenance programmer who wrote 0.1% of the code and then tried to claim
> 99% of the credit. He was lying. I will never forgive him for this lie.

You seem to have confused his comments about MFX and his comments about the processor.

> I don't provide the novice-package to the general public anymore.
> None of the smirky trolls on comp.lang.forth (including DXforth) are authorized
> to have a copy of the novice package. If you have an old copy of the novice package,
> delete it from your computer. That is my intellectual property --- not yours!

You released it under a BSD licence which only affords this:

\ novice.4th --- written by Hugh Aguilar --- copyright (c) 2009, BSD license

As long as you keep bringing up the contents of the novice pack in c.l.f. posts,
folks will want to examine the code and the claims made in respect of it.

[none albert]

In article <03da6e10-f1ee-47d0...@googlegroups.com>,

Hugh Aguilar <hughag...@gmail.com> wrote:
>I don't provide the novice-package to the general public anymore.
>None of the smirky trolls on comp.lang.forth (including DXforth) are authorized
>to have a copy of the novice package. If you have an old copy of the
>novice package,
>delete it from your computer. That is my intellectual property --- not yours!

You can retroactively change the copyright conditions.
If I was entitled to download the source at the time, it sticks.

[none albert]

In article <nnd$1c7f76fe$0a06061c@701394006c4d786b>,

none) (albert <albert@cherry.> wrote:
>In article <03da6e10-f1ee-47d0...@googlegroups.com>,
>Hugh Aguilar <hughag...@gmail.com> wrote:
>>I don't provide the novice-package to the general public anymore.
>>None of the smirky trolls on comp.lang.forth (including DXforth) are authorized
>>to have a copy of the novice package. If you have an old copy of the
>>novice package,
>>delete it from your computer. That is my intellectual property --- not yours!
>
>You can retroactively change the copyright conditions.

Of course I meant "can't".

>If I was entitled to download the source at the time, it sticks.

Apparently it was under the BSD license.

[Jurgen Pitaske]

I am amazed what all of this fuss is about
The old version of the novice package is here
https://www.forth2020.org/beginners-to-forth/a-novice-package
can be downloaded by anybody.
If there is a new version to be discussed it should be accessible as well.
If not, the CLF should move to more fruitful discussions.
According to Hugh they are all liars anyway ....

The link here is dead
original document : -- http://www.forth.org/novice.html --

[Stephen Pelc]

I'm not touching the novice code. That's for Hugh and his sycophants.

Your FP changes will be integrated as soon as I have delivered a major update
to a client and finished some migration issues.

[Hans Bezemer]

On Sunday, February 26, 2023 at 12:26:27 AM UTC+1, Hugh Aguilar wrote:
> I can't associate with soulless maintenance programmers such as DXforth,
> Albert van der Horst, Hans Bezemer, etc.. This just gives Tom Hart the
> opportunity to say: "Birds of a feather stick together." Guilt by association!

Let me begin this by publicly stating that I don't want, need, require or ask
for any association with you in any way, shape or form. So relax.

Second, there is such thing as "guilt by association" other than as a logical
fallacy: https://owl.excelsior.edu/argument-and-critical-thinking/logical-fallacies/logical-fallacies-guilt-by-association/
So relax.

But I'm not a maintenance programmer. As a matter of fact, my last paid
programming job ended over 35 years ago - and I've not specifically *hired*
to do any programming since.

Yes, I've done some programming professionally since, but always when
people stated "it cannot be done" or "it cannot be done in that time frame".
And always in my capacity as Service Manager. Consequently, those were
always original programs.

So - why am I sharing this information with you. Because you're simply wrong.

In your delusion you may think I'm a professional programmer - but I'm not.
The vast majority of articles I wrote were on ITSM - not programming. Which
is kind of logical, since I have been in Service Management for almost 30 yrs.
(Yes, I've also been a DBA and a sys admin for a few years - so it doesn't add
up to 35 yrs).

I bet you don't have ANY solid evidence that the others you listed were
"maintenance programmers", because that is obviously how your mind works.
You assume some things, may be even imagine them and then that becomes
your truth. But that is not how the world works.

But maybe now you understand why I don't care about you, Hugh. Or anything
you say about me. Or make me stop what I'm doing. To me, you're just a nobody
with a crazy opinion I don't care for.

Hans Bezemer

BTW, I can rip your NOVICE package till the last byte. You clearly released it under
the BSD license - and you can't revoke that. You can change the license on the next
version, but not the previous one.

More unlucky - it is a very permissive one. The only thing one has to do is basically
retain the copyright message. For the rest, it's free game.

If you want to sue anybody here for using it, take my advise: you better keep your
money in your pocket.

[Hugh Aguilar]

On Sunday, February 26, 2023 at 3:05:05 AM UTC-7, Jurgen Pitaske wrote:
> On Sunday, 26 February 2023 at 09:39:40 UTC, none albert wrote:
> > In article <nnd$1c7f76fe$0a06061c@701394006c4d786b>,
> > none) (albert <albert@cherry.> wrote:
> > >In article <03da6e10-f1ee-47d0...@googlegroups.com>,
> > >Hugh Aguilar <hughag...@gmail.com> wrote:
> > >>I don't provide the novice-package to the general public anymore.
> > >>None of the smirky trolls on comp.lang.forth (including DXforth) are authorized
> > >>to have a copy of the novice package. If you have an old copy of the
> > >>novice package,
> > >>delete it from your computer. That is my intellectual property --- not yours!
> > >
> > >You can retroactively change the copyright conditions.
> > Of course I meant "can't".
> > >If I was entitled to download the source at the time, it sticks.
> > Apparently it was under the BSD license.
> > Groetjes Albert

You have no right to post my code on the internet without my permission.

> I am amazed what all of this fuss is about
> The old version of the novice package is here
> https://www.forth2020.org/beginners-to-forth/a-novice-package
> can be downloaded by anybody.
> If there is a new version to be discussed it should be accessible as well.
> If not, the CLF should move to more fruitful discussions.
> According to Hugh they are all liars anyway ....
>
> The link here is dead
> original document : -- http://www.forth.org/novice.html --

I demand that my novice package should be removed from the
www.Forth2020 website. This is grossly unethical to post my code on
your website when I have clearly said that you don't have my permission.

I demanded that my novice package be removed from the SVFIG website
and they complied, which is why that link is dead.

All of Stephen Pelc's sycophants are liars.
On this page: https://www.forth2020.org/beginners-to-forth/a-novice-package
The Forth2020 liars say this: "239 Kb zip file this file is up to date to Oct.2020"
They are lying! I never gave them an updated version.
They have an old copy of the novice package from 2010 that they are saying
is the best that I've come up with in all of these years.

Most likely they sabotaged my novice package to turn it into non-working crap
to support their claim that I'm incompetent and they are Forth experts.
The Forth-2020 "experts" are truly evil people! They are chronic liars.

Consider this thread:
https://groups.google.com/g/comp.lang.forth/c/qqlp1gZnVic/m/kjeAwWCaR1MJ

On Monday, November 25, 2013 at 4:20:14 PM UTC-7, Bernd Paysan wrote:
> Albert van der Horst wrote:
> > It sounds like you have a whole machinery in place to tests rng's.
> > Would you mind adding LC53 to the list?
> >
> > \ Comma for clarity, not a double number.
> > : LC53 -5 um* -333,333,333 + nip ;
> Hm, wasn't Hugh's LC53
>
> : lc53 -333333333 um* -5 um/mod drop ;
>
> ? Don't make Hugh look more stupid than he actually is ;-).

In this thread Albert van der Horst repeated posted non-working crap code
that looked similar to my code, but he was lying --- it wasn't my code.
He was telling these lies about me to support his claim that I'm incompetent
and he is an expert. Eventually he and Andrew Haley concluded that I had
written working code, but this was pure luck because I knew nothing of theory
and didn't do any tested (somewhat like a monkey banging on a keyboard).

On Thursday, November 28, 2013 at 6:47:27 AM UTC-7, Albert van der Horst wrote:
> In article <eqKdnSUOWM1xtgrP...@supernews.com>,
> Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> >Bernd Paysan <bernd....@gmx.de> wrote:
> >>
> >> LC53 is a maximum period linear congruent random number generator -
> >> so far, so good. It has the usual problems of LCGs, so it doesn't
> >> pass any serious randomness test suite. It is certainly not worse
> >> than others,
> >
> >Did you really mean to say that? All we know is that it is not
> >certainly worse. I doubt very much that a generator chosen without
> >any theoretical justification or testing is as good as any. It's not
> >impossible, but it would be a fantastic stroke of luck.
> Sure Hugh got lucky...

Bernd Paysan is another clown.
He is completely missing the point of LC53 --- I wanted a simple 32-bit
linear-congruential generator as an easy introduction into encryption cracking.
LC53 was not intended to be a strong prng that passes a "serious randomness
test suite."

All of the Forth-2020 enthusiasts attack my code with the intention of
proving that I'm incompetent. They are not positive contributors.
They don't deserve to be given source-code, which is why I demand that
they remove all mention of my novice-package from their website.
These are truly evil people! I want them to leave me alone!

[Hans Bezemer]

On Wednesday, March 1, 2023 at 8:22:42 AM UTC+1, Hugh Aguilar wrote:
> I demand that my novice package should be removed from the
> www.Forth2020 website. This is grossly unethical to post my code on
> your website when I have clearly said that you don't have my permission.

You lost that right the moment you published your code with a reference
to the BSD license. There is as little you can do as I can do reassigning
previous releases of my code under the LGPL v3 license. Any concessions
people do is pure courtesy.

> All of the Forth-2020 enthusiasts attack my code with the intention of
> proving that I'm incompetent.

Yeah, right, Hugh. Everybody is out to get you. That's their main purpose in
live. But frankly, I think you damaged your reputation more than anyone on
c.l.f could or would ever do.

> These are truly evil people! I want them to leave me alone!

Somehow this reminds me of South Parks "World Privacy Tour".

Hans Bezemer

[none albert]

In article <dd89d6ba-aada-4969...@googlegroups.com>,
Hugh Aguilar <hughag...@gmail.com> wrote:
<SNIP>

>In this thread Albert van der Horst repeated posted non-working crap code
>that looked similar to my code, but he was lying --- it wasn't my code.
>He was telling these lies about me to support his claim that I'm incompetent
>and he is an expert. Eventually he and Andrew Haley concluded that I had
>written working code, but this was pure luck because I knew nothing of theory
>and didn't do any tested (somewhat like a monkey banging on a keyboard).

This are a bunch of Trumpian lies. Especially if you accuse me of lying,
it was a honest mistake. I certainly am an expert, but you are just
conditionally incompetent.
Anyhow I made a promise to redress the contribution I made on wikipedia.
Apparently you prefer to rant about it, since a decenium now.