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

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

Adding thousands separators

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

Contents

  Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-13 21:24 +1100
    Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-02-13 13:05 -0800
      Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-16 10:19 +1100
    Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-02-15 08:48 +0100
      Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-02-23 22:46 -0800
        Re: Adding thousands separators "A. K." <akk@nospam.org> - 2012-02-24 08:07 +0100
        Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-02-24 15:00 +0100
          Re: Adding thousands separators "Elizabeth D. Rather" <erather@forth.com> - 2012-02-24 08:29 -1000
            Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-02-25 00:11 +0100
          Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-02-27 23:28 -0800
            Re: Adding thousands separators Alex McDonald <blog@rivadpm.com> - 2012-02-28 01:37 -0800
              Re: Adding thousands separators Ron Aaron <rambamist@gmail.com> - 2012-02-28 15:06 +0200
            Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-02-29 09:29 +0100
              Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-29 03:00 -0600
                Re: Adding thousands separators The Beez <the.beez.speaks@gmail.com> - 2012-02-29 03:44 -0800
                  Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-29 11:19 -0600
              Re: Adding thousands separators hughaguilar96@yahoo.com - 2012-02-29 22:48 -0800
                Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-03-01 08:38 +0100
                  Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-01 00:57 -0800
                    Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-03-01 18:23 +0100
                    Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-01 17:22 -0800
                      Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-01 18:00 -0800
                        Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-01 22:14 -0800
                          Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-02 06:58 -0800
                            Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-02 11:07 -0800
                              Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-02 13:13 -0600
                              Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-02 11:25 -0800
                                Re: Adding thousands separators Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-03 11:00 +0000
                                  Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-03 03:17 -0800
                                    Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-03 12:30 +0000
                                      Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-03 11:39 -0800
                                      Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-06 16:31 -0800
                                    Re: Adding thousands separators mhx@iae.nl (Marcel Hendrix) - 2012-03-03 15:52 +0200
                                      Re: Adding thousands separators Coos Haak <chforth@hccnet.nl> - 2012-03-03 16:23 +0100
                                      Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-03 10:19 -0800
                                      Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-03 12:35 -0800
                                    Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-03 11:02 -0600
                                      Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-03 17:25 +0000
                                        Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-03 10:14 -0800
                                          Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-03 14:14 -0600
                                            Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-03 14:52 -0800
                                              Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-04 03:39 -0600
                                          Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-04 15:02 +0000
                                        Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-03 14:11 -0600
                                      Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-03 23:49 +0100
                                        Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-03 15:50 -0800
                                        Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-04 15:38 +0000
                                          Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-04 18:08 +0100
                                            Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-04 11:20 -0600
                                            Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-04 17:45 +0000
                                              Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-04 23:50 +0100
                                                Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-05 14:39 +0000
                                          Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-03-06 13:01 -0800
                                            Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-12 16:05 +0000
                                    Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-03 15:45 -0800
                                      Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-03 17:56 -0800
                                        Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-05 15:41 -0800
                                          Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-06 11:27 -0800
                                  Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-03 11:01 -0800
                        Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-02 05:53 -0800
                      Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-03 01:49 +0100
        Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-29 17:20 +1100
          Re: Adding thousands separators "A. K." <akk@nospam.org> - 2012-02-29 07:51 +0100
          Re: Adding thousands separators hughaguilar96@yahoo.com - 2012-02-29 21:26 -0800
            Re: Adding thousands separators "WJ" <w_a_x_man@yahoo.com> - 2012-03-03 03:45 +0000
            Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-04 20:49 +1100
              Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-03-04 15:16 +0100
                Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-06 15:06 +1100
                  Re: Adding thousands separators Hans Bezemer <the.beez.speaks@gmail.com> - 2012-03-06 08:32 +0100
              Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-05 15:06 -0800
                Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-06 15:03 +1100
                Re: Adding thousands separators hwfwguy@gmail.com - 2012-03-06 20:29 -0800
                  Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-06 23:18 -0800
                    Re: Adding thousands separators John Passaniti <john.passaniti@gmail.com> - 2012-03-07 06:07 -0800
                    Re: Adding thousands separators hwfwguy@gmail.com - 2012-03-07 06:36 -0800
                      Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-03-07 16:19 -0800
                        Re: Adding thousands separators Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-08 10:51 +0000
    Re: Adding thousands separators Doug Hoffman <glidedog@gmail.com> - 2012-02-15 20:18 -0500
      Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-17 12:29 +1100
        Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-17 09:42 -0800
          Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-20 15:24 +0000
            Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-20 20:41 -0800
              Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-21 16:46 +0000
                Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-21 12:23 -0600
                  Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-21 11:32 -0800
                    Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-22 12:46 +1100
                      Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-22 10:08 +0000
                        Re: Adding thousands separators "Elizabeth D. Rather" <erather@forth.com> - 2012-02-22 08:51 -1000
                          Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-22 14:28 -0800
                          Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-23 13:13 +0000
                          Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-24 14:32 +1100
                            Re: Adding thousands separators "Elizabeth D. Rather" <erather@forth.com> - 2012-02-23 19:53 -1000
                              Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-03 12:47 +1100
                                Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-03-02 22:26 -0800
                                  Re: Adding thousands separators Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2012-03-03 14:32 +0000
                                  Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-04 21:31 +1100
                                    Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-03-04 10:07 -0800
                                      Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-06 15:31 +1100
                                        Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-03-05 22:26 -0800
                                        Re: Adding thousands separators Josh Grams <josh@qualdan.com> - 2012-03-06 12:32 +0000
                            Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-24 05:04 -0800
                              Re: Adding thousands separators "Elizabeth D. Rather" <erather@forth.com> - 2012-02-24 08:30 -1000
                      Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-22 04:28 -0600
                        Re: Adding thousands separators stephenXXX@mpeforth.com (Stephen Pelc) - 2012-02-22 14:59 +0000
                          Re: Adding thousands separators stephenXXX@mpeforth.com (Stephen Pelc) - 2012-02-22 18:05 +0000
                      Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-22 07:49 -0800
                        Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-02-22 12:46 -0800
                          Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-22 18:24 -0800
                        Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-24 13:23 +1100
                Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-21 11:29 -0800
                  Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-22 09:56 +0000
                    Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-22 07:37 -0800
                      Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-22 10:30 -0600
                      Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-22 16:24 +0000
                      Re: Adding thousands separators Brad <hwfwguy@gmail.com> - 2012-02-23 07:44 -0800
                        Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-02-23 17:54 +0100
                        Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-23 16:51 +0000
                          Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-23 11:49 -0600
                            Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-02-23 13:26 -0800
                              Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-23 15:58 -0600
                            Re: Adding thousands separators Bernd Paysan <bernd.paysan@gmx.de> - 2012-02-26 02:25 +0100
                              Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-26 03:24 -0600
                                Re: Adding thousands separators anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-26 13:40 +0000
                                  Re: Adding thousands separators Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-02-26 11:06 -0600
                    Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-23 15:02 -0800
    Re: Adding thousands separators Doug Hoffman <glidedog@gmail.com> - 2012-02-16 13:21 -0500
    Re: Adding thousands separators Paul Rubin <no.email@nospam.invalid> - 2012-02-16 20:44 -0800
      Re: Adding thousands separators Coos Haak <chforth@hccnet.nl> - 2012-02-17 21:32 +0100
    Re: Adding thousands separators "A. K." <akk@nospam.org> - 2012-02-17 22:41 +0100
      Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-17 18:52 -0800
        Re: Adding thousands separators "A. K." <akk@nospam.org> - 2012-02-18 10:39 +0100
          Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-02-18 21:22 +1100
            Re: Adding thousands separators "A. K." <akk@nospam.org> - 2012-02-18 13:12 +0100
              Re: Adding thousands separators "Peter Knaggs" <pjk@bcs.org.uk> - 2012-02-18 16:30 +0000
                Re: Adding thousands separators Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2012-02-18 17:08 +0000
                Re: Adding thousands separators BruceMcF <agila61@netscape.net> - 2012-02-18 14:46 -0800
              Re: Adding thousands separators "Ed" <nospam@invalid.com> - 2012-03-04 20:47 +1100
    Re: Adding thousands separators Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-02-28 17:03 -0800
    Re: Adding thousands separators "WJ" <w_a_x_man@yahoo.com> - 2012-03-01 18:13 +0000
      Re: Adding thousands separators Alex McDonald <blog@rivadpm.com> - 2012-03-01 12:46 -0800
    Re: Adding thousands separators "WJ" <w_a_x_man@yahoo.com> - 2012-03-01 18:52 +0000

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

#9822

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> It's not difficult to scan the return stack in any Forth that I'm
> aware of.  It's hard to do it in standard Forth, but that's not likely
> to matter to anyone who needs it in some application.

I thought it was pretty common in Forth programs to put temporary values
on the return stack.  In C, there's a common trick of protecting local
variables from GC by connecting them up to a GC root through the call
stack, but that sounds like a pain in Forth because of the difficulty of
reaching past the first one or two data stack levels (remember you can't
use locals for this either).

>> I remember seeing a mini-Scheme interpreter written in Forth,.. and
>> deciding that the way it was written, fixing that problem by plugging
>> your GC into it would have been difficult.
>
> Really?  I'm surprised.  A conservative GC should Just Work, as long
> as it can find all the roots and you don't care about a few memory
> leaks due to false positives.

Well, I saw that it used the return stack to hold some values, but maybe
it's still manageable.  The author is at the same university as Anton,
so maybe they know each other:

http://www.complang.tuwien.ac.at/~schani/oldstuff/scheme_in_forth.tar.gz

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

#9829

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> It's not difficult to scan the return stack in any Forth that I'm
>> aware of.  It's hard to do it in standard Forth, but that's not likely
>> to matter to anyone who needs it in some application.
> 
> I thought it was pretty common in Forth programs to put temporary
> values on the return stack.  In C, there's a common trick of
> protecting local variables from GC by connecting them up to a GC
> root through the call stack, but that sounds like a pain in Forth
> because of the difficulty of reaching past the first one or two data
> stack levels (remember you can't use locals for this either).

I tend to asume that the GC runs in a GC thread: the stacks of all the
other threads are just data.

Andrew.

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

#9836

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> http://www.complang.tuwien.ac.at/forth/garbage-collection.zip
>
>I remember looking at that and thinking it was really cool, but that its
>limitation of not being able to scan the return and locals stacks made
>it difficult to use.

That limitation is due to the standard.  For any specific Forth
system, it should be easy to also scan the data on the return stack
and locals (since the collector is conservative, the scanner can be
conservative, too, and you can pass it values that are not necessarily
on any stack.

E.g., in Gforth you can scan the return stack with:

: mark-rstack ( -- )
  rp0 @ rp@ u+do
    i @ mark
  1 cells +loop ;

The locals stack is similar, except that currently lp0 is not
initialized by the system, but you can set up your own at the start:

lp@ constant lp-bottom
: mark-lstack ( -- )
  lp-bottom lp@ u+do
    i @ mark
  1 cells +loop ;

And you would have to call that in MARK-ALL:

: mark-all ( -- )
    mark-stack mark-others mark-lstack mark-rstack ;

That's all.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2011: http://www.euroforth.org/ef11/

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

#9815

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>True, but there's nothing to stop you from doing GC in a fairly low-
>>level way.  I think it might be very nice fit if done well.  I
>>suppose to do a nice job it'd help to make the virtual machine aware
>>of the GC, but it needn't be necessary.  It depends on just how much
>>of the system you use GC for.
> 
> Hmm, maybe the problem with Forth and libraries is not that they don't
> exist, but that the community ignores them.  GC for Forth has existed
> for at least 12 years.

Oh, of course.  I don't think that the existence of GC of some kind in
Forth is open to question, and I certainly wasn't questioning it.

Andrew.

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

#9821

Andrew Haley wrote:
> When I did Forth full-time (mostly in industrial control
> applications) I was terrified of GC and knew that it wasn't
> appropriate.

As long as you can make the GC a low-priority incremental background 
task, this isn't a problem, rather the contrary.  GC allows you to 
implement memory management with a short (and constant) allocation time, 
something that helps a lot, when your application does dynamic memory 
allocation in the hard realtime path.

Anton's GC is a conservative garbage collector, something that can be 
added as an afterthought.  But IMHO, the best designs are the ones where 
you had made the thought before.  So in a "managed Forth" (where you 
don't have to care about your memory, it is managed for you), there 
would be two sorts of managed objects: on one side, strings and buffers, 
which may resize dynamically, and then may move (the GC there is also a 
compactor), on the other side, OOP objects, which have a static size, 
but do not need to move (there is no sufficient advantage in compacting 
them).

Awareness means that your OOP system knows that OOP objects are garbage 
collected, and whenever you do an assignment of a white object (maybe 
dead) to an object pointer, it "grays" out the assigned object (gray is 
the "alive, but not scanned" color for incremental GCs).  The OOP system 
also can know which variables in an object are actual pointers, reducing 
the false positives (there may still be false positives through other 
possible roots, like stacks), lowering the overall effort.  You can even 
avoid scanning the entire dictionary by requiring that object pointers 
are declared as such (which they usually are) - they then either go to a 
dedicated memory region for quick and easy scanning of roots, or they 
are chain-linked together.

And there are further opportunities.  Objects may have a dedicated life-
time, e.g. a network connection may have an idle timeout.  Instead of 
adding another timeout event queue, you could let the garbage collector 
know that there's a timeout field in the object, and when the timestamp 
there is less than the current time, it has timed out, and doesn't need 
scanning.

There's actually a third class of managed memory, that's the one of 
large data chunks (images, pixel buffers, and alike).  Here, the most 
important thing is that reclaiming this memory also gives it back to the 
OS, which usually requires allocating using mmap and reclaiming using 
munmap (you should also reclaim the unused part of the string memory 
after compaction).  Otherwise you have the JVM situation, where you have 
the combined disadvantage of a non-incremental GC (stopping you here and 
there), and the memory usage of applications grows and grows, and never 
shrinks.

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

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

#9824

Bernd Paysan <bernd.paysan@gmx.de> writes:
> As long as you can make the GC a low-priority incremental background 
> task, this isn't a problem, rather the contrary.  GC allows you to 
> implement memory management with a short (and constant) allocation time, 
> something that helps a lot, when your application does dynamic memory 
> allocation in the hard realtime path.

I know that a lot of papers have been written about GC's like that, but
I don't get the impression they are used very much in practice, maybe
because they add more overhead than other methods.  They also seem in
tension with the concept of a hard realtime system in that they could
conceivably fail to allocate memory (if you're not keeping track of all
the memory yourself, you don't know how much is allocated).  

I looked at a book about SPARK/Ada a while back (a system for writing
high-assurance realtime programs in a subset of Ada), and it IIRC does
not allow dynamic memory allocation at all--you have to use static
buffers for everything.  MISRA C is the same way.  SPARK is designed in
part to guarantee that a given chunk of code cannot throw a runtime
exception under any circumstances.  It's sort of the opposite of
Haskell, which only cares about the results of successful computations,
and treats exceptions as "outside the universe", to be handled elsewhere
if they occur.

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

#9838

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton's GC is a conservative garbage collector, something that can be 
>added as an afterthought.  But IMHO, the best designs are the ones where 
>you had made the thought before.

Precise garbage collectors have some advantages: In particular, they
can move the live data around, which allows very fast (ALLOT-like)
allocation.

But they also have a significant cost: They require the ability to
determine precisely which data is a pointer and which isn't (whereas a
conservative collector can assume that everything is a pointer).  If
you have tagged data, that's no problem.

If you don't, it means you pay for the precision advantage with the
cost of added tags.  That choice was taken by Ocaml last time I looked
at the code (the language is statically typed and does not need data
tags in its implementation for any other reason, and the Ocaml
implementor confirmed that the tags are there for GC).

Or one might think that one can somehow get all the static type
knowledge from the compiler into the run-time system such that the GC
can use that knowledge determine precisely whether something is a
pointer or not, but that's complex and affects a very large part of
the compiler; e.g., you change something in the register allocation?
Since the register might contain a pointer, you may have to change
what is communicated to the run-time system.  I have heard/read about
several projects that wanted to go that way, but after a few years
still were not there, so they were still using Boehm's collector
(which is a good one, and you can use it with Forth, too).  Overall,
this kind of thing is what some call "heroic effort", Forthers tend to
call it "needless complexity", though.

Given that we have no type knowledge in the compiler nor in the
run-time system in Forth, a conservative GC is the way to go.

>There's actually a third class of managed memory, that's the one of 
>large data chunks (images, pixel buffers, and alike).  Here, the most 
>important thing is that reclaiming this memory also gives it back to the 
>OS, which usually requires allocating using mmap and reclaiming using 
>munmap (you should also reclaim the unused part of the string memory 
>after compaction).

Two other things are special for this kind of data:

1) You don't need to scan it.

2) You don't want to copy it on every collection.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2011: http://www.euroforth.org/ef11/

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

#9843

Anton Ertl wrote:
> Given that we have no type knowledge in the compiler nor in the
> run-time system in Forth, a conservative GC is the way to go.

Well, my idea was that you put the GC into an object oriented system 
added on top of Forth. This system can have this knowledge, and 
therefore can benefit of this.  With a vtable approach, every managed 
data type is tagged (the vtable pointer is the tag), anyways.

In such a system, I would go for a separate object pointer stack (the 
TOS is the "current object"), and declare that object pointers anywhere 
else do not constitute roots - so if you use them, make sure there is 
already a root for it.

That way, you get the benefit of GC only for a certain style of 
programming - using that OOP system.

>>There's actually a third class of managed memory, that's the one of
>>large data chunks (images, pixel buffers, and alike).  Here, the most
>>important thing is that reclaiming this memory also gives it back to
>>the OS, which usually requires allocating using mmap and reclaiming
>>using munmap (you should also reclaim the unused part of the string
>>memory after compaction).
> 
> Two other things are special for this kind of data:
> 
> 1) You don't need to scan it.
> 
> 2) You don't want to copy it on every collection.

Ah, yes.  And you very likely have a handler object which knows how to 
deal with that data and can release it when the handler object is 
collected.

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

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

#9844

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Anton Ertl wrote:
>> Given that we have no type knowledge in the compiler nor in the
>> run-time system in Forth, a conservative GC is the way to go.
> 
> Well, my idea was that you put the GC into an object oriented system 
> added on top of Forth. This system can have this knowledge, and 
> therefore can benefit of this.  With a vtable approach, every managed 
> data type is tagged (the vtable pointer is the tag), anyways.
> 
> In such a system, I would go for a separate object pointer stack (the 
> TOS is the "current object"), and declare that object pointers anywhere 
> else do not constitute roots - so if you use them, make sure there is 
> already a root for it.
> 
> That way, you get the benefit of GC only for a certain style of 
> programming - using that OOP system.

It's an idea.  You could use a conservative GC for everything else.

Andrew.

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

#9846

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Given that we have no type knowledge in the compiler nor in the
>> run-time system in Forth, a conservative GC is the way to go.
>
>Well, my idea was that you put the GC into an object oriented system 
>added on top of Forth. This system can have this knowledge, and 
>therefore can benefit of this.  With a vtable approach, every managed 
>data type is tagged (the vtable pointer is the tag), anyways.
>
>In such a system, I would go for a separate object pointer stack (the 
>TOS is the "current object"), and declare that object pointers anywhere 
>else do not constitute roots - so if you use them, make sure there is 
>already a root for it.
>
>That way, you get the benefit of GC only for a certain style of 
>programming - using that OOP system.

This is a kind of two-worlds approach, where Forth code deals with
Forth data and OO code deals with objects, and you cannot use things
from one world in the other one.  From reading about them, Objective-C
and Neon took such an approach.

I prefer more integrated approaches, where an object address is just a
cell in Forth, and there is no conceptual difference between Forth
code and object-oriented code (you may have Forth code that does not
use OO, however, but if it does, it's still Forth code).

Anyway, this is a good example of the kind of costs that you have to
pay if you want precise GC.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2011: http://www.euroforth.org/ef11/

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

#9853

Anton Ertl wrote:
> I prefer more integrated approaches, where an object address is just a
> cell in Forth, and there is no conceptual difference between Forth
> code and object-oriented code (you may have Forth code that does not
> use OO, however, but if it does, it's still Forth code).

Well, the Forth code that does use OO should have no problems with the 
limits of the precise garbage collector: It will use the necessary 
features of the OO package.

> Anyway, this is a good example of the kind of costs that you have to
> pay if you want precise GC.

The point here is more: In the traditional Forth world, your program 
manages memory explicitely, it allocates and frees as necessary.  In the 
OO world, this is too cumbersome (or whatever), and you don't want it 
there.  You pay a price for doing so - you must be disciplined about how 
you treat your object addresses (you can only store it in cells that are 
specified to contain addresses, i.e. in object pointers, or, for 
strings, in string pointers).  It's not very inconvenient to say

String foo

instead of

Variable foo

and later using $! to store a string in foo.  Hm, wait: The way $! is 
implemented in bigForth (with it's compacting collector for strings), 
you don't even need to say String foo, it works with Variable foo, as 
well.  And it's still precise and incremental garbage collection.

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

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

#9862

Bernd Paysan <bernd.paysan@gmx.de> writes:
>The point here is more: In the traditional Forth world, your program 
>manages memory explicitely, it allocates and frees as necessary.  In the 
>OO world, this is too cumbersome (or whatever), and you don't want it 
>there.

In the Forth world, explicit freeing is too cumbersome, too, and you
don't want it there, either.  And actually traditional Forth has not
done any freeing, but relied on pre-allocation with limits (some would
say static allocation, but I consider that a questionable concept in a
language that does not have a single compile-time/run-time boundary.

And some OO people did not consider explicit deallocation too
cumbersome; it certainly the only thing that C++ has offered for a
long time (supposedly the new standard will support GC).

>You pay a price for doing so - you must be disciplined about how 
>you treat your object addresses (you can only store it in cells that are 
>specified to contain addresses, i.e. in object pointers, or, for 
>strings, in string pointers).

I have always made mistakes with cross.fs' A! etc.  I just don't think
that way when programming in something that looks like Forth.

Anyway, my point is that IMO the benefits of precise GC are not big enough
to justify the cost.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2011: http://www.euroforth.org/ef11/

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

#9894

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Precise garbage collectors have some advantages: In particular, they
> can move the live data around, which allows very fast (ALLOT-like)
> allocation.

In semispace GC's, freeing is also much faster since the collector only
has to touch the live data and not the garbage.  And there's the
benefits of compaction on cache locality, and the ability to use
generational GC to keep latency low most of the time, etc.

> If you don't [have tagged data], it means you pay for the precision
> advantage with the cost of added tags.  That choice was taken by Ocaml
> last time I looked at the code (the language is statically typed and
> does not need data tags in its implementation for any other reason,
> and the Ocaml implementor confirmed that the tags are there for GC).

I'm not familiar with the Ocaml implementation but the usual reason for
tags in statically typed FPL's is to implement polymorphism without
having to specialize all polymorphic functions to every possible type
signature used at any call site (C++ templates can lead to exponential
code bloat because of this specialization).  I can see how the tags
would also make GC simpler.

> the compiler; e.g., you change something in the register allocation?
> Since the register might contain a pointer, you may have to change
> what is communicated to the run-time system.  

I'll try to find out more about how GHC handles this, but I think the GC
(and the task switcher) can only run at specific points in the program
and the compiler just makes sure the data in the registers is in an
udnerstandable state at those points.

> Given that we have no type knowledge in the compiler nor in the
> run-time system in Forth, a conservative GC is the way to go.

Yes, there doesn't seem to be any alternative in Forth or C/C++ given
the possibility of pointers in the middle of untyped data.  It's pretty
impressive that GC in Forth can exist at all though, so I'm not
complaining about the Boehm algorithm in that context.

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

#10050

Paul Rubin <no.email@nospam.invalid> writes:
>> If you don't [have tagged data], it means you pay for the precision
>> advantage with the cost of added tags.  That choice was taken by Ocaml
>> last time I looked at the code (the language is statically typed and
>> does not need data tags in its implementation for any other reason,
>> and the Ocaml implementor confirmed that the tags are there for GC).
>
>I'm not familiar with the Ocaml implementation but the usual reason for
>tags in statically typed FPL's is to implement polymorphism without
>having to specialize all polymorphic functions to every possible type
>signature used at any call site

That's not the reason for Ocaml.  There the tags only differentiate
between plain integers and pointers.  As for genericity, AFAIK Ocaml
(used to) support that without code duplication by boxing more or less
everything (which is the usual approach).

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2011: http://www.euroforth.org/ef11/

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

#9823

On Mar 3, 4:17 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>
> > I don't agree. With 4Gbyte of internal memory in my Forth, a large
> > class of problems can be solved with closures, that ly around
> > indefinitely. Don't even try to collect them manually.
>
> 1) I think the typical system where Forth is used has nowhere near 4G of
> memory.
>
> 2) If you program in a style that uses closures a lot, burning through
> 4G won't take very long anyway.
>
> > Me too. I hope he leaves the garbage collection out, as that diminishes
> > the chance we'll ever see something from it.
>
> GC isn't that hard to implement, but I think it's not in the Forth
> spirit to rely on it heavily.  Forth as I see it is about very manual
> control of almost everything, stingy use of memory, and deterministic
> scheduling suitable for hard-real-time applications.
>
> I'd say if you want a language with closures and GC, you actually want
> Lisp rather than Forth, so it's better to just implement Lisp directly.

Don't worry --- I have no intention of implementing GC. I think Lisp
and Scheme are wonderful languages --- for the desktop! I also think
that Factor and various other languages are great. There is a guy over
on comp.lang.asm.x86 who is writing his own language which I was very
impressed with, and he taught me a lot about GC. As fascinating as all
of this is, it has nothing to do with Forth though --- Forth is for
micro-controllers such as the PIC24 and MSP430 that have maybe 16K of
data memory, which run in real-time, which run indefinitely, and which
have to be totally reliable/deterministic.

I did figure out a way to provide run-time bug-catching. If a closure
gets executed after its parent has gone out of scope, the closure will
be able to gracefully abort with a helpful error message --- I won't
just run the closure accessing the garbage data on the return stack
belonging to some unrelated function.

I wouldn't mind being the "bonehead" who writes the software for a
toilet flusher --- if I'm getting paid. Desktop software is fun, but
it is just a hobby. Essentially *all* desktop software is given away
for free, including the OS. The days of writing a word-processor (such
as WordStar) and selling it in a shrink-wrapped box are long gone.
CompUSA is kaput. The only shrink-wrapped software still being sold
(at WalMart) are games --- but I have no interest in writing games
(the only game I play is internet Go --- I'm "Classic" on KGS).

If you want to make money, you have to forget about all of this high-
level stuff. Competing against Python is not a good idea. Stick with
micro-controllers --- that is the only field in which it is possible
to make money --- and the only field in which the reigning language
(C) is bad enough (no closures) that Straight Forth would be
considered an improvement.

One of the many reasons why I have abandoned Forth-200x is that
Forth-200x tries to be everything to everybody. I already made this
point in regard to the conflicting features of ANS-Forth that were
introduced to please various Forth vendors, despite the fact that they
don't work together. The same point can be made in regard to trying to
please various Forth programmers who are interested in such disparate
applications as desktop-scripting and robotics. I'm not going to make
this mistake with Straight Forth. I am just aiming entirely at micro-
controllers. If people complain that Straight Forth isn't any good for
desktop software, I will just give them links to websites supporting
appropriate languages and tell them: "Good luck and goodbye." I will
have a version of Forth that runs on the desktop computer, but the
only application that it will be used for will be the cross-compiler
--- it will be fairly simple, and totally oriented toward that one
application. I may have a "sister language" (most likely Racket) that
I will encourage desktop software to be written in, as there may be
software related to micro-controllers that needs to be run on the
desktop computer (such as my own program for converting dxf files into
gcode which I wrote at Testra in UR/Forth, but which would have been
much easier to do in Lisp or almost anything other than Forth).

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

#9826

On Mar 3, 6:45 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> I did figure out a way to provide run-time bug-catching. If a
> closure gets executed after its parent has gone out of scope,
> the closure will be able to gracefully abort with a helpful
> error message --- I won't just run the closure accessing
> the garbage data on the return stack belonging to some
> unrelated function.

Oh well.  Apparently your notion of a closure isn't much more than an
anonymous function, since what most people consider to be closures can
exist beyond the parent that created them.  What you seem to be
describing sounds more like a quotation that can only be used in-
place, not passed arbitrarily around to other code.  Useful, but not
as useful as what most people consider closures to be.

> If you want to make money, you have to forget about all of
> this high-level stuff. Competing against Python is not a
> good idea. Stick with micro-controllers --- that is the
> only field in which it is possible to make money --- and
> the only field in which the reigning language (C) is bad
> enough (no closures) that Straight Forth would be
> considered an improvement.

You might be right regarding desktop applications, but increasingly,
desktop applications are being replaced with web-based applications
and mobile applications.  The folks I know who work at Google and
Facebook and LinkedIn and Orbitz and Amazon seem to be doing very
well.

I'm still looking forward to a deeper discussion from you about what
exactly you mean by closures.  Because what you've described doesn't
sound like it provides much more than what you would get by (in C)
setting a function pointer to a function and passing that.  Could you
provide an example of what the code that uses such a closure would
look like?

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

#9868

On Mar 3, 6:56 pm, John Passaniti <john.passan...@gmail.com> wrote:
> On Mar 3, 6:45 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>
> > I did figure out a way to provide run-time bug-catching. If a
> > closure gets executed after its parent has gone out of scope,
> > the closure will be able to gracefully abort with a helpful
> > error message --- I won't just run the closure accessing
> > the garbage data on the return stack belonging to some
> > unrelated function.
>
> Oh well.  Apparently your notion of a closure isn't much more than an
> anonymous function, since what most people consider to be closures can
> exist beyond the parent that created them.  What you seem to be
> describing sounds more like a quotation that can only be used in-
> place, not passed arbitrarily around to other code.  Useful, but not
> as useful as what most people consider closures to be.
> ...
> I'm still looking forward to a deeper discussion from you about what
> exactly you mean by closures.  Because what you've described doesn't
> sound like it provides much more than what you would get by (in C)
> setting a function pointer to a function and passing that.  Could you
> provide an example of what the code that uses such a closure would
> look like?

What part of the name "Straight Forth" do you not understand? Leave me
the hell alone, faggot! Are you really so lonely that you want a "deep
discussion" with a known homophobe such as myself??? Go to the truck
stop and fake up a female voice on the CB radio so that guys will talk
to you --- that is what most faggots do when they are lonely.

For the record, yes my closures do have access to the parent
function's local variables --- that is why running them after the
parent function has exited results in a program abort with an error
message --- because those local variables don't exist anymore and the
display-pointer is left pointing into the middle of the return-stack
segment at who-knows-what.

It is possible to put the parent's local variables on the heap rather
than on the return stack, and to keep them around after the parent
function has exited. GC is needed to get rid of them eventually. I
don't support any such thing --- it is not Forthish --- people can
program in a desktop-computer scripting language if they want that
kind of thing.

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

#9892

On Mar 5, 6:41 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> What part of the name "Straight Forth" do you not understand?

I'm not sure what is so hard to understand about the name.  You chose
it as part of a continued smokescreen against your own failings and
insecurities.  I don't think anyone who has witnessed your various
tantrums in comp.lang.forth sees it as anything less.

> Leave me the hell alone, faggot! Are you really so lonely that
> you want a "deep discussion" with a known homophobe such as
> myself???

I don't have to like you as a person to ask questions about your
Forth.  Despite your many personality flaws and bizarre perspective,
we agree on some things.  As a fan of Forth and a programming
languages geek, I'm interested in what you can bring to the table.  I
don't have to respect you in order to find value in your work.

> For the record, yes my closures do have access to the
> parent function's local variables --- that is why
> running them after the parent function has exited
> results in a program abort with an error message ---
> because those local variables don't exist anymore and
> the display-pointer is left pointing into the middle
> of the return-stack segment at who-knows-what.

While you are free to call such as mechanism anything you like,
calling it a "closure" will inevitably cause confusion.  Not that
Wikipedia is necessarily authoritative, but the definition they
provide is pretty common:

http://en.wikipedia.org/wiki/Closure_(computer_science)

You might consider a better name for the feature.  What you are
providing seems more like a quotation with the added ability to
reference locals in the parent.  That's potentially useful, but it's
not a closure.

> It is possible to put the parent's local variables on the
> heap rather than on the return stack, and to keep them
> around after the parent function has exited. GC is needed
> to get rid of them eventually.

Or manual reclamation. Painful and annoying, but possible.

> I don't support any such thing --- it is not Forthish
> --- people can program in a desktop-computer scripting
> language if they want that kind of thing.

Yes, if you are specifically targeting smaller embedded systems, that
might be an acceptable trade-off.  It should be pointed out that these
days embedded systems are getting larger and some of the techniques
used on desktop and server systems are finding their place there.  And
even when that wasn't the case, most non-trivial embedded systems
often have different performance domains.  In the products I design, a
single system will have low-level, high-speed, hard real-time
requirements for some parts (like digital signal processing) *and* it
will have high-level, low-speed, aspects (like the user interface).

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

#9812

On Mar 3, 6:00 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> I don't agree. With 4Gbyte of internal memory in my Forth,
> a large class of problems can be solved with closures,
> that ly around indefinitely. Don't even try to collect
> them manually.

Well, yeah, if you have those kinds of resources in a system, and/or
the software isn't intended to be a long-running process.  That's not
the kind of systems I target, and I suspect the same is true of many
others in this newsgroup.

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

#9782

On Mar 1, 9:00 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> John Passaniti <john.passan...@gmail.com> writes:
> > I'd really enjoy hearing how you define object-oriented because
> > it's completely outside any definition I'm aware of.
>
> http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism
>
> has some nice descriptions too ;-).

I'm not sure what your point is.  I'm not promoting or defending OOP.
I'm questioning Hugh's statement about polymorphism in OOP.

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

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

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

csiph-web