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

Groups > comp.lang.forth > #39615

Re: Extendable structure with inspection

Show all headers | View raw

on 07/06/2015 03:35:16,  wrote:
> On Saturday, June 6, 2015 at 9:18:59 AM UTC-7, Anton Ertl wrote:
>> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> >In article <8021c02c-0a0c-42ef-bc8f-1635f64ae841@googlegroups.com>,
>> > <hughaguilar96@gmail.com> wrote:
>> >>I wrote an RfD for Forth-200x asking that we have a word that, given th
> e
>> >>address of a memory-block in the heap, returns its size. This seemed
>> >>super-easy to me, because the information is already stored (FREE and
>> >>RESIZE access this information to do what they do). Everybody seemed to
>> >>like the idea, but then Leon Wagner killed it by saying that he wouldn'
> t
>> >>implement this in SwiftForth and he didn't understand what it was for.
>>
>> The SIZE RfD is still listed among the RfDs without CfVs.  I guess we
>> should do some timeout of RfDs after some time, though.
> 
> There is no need for an RfD to time-out --- there can be no further
> discuss ion after Leon kills an RfD, because Forth Inc. owns
> Forth-200x. The follow ing is how Leon Wagner killed the RfD. Notice
> how he is unaware of the size of operator in C++, and also unaware
> that objects can be copied when their type is not known at run-time
> (the type was declared at compile-tie only as that of a parent class,
> although it may actually be of a child class which would be bigger).
> He doesn't know what a VMT is, or know that it contains the size of
> the object.
> 
> Here is what Leon Wagner said:
> 
> I don't support this feature and would likely not implement it. Other
> than the nice discussion of what to name it, I see no compelling
> reason for its actual use.
> 
>> -----Original Message-----
>> From: forth200x@yahoogrou ps.com [mailto:forth200x@yahoogrou ps.com] On B
> ehalf Of Hugh Aguilar
>> Sent: Friday, January 29, 2010 2:41 PM
>> To: forth200x@yahoogrou ps.com
>> Subject: [forth200x] SIZE RfD
> 
>> My .NODE-SIZE field is a waste of memory. This information is held intern
> ally (FREE and RESIZE are able to obtain
>> it), so there is no need for me to hold onto it as well.
> 
> For hosted systems that use the heap management of the underlying OS,
> the i nternal information is "under the hood" and not available to us.
> This means that each and every call to ALLOCATE would have allocate
> additional space, retain the size, and fudge the pointers returned by
> ALLOCATE and used by F REE. Now *that* does seem wasteful.
> 
> I do not understand the argument that C++ programmers don't understand
> the need to keep track of allocated memory. As far as I know, the
> traditional m alloc and free are still in use, as well as new and
> delete (or new[] and de lete[]). But there's no "size of" memory space
> allocated. Is there?
> 
> --Leon
> 
> 
>> Why would it be different?  If you and Hugh cannot agree on a name
>> (and probably not on a common specification, either), that's certainly
>> not the fault of the standardization process; on the contrary, it
>> would explain why there is no progress in standardizing this feature.
> 
> This is totally dishonest. You are saying that the RfD died because
> myself and Albert couldn't agree on the name? Bullshit! We were having
> a "nice dis cussion" about the name, then Leon killed the RfD and the
> discussion ended. I had agreed that SIZE (my original suggestion) was
> a bad name. The names proposed were ALLOCATION (for the exact amount
> of memory requested) and ALL OCATED (for the amount of memory actually
> provided). That was fine with me. The ALLOCATED value is actually
> better because this is certainly stored in ternally, whereas the
> ALLOCATION value is not necessarily stored internally --- the
> ALLOCATED value is adequate for copying the object (there might be a
> few extra bytes copied, but that is not a problem) --- copying nodes
> wit hout knowing their data type is the whole point of this.
> 
> Anyway, Forth-200x is a joke --- it is totally owned by Forth Inc. ---
> it i s "astro turf" in the sense that a lot of effort is made (mostly
> by you) to present an image of it being a grassroots effort, but it is
> actually just SwiftForth.
> 
> All of the Forth-200x committee members are on Forth Inc.'s payroll,
> so the y just do what their boss Leon Wagner tells them to do --- it
> is the same a s at any corporation.
> 

I wasn't a big fan either. You kept banging on about GLIBC for some
reason I couldn't quite fathom. And don't blame Leon; that's the usual
paranoia kneejerk you have any time anyone from Forth Inc disagrees with
you. You simply failed to make your argument. I was then supporting a
Forth compiler (Win32Forth) and I too didn't support this feature and
didn't implement it.


https://groups.google.com/forum/message/raw?msg=comp.lang.forth/9HGIOO6zyag/ga5Qiy45m0wJ

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Extendable structure with inspection humptydumpty <ouatubi@gmail.com> - 2015-06-02 13:29 -0700
  Re: Extendable structure with inspection anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-03 06:02 +0000
    Re: Extendable structure with inspection humptydumpty <ouatubi@gmail.com> - 2015-06-03 08:27 -0700
  Re: Extendable structure with inspection humptydumpty <ouatubi@gmail.com> - 2015-06-03 11:30 -0700
    Re: Extendable structure with inspection Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-03 20:54 -0700
      Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-04 09:11 +0100
        Re: Extendable structure with inspection Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-04 04:43 -0700
          Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-04 20:21 +0100
            Re: Extendable structure with inspection Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-04 23:23 -0700
              Re: Extendable structure with inspection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-05 03:40 -0400
              Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 15:31 +0100
                Re: Extendable structure with inspection Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-05 08:48 -0700
                Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 18:10 +0100
                Re: Extendable structure with inspection albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-06 10:46 +0000
                Re: Extendable structure with inspection hughaguilar96@gmail.com - 2015-06-05 17:53 -0700
                Re: Extendable structure with inspection albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-06 10:56 +0000
                Re: Extendable structure with inspection anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-06 16:00 +0000
                Re: Extendable structure with inspection hughaguilar96@gmail.com - 2015-06-06 19:35 -0700
                Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-07 10:51 +0100
                Re: Extendable structure with inspection Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-08 23:24 +0200
                SIZE RfD: Re: Extendable structure with inspection anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-09 07:56 +0000
                Re: Extendable structure with inspection "Alex McDonald" <blog@rivadpm.com> - 2015-06-09 12:09 +0100
                Re: Extendable structure with inspection Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-09 23:25 +0200
              Re: Extendable structure with inspection "Elizabeth D. Rather" <erather@forth.com> - 2015-06-05 07:53 -1000
                Re: Extendable structure with inspection hughaguilar96@gmail.com - 2015-06-05 17:34 -0700
      Re: Extendable structure with inspection humptydumpty <ouatubi@gmail.com> - 2015-06-05 00:40 -0700
  Re: Extendable structure with inspection humptydumpty <ouatubi@gmail.com> - 2015-06-10 12:16 -0700

csiph-web