B A T T E R Y M O N I T O R 0.3
-----------------------------------

WHAT IS IT:

Battery monitor is a small utility that displays the status of your
laptop battery (charge/discharge and status). Currently, it works only
on Linux with ACPI with 2.6 kernels since it reads files in /proc and
relies on that format. It runs also on FreeBSD thanks to patches by
Chris Vetter.

It is a 0.3 release and thus has some limitations but it is already
working and I found no problems running it on my computer and thus I
wanted to share it with you all.

What is new in 0.3 ?
- bug fixes, especially a nasty memory leak
- percentage display
- better handling of strange ACPI cases (like charge greater than 100%%)
- an Icon
- cleaner system to support different platforms

WHERE:

On 06.07.2008, at 20:40, Richard Frith-Macdonald wrote:

In libFoundation you would watch the object for finalization, check

+ (void)registerForFinalizationObserver:(id)observer
selector:(SEL)selector
object:(id)object

for the implementation. Its 'relatively' expensive though.

Don't know what additional features todays Boehm GC has.

On 6 Jul 2008, at 19:03, Helge Hess wrote:

Well, it looks to me like the easiest way to get something broadly
compatible with Apple's implementation. I think we need the
capability to zero weak references when the memory referenced is GC'd
though ... not sure if that's easily achieved with Boehm.

Hi,

I'm not sure whats wrong with the BoehmGC implementation. Its fast and
efficient, it works very well, and it can be easily made interoperable
with RC (if thats really required).

A big problem with Foundation RC is that the reference count is
managed using methods (-retain/-release), which is pretty slow.

Greets,
Helge

PS: libFoundation actually contains a GC which works on top of the
regular RC and can be used to detect cycles.

On 6 Jul 2008, at 14:00, David Chisnall wrote:

I think that's a little unkind ... it has the advantage that you never
need to call retain, release, or autorelease. Probably to most people
that's all GC is about. They aren't interested in performance or in
how you deal with tricky cases, just in the fact that with GC you can
(for many applications) simply pay no attention to the issue whatsoever.

From a technical viewpoint I agree.

So, I've been thinking for a while that the implementation of GC that
Apple seem to have settled upon is, to be polite, a complete
disaster. The need for weak pointers means that it has no advantages
over ref counting and lots of disadvantages.

One thing that Apple seem to have forgotten is that reference counting
is a form of GC - replacing it with a tracing collector doesn't make
much sense, especially if it's a very poor tracing collector, and
adding GC to the compiler, rather than the library, goes against the
spirit of Objective-C.

Reference counting works quite well, and doesn't have very large
overheads (it also plays nicely with swapping, which tracing doesn't
and leads to some quite pathological behaviour if you have low
memory), but it has one significant flaw - it doesn't handle cycles.
Adding a cycle detector to NSObject seemed like a better solution.