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

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

Windows8

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

Contents

  Windows8 visualforth@rocketmail.com - 2012-11-02 08:41 -0700
    Re: Windows8 Brad Eckert <hwfwguy@gmail.com> - 2012-11-02 11:12 -0700
    Re: Windows8 visualforth@rocketmail.com - 2012-11-06 09:05 -0800
      Re: Windows8 Jason Damisch <jasondamisch@yahoo.com> - 2012-11-12 07:10 -0800
        Re: Windows8 stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-12 17:27 +0000
      Re: Windows8 visualforth@rocketmail.com - 2012-11-21 17:48 -0800
    Re: Windows8 visualforth@rocketmail.com - 2012-11-07 20:44 -0800
    Re: Windows8 Jason Damisch <jasondamisch@yahoo.com> - 2012-11-12 07:15 -0800
      Re: Windows8 Brad Eckert <hwfwguy@gmail.com> - 2012-11-12 07:59 -0800
      Re: Windows8 "Elizabeth D. Rather" <erather@forth.com> - 2012-11-12 07:55 -1000
        Re: Windows8 "Ed" <invalid@nospam.com> - 2012-11-14 20:04 +1100
          Re: Windows8 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-14 17:01 +0000
            Re: Windows8 "Ed" <invalid@nospam.com> - 2012-11-18 11:14 +1100
              Re: Windows8 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-19 14:25 +0000
                Re: Windows8 "Elizabeth D. Rather" <erather@forth.com> - 2012-11-19 08:09 -1000
                  Re: Windows8 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-20 09:55 +0000
                    Re: Windows8 mhx@iae.nl (Marcel Hendrix) - 2012-11-25 10:56 +0200
                      Re: Windows8 Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-25 16:46 +0100
              Re: Windows8 Doug Hoffman <glidedog@gmail.com> - 2012-11-19 16:21 -0500
                Re: Windows8 Paul Rubin <no.email@nospam.invalid> - 2012-11-19 13:46 -0800
                  Re: Windows8 Doug Hoffman <glidedog@gmail.com> - 2012-11-19 17:05 -0500
                    Re: Windows8 "Elizabeth D. Rather" <erather@forth.com> - 2012-11-19 12:14 -1000
                      Re: Windows8 Paul Rubin <no.email@nospam.invalid> - 2012-11-19 14:30 -0800
                        Re: Windows8 "Elizabeth D. Rather" <erather@forth.com> - 2012-11-19 12:53 -1000
                      Re: Windows8 Doug Hoffman <glidedog@gmail.com> - 2012-11-19 17:44 -0500
                        Re: Windows8 Paul Rubin <no.email@nospam.invalid> - 2012-11-19 14:52 -0800
                          GC (was Re: Windows8) Doug Hoffman <glidedog@gmail.com> - 2012-11-26 11:44 -0500
                            Re: GC Paul Rubin <no.email@nospam.invalid> - 2012-11-26 11:44 -0800
                              Re: GC Doug Hoffman <glidedog@gmail.com> - 2012-11-28 06:35 -0500
                                Re: GC Paul Rubin <no.email@nospam.invalid> - 2012-11-29 11:58 -0800
                                  Re: GC albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-30 01:46 +0000
                                    Re: GC Paul Rubin <no.email@nospam.invalid> - 2012-11-29 21:14 -0800
                    Re: Windows8 Paul Rubin <no.email@nospam.invalid> - 2012-11-19 14:42 -0800
                      Re: Windows8 Doug Hoffman <glidedog@gmail.com> - 2012-11-19 17:56 -0500
                        Re: Windows8 Paul Rubin <no.email@nospam.invalid> - 2012-11-19 15:14 -0800
                          Re: Windows8 Doug Hoffman <glidedog@gmail.com> - 2012-11-19 18:45 -0500
                            Re: Windows8 "Elizabeth D. Rather" <erather@forth.com> - 2012-11-19 14:18 -1000
                            Re: Windows8 Paul Rubin <no.email@nospam.invalid> - 2012-11-19 16:18 -0800
                          Re: Windows8 Doug Hoffman <glidedog@gmail.com> - 2012-11-19 19:01 -0500
                      Re: Windows8 "Elizabeth D. Rather" <erather@forth.com> - 2012-11-19 12:58 -1000
                      Re: Windows8 Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-20 02:23 +0100
                        Re: Windows8 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-20 10:48 +0000
                          Re: Windows8 Alex McDonald <blog@rivadpm.com> - 2012-11-20 07:56 -0800
                            Re: Windows8 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-21 15:03 +0000
                          Re: Windows8 Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-23 05:58 -0800
                      Re: Windows8 Mark Wills <forthfreak@gmail.com> - 2012-11-20 02:13 -0800
                        Re: Windows8 Paul Rubin <no.email@nospam.invalid> - 2012-11-20 08:57 -0800
                          Re: Windows8 "David N. Williams" <williams@umich.edu> - 2012-11-20 16:56 -0500
                        Re: Windows8 mhx@iae.nl (Marcel Hendrix) - 2012-11-25 11:20 +0200
      Re: Windows8 rickman <gnuarm@gmail.com> - 2012-11-14 16:36 -0500
        Re: Windows8 "Elizabeth D. Rather" <erather@forth.com> - 2012-11-14 12:12 -1000
          Re: Windows8 rickman <gnuarm@gmail.com> - 2012-11-14 17:46 -0500
            Re: Windows8 "Elizabeth D. Rather" <erather@forth.com> - 2012-11-14 13:12 -1000
              Re: Windows8 Paul Rubin <no.email@nospam.invalid> - 2012-11-14 18:12 -0800
              Re: Windows8 rickman <gnuarm@gmail.com> - 2012-11-15 13:55 -0500
                Re: Windows8 RR <freedomspyder@gmail.com> - 2012-11-15 16:03 -0800
                  Re: Windows8 rickman <gnuarm@gmail.com> - 2012-11-15 21:54 -0500
                    Re: Windows8 RR <freedomspyder@gmail.com> - 2012-11-15 19:26 -0800
                    Re: Windows8 Paul Rubin <no.email@nospam.invalid> - 2012-11-15 19:27 -0800
                      Re: Windows8 Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-16 17:45 +0100
                        Re: Windows8 Paul Rubin <no.email@nospam.invalid> - 2012-11-16 09:10 -0800
                          Re: Windows8 Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-16 22:34 +0100
                        Re: Windows8 Andy Valencia <vandys@vsta.org> - 2012-11-16 18:06 +0000
                          Re: Windows8 Paul Rubin <no.email@nospam.invalid> - 2012-11-16 11:09 -0800
                            Re: Windows8 Spam@ControlQ.com - 2012-11-16 15:18 -0500
          Re: Windows8 visualforth@rocketmail.com - 2012-11-15 00:19 -0800
            Re: Windows8 "Elizabeth D. Rather" <erather@forth.com> - 2012-11-14 22:55 -1000
            Re: Windows8 albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-15 12:20 +0000
              Re: Windows8 visualforth@rocketmail.com - 2012-11-15 08:32 -0800
              Re: Windows8 kenney@cix.compulink.co.uk - 2012-11-16 04:51 -0600
                Re: Windows8 stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-16 13:46 +0000
                Re: Windows8 visualforth@rocketmail.com - 2012-11-16 08:12 -0800
    Re: Windows8 the_gavino_himself <visphatesjava@gmail.com> - 2012-11-29 00:16 -0800

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

#17392

On 11/19/12 4:46 PM, Paul Rubin wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>> As others have indicated that would be a failure on the part of the
>> programmer to FREE memory.
>
> Calling it a programmer "failure" is kind of an incomplete description.
> To FREE memory you first have to know that the memory is no longer in
> use, which can require careful bookkeeping in the program if the memory
> is (e.g.) shared between multiple objects.
>
> That bookkeeping is error-prone to start with, and it expands programmer
> effort (i.e. development budget) even when it works.  If you have the
> machine resources to take a moderate efficiency hit in the running
> program, and if you're using dynamic memory in any more than trivial
> way, GC can be quite a big win for programmer productivity.  FREE seems
> to have gone out of style even in C++, which now (C++11) prefers
> reference-counted pointers that are handled sort of invisibly by the
> standard library, for heap-allocated data.

Could you show where in my example that the bookkeeping gets to be error 
prone?  Or would you consider it a trivial example?  If trivial, that 
trviality is sure darn useful.

-Doug

source:  http://soton.mpeforth.com/flag/fms/microFMS.f

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

#17393

On 11/19/12 12:05 PM, Doug Hoffman wrote:
> On 11/19/12 4:46 PM, Paul Rubin wrote:
>> Doug Hoffman <glidedog@gmail.com> writes:
>>> As others have indicated that would be a failure on the part of the
>>> programmer to FREE memory.
>>
>> Calling it a programmer "failure" is kind of an incomplete description.
>> To FREE memory you first have to know that the memory is no longer in
>> use, which can require careful bookkeeping in the program if the memory
>> is (e.g.) shared between multiple objects.
>>
>> That bookkeeping is error-prone to start with, and it expands programmer
>> effort (i.e. development budget) even when it works.  If you have the
>> machine resources to take a moderate efficiency hit in the running
>> program, and if you're using dynamic memory in any more than trivial
>> way, GC can be quite a big win for programmer productivity.  FREE seems
>> to have gone out of style even in C++, which now (C++11) prefers
>> reference-counted pointers that are handled sort of invisibly by the
>> standard library, for heap-allocated data.
>
> Could you show where in my example that the bookkeeping gets to be error
> prone?  Or would you consider it a trivial example?  If trivial, that
> trviality is sure darn useful.

That allocation is used and freed within a limited context. As Paul 
points out, in some programs buffers may be used in multiple places in a 
large program. It requires meticulous program design to FREE such a 
buffer in the right place without conflict among all the uses.

Of course, my argument would be that it is only safe to use an ALLOCATEd 
buffer temporarily and locally, and any memory space that has to be a 
resource in multiple places in a large program should be permanently 
ALLOTted for security.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#17394

"Elizabeth D. Rather" <erather@forth.com> writes:
> Of course, my argument would be that it is only safe to use an
> ALLOCATEd buffer temporarily and locally, and any memory space that
> has to be a resource in multiple places in a large program should be
> permanently ALLOTted for security.

Why would you ALLOT if permanently if you're only going to need it
temporarily?  That's a memory leak.  If you're processing a lot of data,
you'll eventually run out of memory that way.

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

#17398

On 11/19/12 12:30 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> Of course, my argument would be that it is only safe to use an
>> ALLOCATEd buffer temporarily and locally, and any memory space that
>> has to be a resource in multiple places in a large program should be
>> permanently ALLOTted for security.
>
> Why would you ALLOT if permanently if you're only going to need it
> temporarily?  That's a memory leak.  If you're processing a lot of data,
> you'll eventually run out of memory that way.

It really depends on various design issues in the application. But in 
many cases, PAD can be used as a temporary buffer. If this is something 
that's going to happen repeatedly (e.g. every time you process a 
transaction) you can ALLOT appropriate buffers and reuse them for every 
transaction.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#17396

On 11/19/12 5:14 PM, Elizabeth D. Rather wrote:
> On 11/19/12 12:05 PM, Doug Hoffman wrote:
>> On 11/19/12 4:46 PM, Paul Rubin wrote:
>>> Doug Hoffman <glidedog@gmail.com> writes:
>>>> As others have indicated that would be a failure on the part of the
>>>> programmer to FREE memory.
>>>
>>> Calling it a programmer "failure" is kind of an incomplete description.
>>> To FREE memory you first have to know that the memory is no longer in
>>> use, which can require careful bookkeeping in the program if the memory
>>> is (e.g.) shared between multiple objects.
>>>
>>> That bookkeeping is error-prone to start with, and it expands programmer
>>> effort (i.e. development budget) even when it works.  If you have the
>>> machine resources to take a moderate efficiency hit in the running
>>> program, and if you're using dynamic memory in any more than trivial
>>> way, GC can be quite a big win for programmer productivity.  FREE seems
>>> to have gone out of style even in C++, which now (C++11) prefers
>>> reference-counted pointers that are handled sort of invisibly by the
>>> standard library, for heap-allocated data.
>>
>> Could you show where in my example that the bookkeeping gets to be error
>> prone?  Or would you consider it a trivial example?  If trivial, that
>> trviality is sure darn useful.
>
> That allocation is used and freed within a limited context.

Yes.  That's a smart and useful way to use it.

> As Paul
> points out, in some programs buffers may be used in multiple places in a
> large program.

And I would call that living dangerously by choice.  Maybe.  Depends on 
the details which I don't see.

> It requires meticulous program design to FREE such a
> buffer in the right place without conflict among all the uses.

OK.  Maybe.  If one chooses to live dangerously then meticulous care is 
probably then a requirement and is perhaps more prone to error.  Again, 
depends on the specifics which I don't see.  But no where does this 
condemn ALLOCATE RESIZE FREE, IMO.

-Doug

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

#17397

Doug Hoffman <glidedog@gmail.com> writes:
>> As Paul points out, in some programs buffers may be used in multiple
>> places in a large program.
> And I would call that living dangerously by choice.  Maybe.  Depends
> on the details which I don't see.

What alternative are you proposing?  If the data is needed in multiple
places, you either have to share it, or copy it all over the place,
causing program slowdown and memory bloat.  

> If one chooses to live dangerously then meticulous care
> is probably then a requirement and is perhaps more prone to error.

That is also a route not to travel.  If the pattern of allocation is
complicated enough that you start wanting a computer to keep track of
it, then why not do exactly that, and let the computer keep track of it
so you don't have to?  Use the Force, Luke.  The power of garbage
collection is within you. ;-)

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

#17575 — GC (was Re: Windows8)

On 11/19/12 5:52 PM, Paul Rubin wrote:

> If the pattern of allocation is
> complicated enough that you start wanting a computer to keep track of
> it, then why not do exactly that, and let the computer keep track of it
> so you don't have to?  Use the Force, Luke.  The power of garbage
> collection is within you. ;-)

OK.  Believing in giving different approaches a serious try, I have 
spent some time with a (Anton Ertl's) GC package.  First let me 
complement Anton on what appears to be a solid and functional extension. 
  In short I was pleasantly surprised at how well the GC works and have 
softened my personal opinion of the GC approach.  I will consider it for 
future projects.

However, I did experience some "issues".  Granted, these issues surfaced 
when attempting to convert non-trivial previously written code that used 
ALLOCATE RESIZE FREE.  Had the code been written from the start with GC 
in mind I expect it would have been much easier.

The "issues" (these are not bugs, just details that require care when 
converting code to GC):

- I have written Forth object extensions and the usual complaint has 
been they are too large.  So as a follow up I have written a 
"minimalist" objects extension.  It uses ALLOCATE RESIZE FREE for 
dynamic objects and is pretty small (about 30 lins of code).  In order 
to use GC with it one must first load the GC code which is about 5 times 
the size of the objects package.  This doesn't bother me but some might 
not like it.  Perhaps if GC were part of the ANS standard and most 
mainstream Forths had it already loaded in the kernel or whatever this 
would not cause anyone heartache.

- One must manually take care of a "GC resize".  Not a huge deal, but it 
does slow things down.  Not sure how to write dynamically resizable 
entities without a resize function.

- 0 ALLOC will crash if done more than once without resizing ( 0 
ALLOCATE will not).  So one cannot just replace ALLOCATE with ALLOC. 
Probably best to avoid 0 alloc altogether.

- Often, when "cleaning up" data such as when closing a file, at the 
same time one uses FREE one also might be resetting variables to 0 or 
some other initial state.  My code does this a lot.  So eliminating 
"free" type methods or routines must be done with care to make sure that 
one is not also eliminating data state resetting.


Again, none of the above is a condemnation of GC.  But when converting 
to GC it is not a trivial process and quite a bit of care must be taken.

Thanks for the thoughtful explanations.  I will consider GC in future 
projects where I see the need and a good fit.

-Doug

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

#17580 — Re: GC

Doug Hoffman <glidedog@gmail.com> writes:
> I have spent some time with a (Anton Ertl's) GC package...  In short I
> was pleasantly surprised at how well the GC works and have softened my
> personal opinion of the GC approach.  

Oh my, I had forgotten where the documentation for Anton's package was,
so I typed "Ertl garbage collection" into a search engine, and the first
hit led to this:

  http://www.3000toys.com/catalog/item_detail.aspx?itemfind=ERTL39464

> I have written a "minimalist" objects extension.  It ... is pretty
> small (about 30 lins of code).  In order to use GC with it one must
> first load the GC code which is about 5 times the size of the objects
> package.  This doesn't bother me but some might not like it.

I think in small or memory-constrained systems, there are few enough
heap objects that manually managing them isn't so bad; and at the same
time, the GC approach has enough memory cost that you don't want to use
it anyway.  (The memory used by the GC itself is quite small, but
between GC runs there will be piled-up dead objects occupying memory
while they wait for collection).  In larger systems where GC helps more,
150 lines of GC code doesn't seem like a big deal if the programmer
doesn't have to think about it too much after loading it.

> Perhaps if GC were part of the ANS standard and most mainstream Forths
> had it already loaded in the kernel or whatever this would not cause
> anyone heartache.

That would be interesting.  I'm not privacy to the workings of the
standardization committee so I can only guess at the sorts of
conniptions that might greet such a proposal ;-).

> - One must manually take care of a "GC resize".  Not a huge deal, but
> it does slow things down.  Not sure how to write dynamically resizable
> entities without a resize function.

You mean you want something like an extensible array inside an object?
Yeah, if it has to stay contiguous then you have to allocate a new
larger block and copy the data.  Alternatively you could allocate in
segments (or a tree structure) and have your lookup function navigate
appropriately.

> - 0 ALLOC will crash if done more than once without resizing 

That sounds like a bug to me, but I haven't used the package yet.

> - Often, when "cleaning up" data such as when closing a file, at the
> same time one uses FREE one also might be resetting variables to 0 or
> some other initial state. 

Some GC's allow attaching finalization code to objects, that gets called
when the object is collected, but I think that approach wouldn't work
with conservative GC, and for resources like file descriptors is too
leaky even with precise GC.  So yeah, GC helps with memory management
but other sorts of resources still need manual attention ;).

> Thanks for the thoughtful explanations.  I will consider GC in future
> projects where I see the need and a good fit.

Excellent, the next step is to get you using Lisp ;-).

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

#17625 — Re: GC

On 11/26/12 2:44 PM, Paul Rubin wrote:
> Doug Hoffman <glidedog@gmail.com> writes:

>> - One must manually take care of a "GC resize".  Not a huge deal, but
>> it does slow things down.  Not sure how to write dynamically resizable
>> entities without a resize function.
>
> You mean you want something like an extensible array inside an object?

Yes.  Extensible strings as well (an array of chars if you will).


>> - 0 ALLOC will crash if done more than once without resizing
>
> That sounds like a bug to me

I don't think so.  If we are just bumping a pointer then I would expect 
two 0 alloc's to return the same value, which it does.  Actually, with 
the assert level set to 3 (recommended for debugging I think) a 0 alloc 
will not be allowed.

-Doug

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

#17717 — Re: GC

Doug Hoffman <glidedog@gmail.com> writes:
> I don't think so.  If we are just bumping a pointer then I would
> expect two 0 alloc's to return the same value, which it does.

I don't think Anton's GC allocs by bumping a pointer--it's a different
style of GC that does that.  I don't see any obvious problem with
returning the same value for two 0-length allocs.  It could be special
cased (there would only have to be one such object) or it could be
marked and potentially reclaimed like any other GC'd object.

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

#17735 — Re: GC

In article <7x1ufcdvw7.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Doug Hoffman <glidedog@gmail.com> writes:
>> I don't think so.  If we are just bumping a pointer then I would
>> expect two 0 alloc's to return the same value, which it does.
>
>I don't think Anton's GC allocs by bumping a pointer--it's a different
>style of GC that does that.  I don't see any obvious problem with
>returning the same value for two 0-length allocs.  It could be special
>cased (there would only have to be one such object) or it could be
>marked and potentially reclaimed like any other GC'd object.

I see a problem, if both are placeholder for something to REALLOC.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#17746 — Re: GC

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> I see a problem, if both are placeholder for something to REALLOC.

Anton's GC doesn't have REALLOC and I've never heard of a GC that has
it.  You can of course use an extra pointer and a separate block where
the resizeable data is, and Anton's GC document says how to do this.

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

#17395

Doug Hoffman <glidedog@gmail.com> writes:
> Could you show where in my example that the bookkeeping gets to be
> error prone?  Or would you consider it a trivial example?  If trivial,
> that trviality is sure darn useful.

Well, I was speaking generally rather than toward your specific example,
and I don't really understand your example, but I think it involves
dynamically allocating a string buffer so the string can be resized.

Let's say the string is someone's name ("Joe Smith") and Joe is a member
of a club so his name is on the club's membership list, so you have to
keep that string allocated as long as Joe stays a member.  But if his
membership lapses, he is taken off the membership list, so maybe you
want to FREE the memory when that happens.  On the other hand, perhaps
Joe won the Member of the Month award in November 2003, so Joe's name is
also on the "November members of the month" list which is a permanent
list, so in that case you better NOT free the memory just because Joe is
no longer a member.  Start adding some indexed data structures sharing
fields that might or might not contain Joe, structures that are
themselves being created and deleted on the fly, and you can see how the
bookkeeping can get weird.

What you want is an automated way of tracking the references to Joe, so
you can free the memory once it's no longer needed, without having to
manually remember what lists Joe might or might not be on.  This is
basically what GC is.  If you've never used it and you deal with dynamic
data, give it a try; programming becomes ever so much easier.

I think in the embedded realm, it's probably less of an issue, because
there's less dynamic data involved in that sort of code.

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

#17399

On 11/19/12 5:42 PM, Paul Rubin wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>> Could you show where in my example that the bookkeeping gets to be
>> error prone?  Or would you consider it a trivial example?  If trivial,
>> that trviality is sure darn useful.
>
> Well, I was speaking generally rather than toward your specific example,

Apparently.  My example has no leaks.  Period.

> and I don't really understand your example, but I think it involves
> dynamically allocating a string buffer so the string can be resized.

You understand.

> Let's say the string is someone's name ...

Who there.  You are building a house of cards and in a way that I would 
never consider.  When I allocate a dynamic object I make *sure* that the 
overall program *always* has a path to free that object's memory and 
*only* when appropriate.  What you described begs for possibly copying 
the data before freeing the original's memory, which is an entirely safe 
thing to do.

It all may boil down to the complexity one is attempting to use.  For my 
purposes GC has never seemed necessary.

-Doug

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

#17402

Doug Hoffman <glidedog@gmail.com> writes:
>> Well, I was speaking generally rather than toward your specific example,
> Apparently.  My example has no leaks.  Period.

As Elizabeth mentioned, your example (freeing the memory after doing
just a few operations) could have been done with PAD or ALLOT instead of
ALLOCATE.  In a more typical case, when you create a string, it's for
some other part of the program to use, so the place that creates it
doesn't know when it will be freed.

>> Let's say the string is someone's name ...
> What you described begs for possibly copying the data before freeing
> the original's memory, which is an entirely safe thing to do.

That's the old-fashioned C++ approach, and part of the reason people
complain about C++ programs being slow and memory hogs ;-).  You also
need complexity in each of your containers to free the memory of objects
inside the container when the container is freed, etc.  What happened to
factoring?  GC puts all the freeing in one place.

> It all may boil down to the complexity one is attempting to use.  For
> my purposes GC has never seemed necessary.

Even in the cases where you got by without it, maybe it could have saved
you some effort if you had used it.

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

#17404

On 11/19/12 6:14 PM, Paul Rubin wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>>> Well, I was speaking generally rather than toward your specific example,
>> Apparently.  My example has no leaks.  Period.
>
> ... your example (freeing the memory after doing
> just a few operations) could have been done with PAD or ALLOT instead of
> ALLOCATE.

No.  That requires knowing in advance how large the string may grow. 
That string could grow to 1 meg or larger, no problem.  Same code 
snippet style.  PAD won't do.  What size for ALLOT should I select at 
compile time?


>  In a more typical case, when you create a string, it's for
> some other part of the program to use, so the place that creates it
> doesn't know when it will be freed.

Why not?  Either wait until it is copied, written to disk, or the 
program is ended by the user before freeing.



>>> Let's say the string is someone's name ...
>> What you described begs for possibly copying the data before freeing
>> the original's memory, which is an entirely safe thing to do.
>
> That's the old-fashioned C++ approach, and part of the reason people
> complain about C++ programs being slow and memory hogs ;-).

A Forth GC implementation must have a memory and speed hit of its own. 
You're not likely to convince me to use GC because the problems I solve 
don't require it.

Perhaps others who have used Forth and GC could comment on what GC code 
they use and how that has worked out for them.  I've read negative 
comments about that.

-Doug

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

#17409

On 11/19/12 1:45 PM, Doug Hoffman wrote:
> On 11/19/12 6:14 PM, Paul Rubin wrote:
>> Doug Hoffman <glidedog@gmail.com> writes:
>>>> Well, I was speaking generally rather than toward your specific 
>>>> example,
>>> Apparently.  My example has no leaks.  Period.
>>
>> ... your example (freeing the memory after doing
>> just a few operations) could have been done with PAD or ALLOT instead of
>> ALLOCATE.
> 
> No.  That requires knowing in advance how large the string may grow. 
> That string could grow to 1 meg or larger, no problem.  Same code 
> snippet style.  PAD won't do.  What size for ALLOT should I select at 
> compile time?

Depends. How do you find out how long your string is? PAD can be quite
large on some systems, although of course that becomes a dependency
issue. But, then, if you need to process multi-Mb strings you have a
dependency issue anyway.

>>  In a more typical case, when you create a string, it's for
>> some other part of the program to use, so the place that creates it
>> doesn't know when it will be freed.
> 
> Why not?  Either wait until it is copied, written to disk, or the 
> program is ended by the user before freeing.

His point is how does the creation code know the string has been copied,
etc.?

>>>> Let's say the string is someone's name ...
>>> What you described begs for possibly copying the data before freeing
>>> the original's memory, which is an entirely safe thing to do.
>>
>> That's the old-fashioned C++ approach, and part of the reason people
>> complain about C++ programs being slow and memory hogs ;-).
> 
> A Forth GC implementation must have a memory and speed hit of its own. 
> You're not likely to convince me to use GC because the problems I solve 
> don't require it.
> 
> Perhaps others who have used Forth and GC could comment on what GC code 
> they use and how that has worked out for them.  I've read negative 
> comments about that.

Can't help you there, I avoid GC like the plague!

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#17410

Doug Hoffman <glidedog@gmail.com> writes:
> A Forth GC implementation must have a memory and speed hit of its
> own. You're not likely to convince me to use GC because the problems I
> solve don't require it.

The only Forth GC that I know of is Anton's, which is a Boehm-style
conservative collector that scans the entire heap for anything that
might be a pointer, so its speed hit per collection is O(N) in the total
size of the strings.  Its space hit is small, maybe a bit or a cell in
each allocated object regardless of object size (not sure).  Your
copying approach is potentially much worse, like O(N*K) where K is the
number of copies made, and K could potentially itself be O(N), making
the whole thing O(N**2); and it is both a speed hit and a space hit of
that magnitude.  Whether the speed hit is worse depends of course on
collection frequency.

A more advanced GC usually doesn't scan the heap, but instead just
traces the pointers and copies the live data, so it's basically O(M) in
the live data size at each collection, where M is often much smaller
than N.  With this type of GC, allocation is similar to ALLOT (i.e. it
just bumps a pointer) and freeing most objects takes zero time (since
the GC doesn't touch dead objects).  GC is often faster than traditional
allocate/free for that reason.

> Perhaps others who have used Forth and GC could comment on what GC
> code they use and how that has worked out for them.  I've read
> negative comments about that.

I'd be interested in hearing experiences too.  I think GC is not really
a perfect fit for Forth, but it does exist and apparently gets used
sometimes.  I think for the sorts of problems that benefit a lot from
relying heavily on GC, Forth itself may not be that good a fit.  Forth
with GC is sort of an in-between area and I was surprised to find out
about it.

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

#17406

On 11/19/12 6:14 PM, Paul Rubin wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>>> Well, I was speaking generally rather than toward your specific example,
>> Apparently.  My example has no leaks.  Period.
>
> ... your example (freeing the memory after doing
> just a few operations) could have been done with PAD or ALLOT instead of
> ALLOCATE.

Actually there was more freeing and allocating going on because an 
uncased search was implemented where two copies of strings were created 
and converted to all upper case for comparison (not the only way to do 
it, just convenient).  Couldn't re-use PAD for those operations. 
Pre-allotting has the same problems mentioned before.

Not to argue the details of how to best use strings for a specific 
problem, that's not the issue.  The point is highly dynamic routines 
using ALLOCATE RESIZE FREE are not at all difficult to write while 
confidently avoiding memory leaks and other potential dynamic memory 
problems.  I find other aspects of programming to be much more 
challenging than using ALLOCATE RESIZE FREE.

-Doug

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

#17400

On 11/19/12 12:42 PM, Paul Rubin wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>> Could you show where in my example that the bookkeeping gets to be
>> error prone?  Or would you consider it a trivial example?  If trivial,
>> that trviality is sure darn useful.
>
> Well, I was speaking generally rather than toward your specific example,
> and I don't really understand your example, but I think it involves
> dynamically allocating a string buffer so the string can be resized.

That's the kind of situation that PAD is ideal for.

> Let's say the string is someone's name ("Joe Smith") and Joe is a member
> of a club so his name is on the club's membership list, so you have to
> keep that string allocated as long as Joe stays a member.  But if his
> membership lapses, he is taken off the membership list, so maybe you
> want to FREE the memory when that happens.  On the other hand, perhaps
> Joe won the Member of the Month award in November 2003, so Joe's name is
> also on the "November members of the month" list which is a permanent
> list, so in that case you better NOT free the memory just because Joe is
> no longer a member.  Start adding some indexed data structures sharing
> fields that might or might not contain Joe, structures that are
> themselves being created and deleted on the fly, and you can see how the
> bookkeeping can get weird.

That kind of data needs to be stored in a file, surely?

> What you want is an automated way of tracking the references to Joe, so
> you can free the memory once it's no longer needed, without having to
> manually remember what lists Joe might or might not be on.  This is
> basically what GC is.  If you've never used it and you deal with dynamic
> data, give it a try; programming becomes ever so much easier.
>
> I think in the embedded realm, it's probably less of an issue, because
> there's less dynamic data involved in that sort of code.

Well, many instruments are doing repeated data acquisition, but one 
allots permanent buffers for that purpose. The data comes in, it gets 
some preliminary processing in the buffer, and it gets stored on disk or 
flash. Then the buffer gets reused. If it's high-speed data acquisition 
such that you must be acquiring data while older data is being 
processed, you can use a circular buffer list. Lots of strategies, 
depending on the need.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

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

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

csiph-web