[fpc-pascal] PasCocoa design

[Travis Siegel]

Actually, it's not just the file system that eats space that leads to  
a 500GB disk being shown at just over 400GB.
It's also determined by how the manufacturer measures 1K of data.   
Some manufacturers in order to inflate their drive values, treat a K  
as 1,000 bytes.  This is not accurate.  1K is actually 1024 bytes.
When you're talking about GB size ranges, this leads to huge  
descrepincies in rated vs actual sizes.  Thats why I like the Lasie  
drives, they rate according to a 1024 byte K, and so their drives are  
always very close to the rated size, whereas 1 500GB drive I bought  
(manufacturer will remain nameless) was actually a 435GB drive, which  
made me *very* angry.
If they want to claim 1000 bytes is 1K, then they should be required  
to say so somewhere on their packaging. I happily would have paid the  
extra 20 bucks, and got something that was closer to the actual 500GB  
mark if I had known.

On Feb 12, 2009, at 7:06 AM, OCTAGRAM wrote:

>
> Where are discussions about it occuring? I'd like to follow your  
> progress.
> Maybe we could share some thoughts.
>
> In AdaStep (aka gnat-cocoa) there is a problem with GC. Turning GC  
> on is
> probably not an option at the moment. Classes created by Objective-C
> compiler are binary-documented by compiler, but Ada ancestors are  
> not going
> to be unless someone write ASIS utility to parse Ada sources.
>
> Personally, I am all against GC. People complain loudly when  
> discover that
> their new 500Gb HDD is detected as 418Gb or so. Decimal/hexadecimal  
> Gbs, FS
> structures, 10% reserved for root -- this all adds to storage  
> losses. People
> complain when they lose 8-30%. How happy can such a man be knowing  
> that GC
> program can effectivelly use just 20%-40% out of his operative memory
> (loosing 60-80%)?
>
> I can think of solution like having two internal arrays of strong  
> and weak
> references. To mark an array is simpler than arbitrary Ada object  
> layout.
> And there still probably remain bounded errors. Boehm's heuristic  
> behaviour
> on untyped objects doesn't sound good to me.
>
> Life would be much easier if one did not have to overlay non-GC PLs  
> on top
> of GC ones.
>
> In .NET doing this is a bit simpler: .NET objects can be accessed  
> through a
> COM. .NET wrappers correctly respond to AddRef and Release methods.  
> Apple
> website states that retain and release do nothing in GC environment:
>
> http://developer.apple.com/leopard/overview/objectivec2.html
>
>
> With garbage collection enabled, the older reference count memory  
> management
> methods of retain, release, and autorelease have no effect.
>
> I'm asking those who has Leopard, how much does programmer lose  
> denying GC?
> May be GC is not worth bothering about.
>
> -- 
> View this message in context: http://www.nabble.com/PasCocoa-design-tp21975675p21975675.html
> Sent from the Free Pascal - General mailing list archive at  
> Nabble.com.
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal