VFX Forth 64 v5.42 is avalable for download.

Changes are mainly to the selectable floating point pack system, which is now
properly integrated with the EXTERN mechanism, callbacks, and locals.

There is a new callback mechanism e.g. for Windows:
DefCallProc: int WinProc2(
HWND myhandle, UINT message, WPARAM wparam1, LPARAM lparam
):
\ hwnd msg wparam lparam -- int
{: hwnd msg wparam lparam -- int :} \ can use local variables
case msg
...
endcase
;

When the callback WinProc2 is executed it returns the entry point needed by
the operating system.

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

On Thursday, September 28, 2023 at 2:41:38 AM UTC-7, Stephen Pelc wrote:
> VFX Forth 64 v5.42 is avalable for download.
>
> Changes are mainly to the selectable floating point pack system, which is now
> properly integrated with the EXTERN mechanism, callbacks, and locals.
>
> There is a new callback mechanism e.g. for Windows:
> DefCallProc: int WinProc2(
> HWND myhandle, UINT message, WPARAM wparam1, LPARAM lparam
> ):
> \ hwnd msg wparam lparam -- int
> {: hwnd msg wparam lparam -- int :} \ can use local variables
> case msg
> ...
> endcase
> ;
>
> When the callback WinProc2 is executed it returns the entry point needed by
> the operating system.
>
> Stephen

Lets not forget that Stephen Pelc sabotaged VFX to prevent
my novice package from compiling:
https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08/m/os5OYTOeBAAJ

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

On Thursday, 28 September 2023 at 16:40:28 UTC+1, Hugh Aguilar wrote:
> On Thursday, September 28, 2023 at 2:41:38 AM UTC-7, Stephen Pelc wrote:
> > VFX Forth 64 v5.42 is avalable for download.
> >
> > Changes are mainly to the selectable floating point pack system, which is now
> > properly integrated with the EXTERN mechanism, callbacks, and locals.
> >
> > There is a new callback mechanism e.g. for Windows:
> > DefCallProc: int WinProc2(
> > HWND myhandle, UINT message, WPARAM wparam1, LPARAM lparam
> > ):
> > \ hwnd msg wparam lparam -- int
> > {: hwnd msg wparam lparam -- int :} \ can use local variables
> > case msg
> > ...
> > endcase
> > ;
> >
> > When the callback WinProc2 is executed it returns the entry point needed by
> > the operating system.
> >
> > Stephen
> Lets not forget that Stephen Pelc sabotaged VFX to prevent
> my novice package from compiling:
> https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08/m/os5OYTOeBAAJ
>
> 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

You are back on trying to bullshit again.
But the few people here know who you are and what you do.

You shit on Testra
You shit on MPE
Probably as well on Forth INC.
You shit an anything Forth.
So any commercial Forth company.

I do not believe MPE did anything like this.
BUT ANY commercial supplier should get a clapping to keep your shit out.

Who the fuck do you think you are ???
Get your medication and go back into your mental home.
Close the door behind you and throw the keys away.

On Thursday, September 28, 2023 at 5:40:28 PM UTC+2, Hugh Aguilar wrote:
> Lets not forget that Stephen Pelc sabotaged VFX to prevent
> my novice package from compiling:
> https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08/m/os5OYTOeBAAJ
Who cares..
First: you're the only one using it;
Second: a real man writes his own compiler - like everybody else here. Something a
maintenance programmer like you is obviously not capable of.

Hans Bezemer

On 10/10/2023 3:23 am, Hans Bezemer wrote:
> On Thursday, September 28, 2023 at 5:40:28 PM UTC+2, Hugh Aguilar wrote:
>> Lets not forget that Stephen Pelc sabotaged VFX to prevent
>> my novice package from compiling:
>> https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08/m/os5OYTOeBAAJ
> Who cares..
> First: you're the only one using it;

The latest VFX appears to pass Hugh's test:

https://groups.google.com/g/comp.lang.forth/c/Fmr2UH5FeoE/m/MhBlTcNiEgAJ

If anyone has found something that looks like a bug, they should definitely
report it to the creator. If they're as excited by it as you are, it will
make their day.

> Second: a real man writes his own compiler - like everybody else here. Something a
> maintenance programmer like you is obviously not capable of.

Easier to blame someone else for one's own lack of progress.

Great news! It’s there a way for me to test this? On the tobit Forth notion, I’d like to post the following, mostly as a question to VFX and the rest of the Forthers here:

I see a significant opportunity for Forth in the sector I’m terming Big Iron, observing notable trends such as the successful progression and bare-metal focus of unikernels. The push away from hypervisors is palpable, and considering trends in cloud offerings, bare metal instances are expanding more rapidly than anticipated, with an estimated yearly revenue between 24B to 30B by 2026. Despite VXF being 64-bit, it remains a hosted app and, in my humble opinion, there’s potential for Forth to capitalize on these trends, utilizing its distinct value to gain broader acceptance in the enterprise, especially given its origin in Big Iron and transition to embedded or hosted systems.

This thinking leads to a thought-provoking query: A Forth for Cloud? Forth, with its hardware-centric, interactive nature, forge a novel foundation for cloud and serverless environments? Key points I consider that would be considered.

**Interactive System Access**: Forth’s capability for direct memory inspection and modification could streamline debugging and profiling. This might bring a higher number of developers to write simple server-less apps. The nature of Forth would allow for these self contained applications with in a physical server, with a share nothing approach *longer discussion * where a an application hosts it’s own dictionary with memory isolation, allowing for as close to the metal development for more stringent applications.

**Minimal Attack Surface**: Forth’s compact footprint, often less than 100KB, implies a smaller attack surface, indicating potential for increased security. * overly simplifying this * it would allow for an memory and resource isolation levels where even the common hardware services like networking would be addressed though a masked memory space, limiting acceded to the HW itself and given the developer more freedom in their techniques to further optimize their apps.

**Parallel Execution Potential**: Static analysis of the Forth dictionary might allow for specific word or task assignment to individual CPU cores, paralleling the thread-per-core approach, and possibly avoiding traditional thread management overheads. Again, this would be a new concept, but it could allow for a simplistic approach to parallel execution on a server, optimizing resources.

Could these *new attributes* make Forth a viable foundation for developing efficient, secure, and parallel systems for specialized cloud applications, and are there unseen challenges or drawbacks to this approach?

**Economic motivation**

Drawing from my own experiential intuition, there’s a significant cost overhead—roughly 30% on hardware (CPU and Memory)—attributable to utilizing OSs that were originally architected to facilitate human interaction and inherently embody extensive code bases. This scenario is further “complexified” when we overlay multiple OS layers (like VM’s or containers) libraries, and additional software to execute applications.

Considering the financials, an average server incurs an expenditure of 15-20K buy out cost, with an additional 20K annually on software to execute applications, and another 10K annually to account for footprint costs. The potential savings here are substantial—around 10K - 30K a year per server.

Scaling this to a substantial enterprise operating, for instance, 500 servers, the financial implication is pronounced. The Return on Investment (ROI) is likely even more compelling, considering the accumulated savings in various other domains, and this holds true even if the performance efficiency achieved is merely on par with current systems.

Drawing again on those Financials, * https://www.futuremarketinsights.com/reports/embedded-hypervisor-market#:~:text=The%20embedded%20hypervisor%20market%20is,at%20a%20CAGR%20of%207.7%25. *

This is a 12Billion dollar market share, it would allow for a 1% market share of 120M.

Thoughts?

SpainHackForth schrieb am Dienstag, 10. Oktober 2023 um 11:18:36 UTC+2:
> Thoughts?
How was the weed? ;-)

On Tuesday, October 10, 2023 at 5:18:36 AM UTC-4, SpainHackForth wrote:
> Great news! It’s there a way for me to test this? On the tobit Forth notion, I’d like to post the following, mostly as a question to VFX and the rest of the Forthers here:
>
> I see a significant opportunity for Forth in the sector I’m terming Big Iron, observing notable trends such as the successful progression and bare-metal focus of unikernels. The push away from hypervisors is palpable, and considering trends in cloud offerings, bare metal instances are expanding more rapidly than anticipated, with an estimated yearly revenue between 24B to 30B by 2026. Despite VXF being 64-bit, it remains a hosted app and, in my humble opinion, there’s potential for Forth to capitalize on these trends, utilizing its distinct value to gain broader acceptance in the enterprise, especially given its origin in Big Iron and transition to embedded or hosted systems.
>
> This thinking leads to a thought-provoking query: A Forth for Cloud? Forth, with its hardware-centric, interactive nature, forge a novel foundation for cloud and serverless environments? Key points I consider that would be considered.
>
> **Interactive System Access**: Forth’s capability for direct memory inspection and modification could streamline debugging and profiling. This might bring a higher number of developers to write simple server-less apps. The nature of Forth would allow for these self contained applications with in a physical server, with a share nothing approach *longer discussion * where a an application hosts it’s own dictionary with memory isolation, allowing for as close to the metal development for more stringent applications.
>
> **Minimal Attack Surface**: Forth’s compact footprint, often less than 100KB, implies a smaller attack surface, indicating potential for increased security. * overly simplifying this * it would allow for an memory and resource isolation levels where even the common hardware services like networking would be addressed though a masked memory space, limiting acceded to the HW itself and given the developer more freedom in their techniques to further optimize their apps.
>
> **Parallel Execution Potential**: Static analysis of the Forth dictionary might allow for specific word or task assignment to individual CPU cores, paralleling the thread-per-core approach, and possibly avoiding traditional thread management overheads. Again, this would be a new concept, but it could allow for a simplistic approach to parallel execution on a server, optimizing resources.
>
> Could these *new attributes* make Forth a viable foundation for developing efficient, secure, and parallel systems for specialized cloud applications, and are there unseen challenges or drawbacks to this approach?
>
> **Economic motivation**
>
> Drawing from my own experiential intuition, there’s a significant cost overhead—roughly 30% on hardware (CPU and Memory)—attributable to utilizing OSs that were originally architected to facilitate human interaction and inherently embody extensive code bases. This scenario is further “complexified” when we overlay multiple OS layers (like VM’s or containers) libraries, and additional software to execute applications.
>
> Considering the financials, an average server incurs an expenditure of 15-20K buy out cost, with an additional 20K annually on software to execute applications, and another 10K annually to account for footprint costs. The potential savings here are substantial—around 10K - 30K a year per server.
>
> Scaling this to a substantial enterprise operating, for instance, 500 servers, the financial implication is pronounced. The Return on Investment (ROI) is likely even more compelling, considering the accumulated savings in various other domains, and this holds true even if the performance efficiency achieved is merely on par with current systems.
>
> Drawing again on those Financials, * https://www.futuremarketinsights.com/reports/embedded-hypervisor-market#:~:text=The%20embedded%20hypervisor%20market%20is,at%20a%20CAGR%20of%207.7%25. *
>
> This is a 12Billion dollar market share, it would allow for a 1% market share of 120M.
>
> Thoughts?

Having come from a senior level in a Fortune 500 company I like your enthusiasm and the application
of some market size numbers in your explanation of the opportunity. Bravo.

With no other reference than your post what you say makes sense. Forth was invented to
provide advantages over existing software development methods so why could it not be applied here?

The challenge is that Forth lost a market war back in the 1990s. Forth is odd. Business people
don't like odd. G_d knows Forth Inc. and MPE under Stephen Pelc have spent their lives selling the
Forth solution to various computing domains and they have made some inroads against the headwinds.

As a general rule in business, after a product is working well enough (note: not perfect, not the best)
and it fills an actual need for people, _ALL_ that matters to make it move is _MONEY_ to do :

- Marketing: one to many communication targeted to the people who need the thing
via any medium that can reach them effectively

- Sales: fostering human relationships (the challenging part for techies) with decision makers who
approve expenditures. (sales people are actually psychologists)

- Pricing: It always helps if your solution is a bit cheaper than the alternatives. (but not too cheap)

- Availability: People have to know where to buy it. The internet is handy that way. :-)

So build your product, spend that money wisely, creating the right marketing and sales strategy
and you will get some revenue. The game is to make that revenue self-sustaining.
Oh, and don't make mistakes as the business scales up.

(And.. the market will react and change your reality so you have to adjust)

On Monday, October 9, 2023 at 9:23:14 AM UTC-7, Hans Bezemer wrote:
> On Thursday, September 28, 2023 at 5:40:28 PM UTC+2, Hugh Aguilar wrote:
> > Lets not forget that Stephen Pelc sabotaged VFX to prevent
> > my novice package from compiling:
> > https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08/m/os5OYTOeBAAJ
> Who cares..
> First: you're the only one using it;
> Second: a real man writes his own compiler - like everybody else here. Something a
> maintenance programmer like you is obviously not capable of.
>
> Hans Bezemer

A real Forth programmer gets paid for writing a Forth compiler.
I did get paid for writing MFX, although it wasn't very much money.
How much did you get paid for writing 4TH? You have claimed that your
4TH for the 8086 is "Harvard Architecture" --- considering that you have
achieved the impossible, it should be worth a million dollars!

You are just a troll --- accusing me of being a maintenance programmer
is an attempt at provoking an angry denial --- this is foolish because
I'm obviously not a maintenance programmer, and I don't care enough
about you to have an emotional response to your troll attack.

On Tuesday, October 10, 2023 at 11:54:18 AM UTC-5, Brian Fox wrote:
>
> So build your product, spend that money wisely, creating the right marketing and sales strategy

Marketing 101:
Sell the product first then build it (if you must).

--
me

On Tuesday, October 10, 2023 at 9:57:46 PM UTC-4, S Jack wrote:
> On Tuesday, October 10, 2023 at 11:54:18 AM UTC-5, Brian Fox wrote:
> >
> > So build your product, spend that money wisely, creating the right marketing and sales strategy
> Marketing 101:
> Sell the product first then build it (if you must).

Haha. I like it. :-)
And even without signed contracts the VP of sales should know who the targets are and have created a
pro-forma sales plan that commits their backside to how much revenue comes in over at least the 1st 3 years.
(and they always are over-optimistic so fudge their numbers accordingly)

It's a risky game to sell "vapour" with software products I think.
Fred Brooks' experience and all that.

On 11/10/2023 12:26 pm, Hugh Aguilar wrote:
> On Monday, October 9, 2023 at 9:23:14 AM UTC-7, Hans Bezemer wrote:
>> On Thursday, September 28, 2023 at 5:40:28 PM UTC+2, Hugh Aguilar wrote:
>>> Lets not forget that Stephen Pelc sabotaged VFX to prevent
>>> my novice package from compiling:
>>> https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08/m/os5OYTOeBAAJ
>> Who cares..
>> First: you're the only one using it;
>> Second: a real man writes his own compiler - like everybody else here. Something a
>> maintenance programmer like you is obviously not capable of.
>>
>> Hans Bezemer
>
> A real Forth programmer gets paid for writing a Forth compiler.
> I did get paid for writing MFX, although it wasn't very much money.

It was also 30 years ago. Besides, you've threatened to write a forth
compiler. Those who produce compilers don't have an out. They can't
blame their boss, or complain the tools given to them were no good.

On 11/10/2023 1:39 pm, Brian Fox wrote:
> On Tuesday, October 10, 2023 at 9:57:46 PM UTC-4, S Jack wrote:
>> On Tuesday, October 10, 2023 at 11:54:18 AM UTC-5, Brian Fox wrote:
>>>
>>> So build your product, spend that money wisely, creating the right marketing and sales strategy
>> Marketing 101:
>> Sell the product first then build it (if you must).
>
> Haha. I like it. :-)
> And even without signed contracts the VP of sales should know who the targets are and have created a
> pro-forma sales plan that commits their backside to how much revenue comes in over at least the 1st 3 years.
> (and they always are over-optimistic so fudge their numbers accordingly)
>
> It's a risky game to sell "vapour" with software products I think.
> Fred Brooks' experience and all that.

Switch to finance where toxic debt abounds and selling it is 'caveat emptor'.