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

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

Oforth V0.9.24.1 released

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

Contents

  Oforth V0.9.24.1 released franck.bensusan@gmail.com - 2016-07-23 04:58 -0700
    Re: Oforth V0.9.24.1 released Cecil Bayona <cbayona@cbayona.com> - 2016-07-23 12:48 -0500
      Re: Oforth V0.9.24.1 released Doug Hoffman <glidedog@gmail.com> - 2016-07-23 14:05 -0400
        Re: Oforth V0.9.24.1 released Cecil Bayona <cbayona@cbayona.com> - 2016-07-23 14:35 -0500
          Re: Oforth V0.9.24.1 released hughaguilar96@gmail.com - 2016-07-23 14:04 -0700
            Re: Oforth V0.9.24.1 released Cecil Bayona <cbayona@cbayona.com> - 2016-07-23 16:51 -0500
        Re: Oforth V0.9.24.1 released hughaguilar96@gmail.com - 2016-07-23 14:09 -0700
          Re: Oforth V0.9.24.1 released franck.bensusan@gmail.com - 2016-07-24 03:40 -0700
            Re: Oforth V0.9.24.1 released hughaguilar96@gmail.com - 2016-07-24 19:09 -0700
              Re: Oforth V0.9.24.1 released franck.bensusan@gmail.com - 2016-07-25 15:17 -0700
        Re: Oforth V0.9.24.1 released franck.bensusan@gmail.com - 2016-07-24 03:26 -0700
      Re: Oforth V0.9.24.1 released franck.bensusan@gmail.com - 2016-07-24 03:25 -0700
        Re: Oforth V0.9.24.1 released Cecil Bayona <cbayona@cbayona.com> - 2016-07-24 12:44 -0500
          Re: Oforth V0.9.24.1 released franck.bensusan@gmail.com - 2016-07-24 12:42 -0700
            Re: Oforth V0.9.24.1 released Cecil Bayona <cbayona@cbayona.com> - 2016-07-24 15:43 -0500
              Re: Oforth V0.9.24.1 released franck.bensusan@gmail.com - 2016-07-25 15:12 -0700
          Re: Oforth V0.9.24.1 released Ron Aaron <rambamist@gmail.com> - 2016-07-25 06:46 +0300
            Re: Oforth V0.9.24.1 released Cecil Bayona <cbayona@cbayona.com> - 2016-07-24 23:28 -0500
              Re: Oforth V0.9.24.1 released Ron Aaron <rambamist@gmail.com> - 2016-07-25 07:45 +0300
                Re: Oforth V0.9.24.1 released Paul Rubin <no.email@nospam.invalid> - 2016-07-24 21:58 -0700
                  Re: Oforth V0.9.24.1 released Ron Aaron <rambamist@gmail.com> - 2016-07-25 08:21 +0300
                Re: Oforth V0.9.24.1 released Cecil Bayona <cbayona@cbayona.com> - 2016-07-25 00:05 -0500
                  Re: Oforth V0.9.24.1 released Ron Aaron <rambamist@gmail.com> - 2016-07-25 08:21 +0300
    Re: Oforth V0.9.24.1 released endlessboomcapitalism@gmail.com - 2016-07-26 10:00 -0700

Page 1 of 2  [1] 2  Next page →

#49364 — Oforth V0.9.24.1 released

Hello,

Oforth V0.9.24.1 is released. This version fixes minor bugs.
This version also adds some optimizations on native code generated.

Also, default is now to not generate data stack checks for underflow and
overflow (to generate them, use --C command line parameter).

For instance, with this version, the binarytree benchmark results are
(on a Core i7-4720HQ 2,60GHz running on Windows 10) : 
 
With 1 core used : about 18,5 seconds elapsed :

oforth --P"#[ 20 binarytree ] bench" --W1 examples/binarytree.of
stretch tree of depth 21         check: -1
2097152  trees of depth 4        check: -2097152
524288   trees of depth 6        check: -524288
131072   trees of depth 8        check: -131072
32768    trees of depth 10       check: -32768
8192     trees of depth 12       check: -8192
2048     trees of depth 14       check: -2048
512      trees of depth 16       check: -512
128      trees of depth 18       check: -128
32       trees of depth 20       check: -32
long lived tree of depth 20      check: -1
18410821


With 4 cores used : about 6,5 seconds elapsed :  

oforth --P"#[ 20 binarytree ] bench" --W4 examples/binarytree.of
stretch tree of depth 21         check: -1
2097152  trees of depth 4        check: -2097152
524288   trees of depth 6        check: -524288
131072   trees of depth 8        check: -131072
32768    trees of depth 10       check: -32768
8192     trees of depth 12       check: -8192
2048     trees of depth 14       check: -2048
512      trees of depth 16       check: -512
128      trees of depth 18       check: -128
32       trees of depth 20       check: -32
long lived tree of depth 20      check: -1
6376182

Franck
http://www.oforth.com

[toc] | [next] | [standalone]

#49371

On 7/23/2016 6:58 AM, franck.bensusan@gmail.com wrote:
> Hello,
>
> Oforth V0.9.24.1 is released. This version fixes minor bugs.
> This version also adds some optimizations on native code generated.
>
> Also, default is now to not generate data stack checks for underflow and
> overflow (to generate them, use --C command line parameter).
>
> For instance, with this version, the binarytree benchmark results are
> (on a Core i7-4720HQ 2,60GHz running on Windows 10) :
>
> With 1 core used : about 18,5 seconds elapsed :
>
> oforth --P"#[ 20 binarytree ] bench" --W1 examples/binarytree.of
> stretch tree of depth 21         check: -1
> 2097152  trees of depth 4        check: -2097152
> 524288   trees of depth 6        check: -524288
> 131072   trees of depth 8        check: -131072
> 32768    trees of depth 10       check: -32768
> 8192     trees of depth 12       check: -8192
> 2048     trees of depth 14       check: -2048
> 512      trees of depth 16       check: -512
> 128      trees of depth 18       check: -128
> 32       trees of depth 20       check: -32
> long lived tree of depth 20      check: -1
> 18410821
>
>
> With 4 cores used : about 6,5 seconds elapsed :
>
> oforth --P"#[ 20 binarytree ] bench" --W4 examples/binarytree.of
> stretch tree of depth 21         check: -1
> 2097152  trees of depth 4        check: -2097152
> 524288   trees of depth 6        check: -524288
> 131072   trees of depth 8        check: -131072
> 32768    trees of depth 10       check: -32768
> 8192     trees of depth 12       check: -8192
> 2048     trees of depth 14       check: -2048
> 512      trees of depth 16       check: -512
> 128      trees of depth 18       check: -128
> 32       trees of depth 20       check: -32
> long lived tree of depth 20      check: -1
> 6376182
>
> Franck
> http://www.oforth.com
>

Thanks for making the software available, but is there any chance the 
the documentation will be worked on?

It hard to deal with a Forth that is different, but at the same time not 
documented well.

-- 
Cecil - k5nwa

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

#49375

On 7/23/16 1:48 PM, Cecil Bayona wrote:
> On 7/23/2016 6:58 AM, franck.bensusan@gmail.com wrote:
>> Hello,
>>
>> Oforth V0.9.24.1 is released. This version fixes minor bugs.
>> This version also adds some optimizations on native code generated.
>>
>> Also, default is now to not generate data stack checks for underflow and
>> overflow (to generate them, use --C command line parameter).
>>
>> For instance, with this version, the binarytree benchmark results are
>> (on a Core i7-4720HQ 2,60GHz running on Windows 10) :
>>
>> With 1 core used : about 18,5 seconds elapsed :
>>
>> oforth --P"#[ 20 binarytree ] bench" --W1 examples/binarytree.of
>> stretch tree of depth 21         check: -1
>> 2097152  trees of depth 4        check: -2097152
>> 524288   trees of depth 6        check: -524288
>> 131072   trees of depth 8        check: -131072
>> 32768    trees of depth 10       check: -32768
>> 8192     trees of depth 12       check: -8192
>> 2048     trees of depth 14       check: -2048
>> 512      trees of depth 16       check: -512
>> 128      trees of depth 18       check: -128
>> 32       trees of depth 20       check: -32
>> long lived tree of depth 20      check: -1
>> 18410821
>>
>>
>> With 4 cores used : about 6,5 seconds elapsed :
>>
>> oforth --P"#[ 20 binarytree ] bench" --W4 examples/binarytree.of
>> stretch tree of depth 21         check: -1
>> 2097152  trees of depth 4        check: -2097152
>> 524288   trees of depth 6        check: -524288
>> 131072   trees of depth 8        check: -131072
>> 32768    trees of depth 10       check: -32768
>> 8192     trees of depth 12       check: -8192
>> 2048     trees of depth 14       check: -2048
>> 512      trees of depth 16       check: -512
>> 128      trees of depth 18       check: -128
>> 32       trees of depth 20       check: -32
>> long lived tree of depth 20      check: -1
>> 6376182
>>
>> Franck
>> http://www.oforth.com
>>
>
> Thanks for making the software available, but is there any chance the
> the documentation will be worked on?
>
> It hard to deal with a Forth that is different, but at the same time not
> documented well.

Documentation is most always time consuming and not easy, though I agree
more needs to be done here.

Franck has already made quite a few fundamental changes to Oforth to
make it "less different" than classic Forth:

New definitions now start with : (used to be something else)
Definitions now end with ; (used to be something else)
Locals now use the same ordering as the new ANS Forth (used to be
backwards like locals| )
Several message names have been changed like . (dot) used to be
something else like print)

Again, I agree that better documentation would be nice right now, but
Franck is also working hard on improving the internals of Oforth and
keeping Oforth multi-platform source compatible. Pretty impressive so far!

-Doug

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

#49377

On 7/23/2016 1:05 PM, Doug Hoffman wrote:
> On 7/23/16 1:48 PM, Cecil Bayona wrote:
>> On 7/23/2016 6:58 AM, franck.bensusan@gmail.com wrote:
>>> Hello,
>>>
>>> Oforth V0.9.24.1 is released. This version fixes minor bugs.
>>> This version also adds some optimizations on native code generated.
>>>
>>> Also, default is now to not generate data stack checks for underflow and
>>> overflow (to generate them, use --C command line parameter).
>>>
>>> For instance, with this version, the binarytree benchmark results are
>>> (on a Core i7-4720HQ 2,60GHz running on Windows 10) :
>>>
>>> With 1 core used : about 18,5 seconds elapsed :
>>>
>>> oforth --P"#[ 20 binarytree ] bench" --W1 examples/binarytree.of
>>> stretch tree of depth 21         check: -1
>>> 2097152  trees of depth 4        check: -2097152
>>> 524288   trees of depth 6        check: -524288
>>> 131072   trees of depth 8        check: -131072
>>> 32768    trees of depth 10       check: -32768
>>> 8192     trees of depth 12       check: -8192
>>> 2048     trees of depth 14       check: -2048
>>> 512      trees of depth 16       check: -512
>>> 128      trees of depth 18       check: -128
>>> 32       trees of depth 20       check: -32
>>> long lived tree of depth 20      check: -1
>>> 18410821
>>>
>>>
>>> With 4 cores used : about 6,5 seconds elapsed :
>>>
>>> oforth --P"#[ 20 binarytree ] bench" --W4 examples/binarytree.of
>>> stretch tree of depth 21         check: -1
>>> 2097152  trees of depth 4        check: -2097152
>>> 524288   trees of depth 6        check: -524288
>>> 131072   trees of depth 8        check: -131072
>>> 32768    trees of depth 10       check: -32768
>>> 8192     trees of depth 12       check: -8192
>>> 2048     trees of depth 14       check: -2048
>>> 512      trees of depth 16       check: -512
>>> 128      trees of depth 18       check: -128
>>> 32       trees of depth 20       check: -32
>>> long lived tree of depth 20      check: -1
>>> 6376182
>>>
>>> Franck
>>> http://www.oforth.com
>>>
>>
>> Thanks for making the software available, but is there any chance the
>> the documentation will be worked on?
>>
>> It hard to deal with a Forth that is different, but at the same time not
>> documented well.
>
> Documentation is most always time consuming and not easy, though I agree
> more needs to be done here.
>
> Franck has already made quite a few fundamental changes to Oforth to
> make it "less different" than classic Forth:
>
> New definitions now start with : (used to be something else)
> Definitions now end with ; (used to be something else)
> Locals now use the same ordering as the new ANS Forth (used to be
> backwards like locals| )
> Several message names have been changed like . (dot) used to be
> something else like print)
>
> Again, I agree that better documentation would be nice right now, but
> Franck is also working hard on improving the internals of Oforth and
> keeping Oforth multi-platform source compatible. Pretty impressive so far!
>
> -Doug
>
It's appreciated, the hard work put into designing, coding, and testing 
a complex piece of software. Documentation is not a fun thing to do, 
it's boring compared to adding new features and seeing them work, but 
for the software to be of much use to others documentation is vital.

Myself when I embark on a project I start with the documentation, to 
clearly state my goals in the project and a general outline on how to 
solve it. From there I maintain and keep the documentation up to date as 
I write and test code, I found that documenting after the fact rarely 
gets done in my case so I work that way to make sure that years later 
the project is well documented.

Even in old projects not well documented, I would add the documentation 
on added features as I made changes to the project so at least new 
features were well documented, I usually found that once started it was 
hard to stop and I would add documentation to other parts of a project, 
eventually it was all documented.

Recently while going through stuff in the garage, I found the notebooks 
on two projects I programmed over 10 years ago,, one in Forth, the other 
in Delphi, it was not difficult to understand the projects by reading 
the documentation, which was my purpose in setting that documentation 
style for myself. Part of that documenting procedure is to document each 
word or function as they are entered so the purpose of the module, the 
input data, and the results are documented.

I have Oforth installed in my main two PCs so I could try it out, I been 
looking for a tool that would work well in a project that I been mulling 
over a few years, now that I'm retired I have more time so I been 
thinking about it again. The project would involve massive text 
manipulation so I figure text, list or even lowly linked list capability 
would be a great help in the project. There are some non-Forth languages 
available that have good tools in that area but I rather use Forth or 
something based on the Forth ideas.
-- 
Cecil - k5nwa

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

#49380

On Saturday, July 23, 2016 at 12:35:17 PM UTC-7, Cecil - k5nwa wrote:
> The project would involve massive text 
> manipulation so I figure text, list or even lowly linked list capability 
> would be a great help in the project. 

That sounds like something my string-stack.4th list.4th and association.4th could be used for. I have an upgrade to string-stack. 4th with some minor bug fixes.

Can you tell us something about your project?

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

#49382

On 7/23/2016 4:04 PM, hughaguilar96@gmail.com wrote:
> On Saturday, July 23, 2016 at 12:35:17 PM UTC-7, Cecil - k5nwa wrote:
>> The project would involve massive text
>> manipulation so I figure text, list or even lowly linked list capability
>> would be a great help in the project.
>
> That sounds like something my string-stack.4th list.4th and association.4th could be used for. I have an upgrade to string-stack. 4th with some minor bug fixes.
>
> Can you tell us something about your project?
>
Basically a general purpose macro processor, it would take an input text 
file, and a template for conversion and would proceed to apply the rules 
in the templates to the source text and translate them, the translated 
output could be optionally be translated again until it runs out of 
rules that apply.

In the Forth universe the Forth compiler name "Timbre" and somewhat does 
what I want, but I'm not happy with the documentation and the fact that 
it is written in "C" without comments, so in case of future problems I 
am in a weak position to be able to fix it. Timbre has the advantage 
that the conversion templates can include Forth code to help in the 
conversion process.
<   http://clubweb.interbaun.com/~rc/Timbre/index.html  >

A long time ago I used a package called "Stage2", it was written in 
Fortran, I used it to translate itself into assembler and that version 
was used in several projects to 100% translate "C" code to Turbo Pascal, 
and Forth to assembler, it worked quite well, one would write a set of 
translating rules and they would convert source text to a final form.
< 
http://dl.acm.org/citation.cfm?id=362691&dl=ACM&coll=DL&CFID=817177146&CFTOKEN=99137370 
  >

I was a conundrum, it was very primitive Fortran code that treated a 
source file as a giant character list, yet it allowed you to do some 
very sophisticated conversions, for example; I created a fully working 
Forth Translator that supported the complete Forth language at the time, 
including defining other words, and creating code words. This was in the 
70's when I last worked with it.

Another program I have used in a similar vein is "Gema".
<  http://gema.sourceforge.net/new/index.shtml  >

-- 
Cecil - k5nwa

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

#49381

On Saturday, July 23, 2016 at 11:05:37 AM UTC-7, Doug Hoffman wrote:
> Franck has already made quite a few fundamental changes to Oforth to
> make it "less different" than classic Forth:
> 
> New definitions now start with : (used to be something else)
> Definitions now end with ; (used to be something else)
> Locals now use the same ordering as the new ANS Forth (used to be
> backwards like locals| )
> Several message names have been changed like . (dot) used to be
> something else like print)

Having the locals declarations backwards was what turned me of on Oforth --- maybe I will look at it again.

If Franck fixes the quotations so they have access to the parent function's local variables, then I will definitely be interested. :-) You can do it Franck! It is not that complicated!

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

#49388

Le samedi 23 juillet 2016 23:09:47 UTC+2, hughag...@gmail.com a écrit :
> On Saturday, July 23, 2016 at 11:05:37 AM UTC-7, Doug Hoffman wrote:
> > Franck has already made quite a few fundamental changes to Oforth to
> > make it "less different" than classic Forth:
> > 
> > New definitions now start with : (used to be something else)
> > Definitions now end with ; (used to be something else)
> > Locals now use the same ordering as the new ANS Forth (used to be
> > backwards like locals| )
> > Several message names have been changed like . (dot) used to be
> > something else like print)
> 
> Having the locals declarations backwards was what turned me of on Oforth --- maybe I will look at it again.
> 
> If Franck fixes the quotations so they have access to the parent function's local variables, then I will definitely be interested. :-) You can do it Franck! It is not that complicated!

Quotations have access to parent local, but these locals can't be updated
(quotations hold a copy of these values).

Yes, that is not complicated to allow this. In fact it would be simpler
(no need to copy the values). 

But not being able to update parent locals is an intentional choice as
this would be a huge break in task isolation in a multi-threading context 
as one task could update a value seen by another task if the quotation is
shared.

Oforth has no mutex, no semaphore, ... nothing but channels to synchronize
tasks. It is required that 2 tasks can't update the same object 
simulteanously. If quotations are allowed to update parent locals, everything
collapses. 

In fact, this would break a lot of Oforth principles (immutability, 
isolation, ....).

And, even without this problem, imo, what quotations really need is to see 
parent locals, but not to be able to update them. At least, I have never feel
the need to this.

Franck.

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

#49418

On Sunday, July 24, 2016 at 3:40:12 AM UTC-7, franck....@gmail.com wrote:
> Le samedi 23 juillet 2016 23:09:47 UTC+2, hughag...@gmail.com a écrit :
> > If Franck fixes the quotations so they have access to the parent function's local variables, then I will definitely be interested. :-) You can do it Franck! It is not that complicated!
> 
> Quotations have access to parent local, but these locals can't be updated
> (quotations hold a copy of these values).
> 
> Yes, that is not complicated to allow this. In fact it would be simpler
> (no need to copy the values). 
> 
> But not being able to update parent locals is an intentional choice as
> this would be a huge break in task isolation in a multi-threading context 
> as one task could update a value seen by another task if the quotation is
> shared.

You're worrying about nothing! Quotations aren't going to be shared.

Look at this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B126-150%5D

I said that the rules are:
1.) A HOF calls a quotation with REX.
2.) A HOF can not call another HOF.

So how would a quotation be shared?

> Oforth has no mutex, no semaphore, ... nothing but channels to synchronize
> tasks. It is required that 2 tasks can't update the same object 
> simulteanously. If quotations are allowed to update parent locals, everything
> collapses. 
> 
> In fact, this would break a lot of Oforth principles (immutability, 
> isolation, ....).

I would like to get multi-core support similar to Oforth in Straight Forth --- I'm not clear on how to do this, so maybe you are right, but I doubt it --- if quotations can't be supported along with multi-core support though, then I would just forget about multi-core support because quotations are more important.

Straight Forth is primarily intended to be a platform for a cross-compiler, so I don't need multi-core support for this. Can Oforth be used for this? From what I've seen of it, the answer is no.

Straight Forth is also intended to be used for numeric programs --- this could benefit from multi-core support in the cases where multiple calculations can be done in parallel because they don't use the result(s) of the other calculation(s) as arguments --- these cases are pretty rare though, so multi-core support may not be all that important.

The only thing I can think of multi-core support being really useful for, is searching. If you are going to search through data for a match, you might as well let each core search part of the data and do this in parallel. There are also some inherently parallel programs, such as the Life game, but I've never seen any that had any real-world value. What do you use multi-core support for in oForth?

> And, even without this problem, imo, what quotations really need is to see 
> parent locals, but not to be able to update them. At least, I have never feel
> the need to this.

The whole point of having quotations is that they can upfeed data to the parent function! If you are not going to have that, then you might as well not have quotations at all --- just use regular functions.

Look at that thread I provided the link for --- look at my hottie-counting program --- how would you do that in Oforth without using global variables?

Of course, if you use global variables, your immutability and isolation are lost, which you described as "Oforth principles." Immutability and isolation are ideals, but they are going to be lost in a lot of cases --- it is better to use rquotations and local variables than to use global variables --- if you use global variables then you have no idea which functions might be modifying them and you have completely lost control.

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

#49502

Le lundi 25 juillet 2016 04:09:11 UTC+2, hughag...@gmail.com a écrit :
> 
> You're worrying about nothing! Quotations aren't going to be shared.
> 
> Look at this thread:
> https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B126-150%5D
> 
> I said that the rules are:
> 1.) A HOF calls a quotation with REX.
> 2.) A HOF can not call another HOF.
> 
> So how would a quotation be shared?
>

Well, what can I say ? I'am not worrying about nothing as, in Oforth, 
quotations can be shared.
These rules are simply not Oforth rules for the quotations.

If you write : 
#[ 10 . ] &
the quotation will be performed in parallel into a separated task.

If you write : 
#[ 10 . ] dup &
the quotation is now shared between two tasks.

And if you write : 

: test( a -- b ) 
   #[ 10 ->a a . ] & 
   12 ->a 
   a ;

If the quotation could update parent local, you couldn't tell what is
the value returned by #test (it could be 10 or 12) nor the value printed
by the other task (it could be 10 or 12).

 
> I would like to get multi-core support similar to Oforth in Straight Forth --- I'm not clear on how to do this, so maybe you are right, but I doubt it --- if quotations can't be supported along with multi-core support though, then I would just forget about multi-core support because quotations are more important.
>
> Straight Forth is primarily intended to be a platform for a cross-compiler, so I don't need multi-core support for this. Can Oforth be used for this? From what I've seen of it, the answer is no.
> 
> Straight Forth is also intended to be used for numeric programs --- this could benefit from multi-core support in the cases where multiple calculations can be done in parallel because they don't use the result(s) of the other calculation(s) as arguments --- these cases are pretty rare though, so multi-core support may not be all that important.

If you target desktops or servers, a multi-threading support is more
important than quotations. Unless you dedicate your language for 
cross compilation, of course.

> The only thing I can think of multi-core support being really useful for, is searching. If you are going to search through data for a match, you might as well let each core search part of the data and do this in parallel. There are also some inherently parallel programs, such as the Life game, but I've never seen any that had any real-world value. What do you use multi-core support for in oForth?

Multi-threading is used a lot when you write servers (TCP, HTTP, REST, ...)

 > > And, even without this problem, imo, what quotations really need is to see 
> > parent locals, but not to be able to update them. At least, I have never feel
> > the need to this.
> 
> The whole point of having quotations is that they can upfeed data to the parent function! If you are not going to have that, then you might as well not have quotations at all --- just use regular functions.

No, I don't think so. Upfeeding data to the parent function is, at best, 
a minor feature. I have written a lot of quotations and closure and never 
feel the need of this.


> Look at that thread I provided the link for --- look at my hottie-counting program --- how would you do that in Oforth without using global variables?
> 
> Of course, if you use global variables, your immutability and isolation are lost, which you described as "Oforth principles." Immutability and isolation are ideals, but they are going to be lost in a lot of cases --- it is better to use rquotations and local variables than to use global variables --- if you use global variables then you have no idea which functions might be modifying them and you have completely lost control.


This is not allowed in Oforth. There is no way to define a global 
variable shared by different tasks.

VARIABLE word does not exist in Oforth. It is designed to forbid 
the lost of immutability and isolation between tasks.
Allowing update of parent local would break this.

Franck

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

#49387

Le samedi 23 juillet 2016 20:05:37 UTC+2, Doug Hoffman a écrit :
> On 7/23/16 1:48 PM, Cecil Bayona wrote:
> > On 7/23/2016 6:58 AM, franck.bensusan@gmail.com wrote:
> >> Hello,
> >>
> >> Oforth V0.9.24.1 is released. This version fixes minor bugs.
> >> This version also adds some optimizations on native code generated.
> >>
> >> Also, default is now to not generate data stack checks for underflow and
> >> overflow (to generate them, use --C command line parameter).
> >>
> >> For instance, with this version, the binarytree benchmark results are
> >> (on a Core i7-4720HQ 2,60GHz running on Windows 10) :
> >>
> >> With 1 core used : about 18,5 seconds elapsed :
> >>
> >> oforth --P"#[ 20 binarytree ] bench" --W1 examples/binarytree.of
> >> stretch tree of depth 21         check: -1
> >> 2097152  trees of depth 4        check: -2097152
> >> 524288   trees of depth 6        check: -524288
> >> 131072   trees of depth 8        check: -131072
> >> 32768    trees of depth 10       check: -32768
> >> 8192     trees of depth 12       check: -8192
> >> 2048     trees of depth 14       check: -2048
> >> 512      trees of depth 16       check: -512
> >> 128      trees of depth 18       check: -128
> >> 32       trees of depth 20       check: -32
> >> long lived tree of depth 20      check: -1
> >> 18410821
> >>
> >>
> >> With 4 cores used : about 6,5 seconds elapsed :
> >>
> >> oforth --P"#[ 20 binarytree ] bench" --W4 examples/binarytree.of
> >> stretch tree of depth 21         check: -1
> >> 2097152  trees of depth 4        check: -2097152
> >> 524288   trees of depth 6        check: -524288
> >> 131072   trees of depth 8        check: -131072
> >> 32768    trees of depth 10       check: -32768
> >> 8192     trees of depth 12       check: -8192
> >> 2048     trees of depth 14       check: -2048
> >> 512      trees of depth 16       check: -512
> >> 128      trees of depth 18       check: -128
> >> 32       trees of depth 20       check: -32
> >> long lived tree of depth 20      check: -1
> >> 6376182
> >>
> >> Franck
> >> http://www.oforth.com
> >>
> >
> > Thanks for making the software available, but is there any chance the
> > the documentation will be worked on?
> >
> > It hard to deal with a Forth that is different, but at the same time not
> > documented well.
> 
> Documentation is most always time consuming and not easy, though I agree
> more needs to be done here.
> 
> Franck has already made quite a few fundamental changes to Oforth to
> make it "less different" than classic Forth:
> 
> New definitions now start with : (used to be something else)
> Definitions now end with ; (used to be something else)
> Locals now use the same ordering as the new ANS Forth (used to be
> backwards like locals| )
> Several message names have been changed like . (dot) used to be
> something else like print)
> 
> Again, I agree that better documentation would be nice right now, but
> Franck is also working hard on improving the internals of Oforth and
> keeping Oforth multi-platform source compatible. Pretty impressive so far!
> 
> -Doug

Thank you, Doug.

Having now Oforth mainly written in Oforth itself helps a lot, here.
But yes, this is still very time consuming :)

That is why I'am waiting to have most code written in Oforth before
releasing the ARM version (and Oforth sources).

Franck

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

#49386

Le samedi 23 juillet 2016 19:48:14 UTC+2, Cecil - k5nwa a écrit :
> On 7/23/2016 6:58 AM, franck.bensusan@gmail.com wrote:
> > Hello,
> >
> > Oforth V0.9.24.1 is released. This version fixes minor bugs.
> > This version also adds some optimizations on native code generated.
> >
> > Also, default is now to not generate data stack checks for underflow and
> > overflow (to generate them, use --C command line parameter).
> >
> > For instance, with this version, the binarytree benchmark results are
> > (on a Core i7-4720HQ 2,60GHz running on Windows 10) :
> >
> > With 1 core used : about 18,5 seconds elapsed :
> >
> > oforth --P"#[ 20 binarytree ] bench" --W1 examples/binarytree.of
> > stretch tree of depth 21         check: -1
> > 2097152  trees of depth 4        check: -2097152
> > 524288   trees of depth 6        check: -524288
> > 131072   trees of depth 8        check: -131072
> > 32768    trees of depth 10       check: -32768
> > 8192     trees of depth 12       check: -8192
> > 2048     trees of depth 14       check: -2048
> > 512      trees of depth 16       check: -512
> > 128      trees of depth 18       check: -128
> > 32       trees of depth 20       check: -32
> > long lived tree of depth 20      check: -1
> > 18410821
> >
> >
> > With 4 cores used : about 6,5 seconds elapsed :
> >
> > oforth --P"#[ 20 binarytree ] bench" --W4 examples/binarytree.of
> > stretch tree of depth 21         check: -1
> > 2097152  trees of depth 4        check: -2097152
> > 524288   trees of depth 6        check: -524288
> > 131072   trees of depth 8        check: -131072
> > 32768    trees of depth 10       check: -32768
> > 8192     trees of depth 12       check: -8192
> > 2048     trees of depth 14       check: -2048
> > 512      trees of depth 16       check: -512
> > 128      trees of depth 18       check: -128
> > 32       trees of depth 20       check: -32
> > long lived tree of depth 20      check: -1
> > 6376182
> >
> > Franck
> > http://www.oforth.com
> >
> 
> Thanks for making the software available, but is there any chance the 
> the documentation will be worked on?
> 
> It hard to deal with a Forth that is different, but at the same time not 
> documented well.
> 
> -- 
> Cecil - k5nwa

Hello,

You are right. And I agree that this is very important.

Currently, I'am focused on Oforth V1.0 version (and its documentation)
but I will release the doc first.

Did you run all the tutorials ?

Franck

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

#49394

On 7/24/2016 5:25 AM, franck.bensusan@gmail.com wrote:
> Le samedi 23 juillet 2016 19:48:14 UTC+2, Cecil - k5nwa a écrit :
>> On 7/23/2016 6:58 AM, franck.bensusan@gmail.com wrote:
>>> Hello,
>>>
>>> Oforth V0.9.24.1 is released. This version fixes minor bugs.
>>> This version also adds some optimizations on native code generated.
>>>
>>> Also, default is now to not generate data stack checks for underflow and
>>> overflow (to generate them, use --C command line parameter).
>>>
>>> For instance, with this version, the binarytree benchmark results are
>>> (on a Core i7-4720HQ 2,60GHz running on Windows 10) :
>>>
>>> With 1 core used : about 18,5 seconds elapsed :
>>>
>>> oforth --P"#[ 20 binarytree ] bench" --W1 examples/binarytree.of
>>> stretch tree of depth 21         check: -1
>>> 2097152  trees of depth 4        check: -2097152
>>> 524288   trees of depth 6        check: -524288
>>> 131072   trees of depth 8        check: -131072
>>> 32768    trees of depth 10       check: -32768
>>> 8192     trees of depth 12       check: -8192
>>> 2048     trees of depth 14       check: -2048
>>> 512      trees of depth 16       check: -512
>>> 128      trees of depth 18       check: -128
>>> 32       trees of depth 20       check: -32
>>> long lived tree of depth 20      check: -1
>>> 18410821
>>>
>>>
>>> With 4 cores used : about 6,5 seconds elapsed :
>>>
>>> oforth --P"#[ 20 binarytree ] bench" --W4 examples/binarytree.of
>>> stretch tree of depth 21         check: -1
>>> 2097152  trees of depth 4        check: -2097152
>>> 524288   trees of depth 6        check: -524288
>>> 131072   trees of depth 8        check: -131072
>>> 32768    trees of depth 10       check: -32768
>>> 8192     trees of depth 12       check: -8192
>>> 2048     trees of depth 14       check: -2048
>>> 512      trees of depth 16       check: -512
>>> 128      trees of depth 18       check: -128
>>> 32       trees of depth 20       check: -32
>>> long lived tree of depth 20      check: -1
>>> 6376182
>>>
>>> Franck
>>> http://www.oforth.com
>>>
>>
>> Thanks for making the software available, but is there any chance the
>> the documentation will be worked on?
>>
>> It hard to deal with a Forth that is different, but at the same time not
>> documented well.
>>
>> --
>> Cecil - k5nwa
>
> Hello,
>
> You are right. And I agree that this is very important.
>
> Currently, I'am focused on Oforth V1.0 version (and its documentation)
> but I will release the doc first.
>
> Did you run all the tutorials ?
>
> Franck
>
I understand, V1.0 is an important milestone that you are working hard 
to accomplish so I'm being patient and waiting.

I did not go through quite all the tutorials, after a little bit I tried 
to make a simple tutorial of my own to test some concepts in simple 
string and list conversions and didn't get anywhere as some of the words 
I "think" I would need were not documented so the only choice I had was 
to pour through the source code to figure it all out, and since the 
software right now is in the state of flux I figure if I had to go 
through that effort I will wait a while until things settle down.  I'm 
thinking that V1.0 will bring additional changes ,so now it's better to 
wait a bit and see what happens.

In the meantime, I keep looking for something that will accomplish what 
I'm looking for, so far two pieces of software look promising ( Timbre, 
and 8th ) but I have my own long term objections to both of them.

With Timbre is the lack of decent documentation, and I have known about 
it for years with no change to the documentation so waiting any further 
is a lost cause, a shame since it's pretty close to what I want.

8th looks like it's totally capable of doing what I want so I can create 
my own application, it is well documented, and has great support for 
multiple OSes but it's a software rental item, $100 a year to keep it 
functional for non-commercial use. I could live with a software 
maintenance fee to keep the software updated but they have it so the 
software becomes crippled if you don't pay every 6 months, that is hard 
to swallow. It's their software so they can do as they want, but it's my 
money and I can do as I want.

I'm totally against renting software on general principles, it would 
encourage others to do the same. Divx was in a similar position, it 
wanted to push the idea that one doesn't own a movie but rents it for x 
number of viewings then you have to buy it again, I prayed that the 
concept would die before others started doing the same, and happily that 
concept is no longer with us.

I have tried several offshoots of Forth so that things are getting a 
little mixed up as to what software has what features. So maybe I need 
to repeat the process, and document the findings so I don't forget where 
all the various versions of Forth stand. One thing I do want to have are 
mutable list items, which from reading Oforth does not have that but I 
could be mistaken so I will wait until the new version comes out.


-- 
Cecil - k5nwa

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

#49397

Le dimanche 24 juillet 2016 19:44:32 UTC+2, Cecil - k5nwa a écrit :
> On 7/24/2016 5:25 AM, franck.bensusan@gmail.com wrote:
> I understand, V1.0 is an important milestone that you are working hard 
> to accomplish so I'm being patient and waiting.
> 
> I did not go through quite all the tutorials, after a little bit I tried 
> to make a simple tutorial of my own to test some concepts in simple 
> string and list conversions and didn't get anywhere as some of the words 
> I "think" I would need were not documented so the only choice I had was 
> to pour through the source code to figure it all out, and since the 
> software right now is in the state of flux I figure if I had to go 
> through that effort I will wait a while until things settle down.  I'm 
> thinking that V1.0 will bring additional changes ,so now it's better to 
> wait a bit and see what happens.
> 
> In the meantime, I keep looking for something that will accomplish what 
> I'm looking for, so far two pieces of software look promising ( Timbre, 
> and 8th ) but I have my own long term objections to both of them.
> 
> With Timbre is the lack of decent documentation, and I have known about 
> it for years with no change to the documentation so waiting any further 
> is a lost cause, a shame since it's pretty close to what I want.
> 
> 8th looks like it's totally capable of doing what I want so I can create 
> my own application, it is well documented, and has great support for 
> multiple OSes but it's a software rental item, $100 a year to keep it 
> functional for non-commercial use. I could live with a software 
> maintenance fee to keep the software updated but they have it so the 
> software becomes crippled if you don't pay every 6 months, that is hard 
> to swallow. It's their software so they can do as they want, but it's my 
> money and I can do as I want.
> 
> I'm totally against renting software on general principles, it would 
> encourage others to do the same. Divx was in a similar position, it 
> wanted to push the idea that one doesn't own a movie but rents it for x 
> number of viewings then you have to buy it again, I prayed that the 
> concept would die before others started doing the same, and happily that 
> concept is no longer with us.
> 
> I have tried several offshoots of Forth so that things are getting a 
> little mixed up as to what software has what features. So maybe I need 
> to repeat the process, and document the findings so I don't forget where 
> all the various versions of Forth stand. One thing I do want to have are 
> mutable list items, which from reading Oforth does not have that but I 
> could be mistaken so I will wait until the new version comes out.
> 
> 
> -- 
> Cecil - k5nwa

Even if immutability is a key concept in Oforth, mutable list exist
(and are sometimes more suitable than immutable objects).

They are instances of ListBuffer class.
(and mutable strings are instances of StringBuffer).

You can find a reference of all words defined at startup 
(including ListBuffer methods) here : http://www.oforth.com/lang.html

I doubt that those words will change a lot with V1.0

Basically, you can create a new list using : 
ListBuffer new
or
n ListBuffer newSize

If you know what will be the list size, it is better to use #newSize to
avoid the list to be resized for nothing.

Then you can add new elements using #add method : 
aListBuffer add ( x -- )

or update elements using #put :
aListBuffer put ( i y -- )
 
The list will automatically be resized if necessary. 


For instance, this is how #zipWith is implemented, using a ListBuffer : 

Indexable method: zipWith( coll r -- aList )
| i |
   self size coll size min dup ListBuffer newSize swap 
   loop: i [ i coll at  i self at  r perform over add ]
   dup freeze ;

[ 1 , 2 , 3 ] #[ + 1+ ] [ 4 , 5 , 6 ] zipWith .
[6, 8, 10] ok


Franck

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

#49401

On 7/24/2016 2:42 PM, franck.bensusan@gmail.com wrote:
> Le dimanche 24 juillet 2016 19:44:32 UTC+2, Cecil - k5nwa a écrit :

>> I did not go through quite all the tutorials, after a little bit I tried
>> to make a simple tutorial of my own to test some concepts in simple
>> string and list conversions and didn't get anywhere as some of the words
>> I "think" I would need were not documented so the only choice I had was
>> to pour through the source code to figure it all out, and since the
>> software right now is in the state of flux I figure if I had to go
>> through that effort I will wait a while until things settle down.  I'm
>> thinking that V1.0 will bring additional changes ,so now it's better to
>> wait a bit and see what happens.
>>

>>
>> I have tried several offshoots of Forth so that things are getting a
>> little mixed up as to what software has what features. So maybe I need
>> to repeat the process, and document the findings so I don't forget where
>> all the various versions of Forth stand. One thing I do want to have are
>> mutable list items, which from reading Oforth does not have that but I
>> could be mistaken so I will wait until the new version comes out.
>>
>>
>> --
>> Cecil - k5nwa
>
> Even if immutability is a key concept in Oforth, mutable list exist
> (and are sometimes more suitable than immutable objects).

Good to hear, I vaguely remembered that there was a way to get list of 
items and be mutable, so maybe my documenting this information is needed 
to avoid getting the different Forth systems that I been looking at 
mixed up.
>
> They are instances of ListBuffer class.
> (and mutable strings are instances of StringBuffer).
>
> You can find a reference of all words defined at startup
> (including ListBuffer methods) here : http://www.oforth.com/lang.html
>
Unfortunately for me, that list rarely list what the expected parameters 
are. Also some basic items are not defined, for example what is a 
"receiver" in some cases I gather that it is the top of the stack, but 
in some items I'm not sure.

> I doubt that those words will change a lot with V1.0
>
> Basically, you can create a new list using :
> ListBuffer new
> or
> n ListBuffer newSize
>
> If you know what will be the list size, it is better to use #newSize to
> avoid the list to be resized for nothing.
>
> Then you can add new elements using #add method :
> aListBuffer add ( x -- )
>
> or update elements using #put :
> aListBuffer put ( i y -- )

I will not know how big a list is until the code is actually reading the 
input text, so I planned to declare the "ListBuffer" at a reasonable 
size and then grow as needed, in most cases it will not need to grow. 
The one ListBuffer will keep getting reused so as it grows the chances 
of it needing to grow will diminish.

My plan is to parse a set of code into the list, then proceed to process 
it looking for patterns and doing substitution of the text. If 
processing Forth as an example, I would load an entire word definition 
into the list array and process it as a whole entity, it may not be the 
best way but it's a way I have done before and worked well.

The goal would be to use templates to optimize the word definition and 
then generate optimized assembler code to be compiled as the final result.

In the past I used a similar method to translate languages, and to 
optimize the Forth code and generate code for various CPU chips. The 
process would first optimize the forth code to an internal form using 
special optimized micro ( quarks ) primitives that translate well to 
assembler then those optimized primitives would be translated to 
assembler code for the specific CPU. Not only did it generate decent 
code but I was able to easily modify it to work with several CPUs. The 
thing is one can start simple with few templates but as one adds more 
templates the code generated keeps improving.

>
> The list will automatically be resized if necessary.
>
>
> For instance, this is how #zipWith is implemented, using a ListBuffer :
>
> Indexable method: zipWith( coll r -- aList )
> | i |
>    self size coll size min dup ListBuffer newSize swap
>    loop: i [ i coll at  i self at  r perform over add ]
>    dup freeze ;
>
> [ 1 , 2 , 3 ] #[ + 1+ ] [ 4 , 5 , 6 ] zipWith .
> [6, 8, 10] ok
>
>
> Franck
>


-- 
Cecil - k5nwa

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

#49501

Le dimanche 24 juillet 2016 22:43:06 UTC+2, Cecil - k5nwa a écrit :
> Unfortunately for me, that list rarely list what the expected parameters 
> are. Also some basic items are not defined, for example what is a 
> "receiver" in some cases I gather that it is the top of the stack, but 
> in some items I'm not sure.
> 

The receiver is a concept used with OOP.

It is the "this" of some languages (C++, java, ...) or the
"self" of others (Smalltalk, Oforth, ...).

In Oforth, in order to implement OOP metamodel, there are different 
kind of words.

1) Functions are the classical Forth words and they are declared the 
same way. With functions, there is no receiver.

For instance : 

: dist	// ( a b -- f )
   sq swap sq + sqrt ;


2) Methods are words that can have multiple implementations.
The implementation to run is choosen according to the top of the stack
when the method is called.
- This TOS is what is called the receiver.
- When the method is called, the receiver is removed from the stack.
- Into the method body, you can push back the receiver on the stack using "self".

You can think at the receiver as a parameter called "self" that is implicitely
declared on all methods.

If other parameters are needed, they are under the receiver.

For instance, #add is a method.
The signature for ListBuffer implementation is : 
( x aListBuffer -- )
and the listbuffer will be the receiver.

ListBuffer new 10 over add 12 over add . 
[10, 12] ok

You can find more informations into the first tutorial
(chapter X - Methods and polymorphism )

Franck

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

#49428

On 24/07/2016 20:44, Cecil Bayona wrote:

> 8th looks like it's totally capable of doing what I want so I can create
> my own application, it is well documented, and has great support for
> multiple OSes but it's a software rental item, $100 a year to keep it
> functional for non-commercial use. I could live with a software
> maintenance fee to keep the software updated but they have it so the
> software becomes crippled if you don't pay every 6 months

That is factually incorrect, Cecil.

8th's license is only for building binary applications.  If you pay the
license, you can create encrypted binary applications.  If you do not,
you cannot.  THAT is the only difference between paying for a license
and not paying.

Hardly "crippled", IMO.

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

#49434

On 7/24/2016 10:46 PM, Ron Aaron wrote:
>
>
> On 24/07/2016 20:44, Cecil Bayona wrote:
>
>> 8th looks like it's totally capable of doing what I want so I can create
>> my own application, it is well documented, and has great support for
>> multiple OSes but it's a software rental item, $100 a year to keep it
>> functional for non-commercial use. I could live with a software
>> maintenance fee to keep the software updated but they have it so the
>> software becomes crippled if you don't pay every 6 months
>
> That is factually incorrect, Cecil.
>
> 8th's license is only for building binary applications.  If you pay the
> license, you can create encrypted binary applications.  If you do not,
> you cannot.  THAT is the only difference between paying for a license
> and not paying.
>
> Hardly "crippled", IMO.
>
My understanding is that you cannot generate a stand alone application 
once the 6 month license expires encrypted or not, please correct me if 
I am wrong. Without being able to generate a stand alone application 
it's of limited use in my case, as mostly I would occasionally used it 
to write simple tools for the most part.

I would create an small applications once in a blue while, so I might 
have the opportunity to create one small application or two before the 
expiration period times out.

Since I'm retired due to health issues my income is severely restricted, 
$100 might not seem like much but I have little discretionary income, 
actually until the end of the year I have no clue how I will make my 
income meet my expenses due to my Insurance company only paying for my 
medicine for part of the year so starting next week I have to pay for my 
medicines myself.

A shame as I like your software, for simple applications any Forth would 
do if it can generate stand alone code and there are several Forth 
capable of doing that. The main application where your software would 
shine is not so simple so it might take more than 6 month to create it 
and work out the bugs.



-- 
Cecil - k5nwa

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

#49435

On 25/07/2016 07:28, Cecil Bayona wrote:

> My understanding is that you cannot generate a stand alone application
> once the 6 month license expires encrypted or not, please correct me if
> I am wrong. Without being able to generate a stand alone application
> it's of limited use in my case, as mostly I would occasionally used it
> to write simple tools for the most part.

You do understand correctly.  However, you can use 8th in 'script mode',
e.g. invoke '8th your-script.8th' for as long as you want.  It's not a
standalone executable, but for applications you yourself use (or on a
server, etc) it is probably just as useful.

> I would create an small applications once in a blue while, so I might
> have the opportunity to create one small application or two before the
> expiration period times out.

Tell me: would a "reduced version" (e.g. without the ability to create
encrypted binaries, perhaps without bluetooth support etc) of 8th be
something that would be attractive (at a one-time purchase, not a
subscription)?  Please contact me (at the email you know) to discuss
further if so.


> A shame as I like your software, for simple applications any Forth would
> do if it can generate stand alone code and there are several Forth
> capable of doing that. The main application where your software would
> shine is not so simple so it might take more than 6 month to create it
> and work out the bugs.

Understood.

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

#49437

Ron Aaron <rambamist@gmail.com> writes:
> Tell me: would a "reduced version"... be attractive (at a one-time
> purchase, not a subscription)?  

I also see the subscription scheme as annoying and think there should be
a one-time price for the current full version, with subscriptions
available for support and updates.  That's how most other software
products work, including the main commercial Forths if I understand
correctly.  Even if you have to raise prices to make up for lost
subscription revenue, a one-time price will likely lead to less customer
dissatisfaction.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web