java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination

Re: [java-gnome-hackers] Enchant RuntimeException

[Serkan K. <se...@ge...>]

> Our doc says "Returns null if no suitable dictionary was found."
> http://java-gnome.sourceforge.net/4.0/doc/api/org/freedesktop/enchant/Enchant.html#requestDictionary(java.lang.String)
> so presumably we should do that.
Following this path then. Attaching the bundle

Regards,
Serkan KABA

Re: [java-gnome-hackers] Enchant RuntimeException

[Andrew C. <an...@op...>]

On Tue, 2010-03-09 at 20:34 +0200, Serkan Kaba wrote:
> When requestDict is called for an unexisting dictionary enchant returns
> null and we're not checking this so this throws a
> RuntimeException("Cannot make a Java proxy for the NULL pointer!")

Huh.

Our doc says "Returns null if no suitable dictionary was found."
http://java-gnome.sourceforge.net/4.0/doc/api/org/freedesktop/enchant/Enchant.html#requestDictionary(java.lang.String)
so presumably we should do that.

[adding a checked Exception would be an API change; while that's not
impossible, as usual I'd prefer not to without a compelling reason to]

AfC
Sydney

Re: [java-gnome-hackers] Enchant RuntimeException

[Serkan K. <se...@ge...>]

Or
c) If we plan to keep the RuntimeException (GtkSpell fails with a
RuntimeException if passed an unexisting Dictionary) then it should
give a meaningful message

2010/3/9 Serkan Kaba <se...@ge...>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> When requestDict is called for an unexisting dictionary enchant returns
> null and we're not checking this so this throws a
> RuntimeException("Cannot make a Java proxy for the NULL pointer!") from
> org.freedesktop.bindings.Pointer. I think this should cause a checked
> exception or return *java null* if we want to mimic what the underlying
> library does
>
> So please comment on what to do (I can work on a patch when we decide on
> the road to take)
> - --
> Sincerely,
> Serkan KABA
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuWlLcACgkQRh6X64ivZaKWqwCfXJNRXLHGTTXOm3uzepIPdp8D
> w1MAn16lV3mcfrx3rBgfbW+Amp+2xolf
> =du9k
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>

[java-gnome-hackers] Enchant RuntimeException

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

When requestDict is called for an unexisting dictionary enchant returns
null and we're not checking this so this throws a
RuntimeException("Cannot make a Java proxy for the NULL pointer!") from
org.freedesktop.bindings.Pointer. I think this should cause a checked
exception or return *java null* if we want to mimic what the underlying
library does

So please comment on what to do (I can work on a patch when we decide on
the road to take)
- -- 
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuWlLcACgkQRh6X64ivZaKWqwCfXJNRXLHGTTXOm3uzepIPdp8D
w1MAn16lV3mcfrx3rBgfbW+Amp+2xolf
=du9k
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Putting DataCo

[Serkan K. <se...@ge...>]

for a this is not mandatory but depends on whether you can afford the
extra memory needed for the model only column (and this depends on # of
rows expected) or the cpu time needed for conversion each time you need
the integral value (and this depends on how frequent you need the
integral value)

04-03-2010 06:55, Serkan Kaba yazmış:
>> Hi guys, 
>> this is my code, how convert DataColumnInteger to I can put it in
>> CellRendererText.?
>> is there CellRendererInteger? I cant find it!
>>
>> -- 
>> Best Regards.
>> F.Baghery
> You can't get DataColumnInteger rendered in CellRendererText, so you
> must have a DataColumnString filled with String representations of
> integers. But if you need the integral values of those later for
> a) using them as indices for lookup
> b) sorting the table wrt id.
> 
> then you can have a model only column that's not shown in the TreeView.
> 

-- 
Sincerely,
Serkan KABA
Gentoo Developer

Re: [java-gnome-hackers] Putting DataCo

[Serkan K. <se...@ge...>]

> Hi guys, 
> this is my code, how convert DataColumnInteger to I can put it in
> CellRendererText.?
> is there CellRendererInteger? I cant find it!
> 
> -- 
> Best Regards.
> F.Baghery
You can't get DataColumnInteger rendered in CellRendererText, so you
must have a DataColumnString filled with String representations of
integers. But if you need the integral values of those later for
a) using them as indices for lookup
b) sorting the table wrt id.

then you can have a model only column that's not shown in the TreeView.

-- 
Sincerely,
Serkan KABA

Re: [java-gnome-hackers] Putting DataCo

[Serkan K. <se...@ge...>]

> Hi guys, 
> this is my code, how convert DataColumnInteger to I can put it in
> CellRendererText.?
> is there CellRendererInteger? I cant find it!
> 
> -- 
> Best Regards.
> F.Baghery
You can't get DataColumnInteger rendered in CellRendererText, so you
must have a DataColumnString filled with String representations of
integers. But if you need the integral values of those later for
a) using them as indices for lookup
b) sorting the table wrt id.

then you can have a model only column that's not shown in the TreeView.

-- 
Sincerely,
Serkan KABA

[java-gnome-hackers] Putting DataCo

[F.Baghery <bag...@gm...>]

        final DataColumnString verses;
        final DataColumnInteger poem_id;

.
.

        model = new ListStore(new DataColumn[]{
                    poem_id = new DataColumnInteger(),
                    verses = new DataColumnString(),});

.
.

rs = stmt.executeQuery("SELECT poem_id,verse FROM classicpoems__poem_header
WHERE poet_id='1' ORDER BY poem_id ASC");

            if (rs != null) {
                rs = stmt.getResultSet();
                while (rs.next()) {
                    row = model.appendRow();
                    model.setValue(row, poem_id, rs.getInt(1));
                    model.setValue(row, verses, rs.getString(2));

                }

                vertical = verses_title_menu.appendColumn();
                vertical.setTitle("مقطع شعر");
                vertical.setAlignment(0.5f);
                renderer = new CellRendererText(vertical);
                renderer.setMarkup(verses);
                renderer.setAlignment(1.0f, 0.0f);

                vertical = verses_title_menu.appendColumn();
                vertical.setTitle("شماره");
                vertical.setAlignment(0.5f);
                renderer = new CellRendererText(vertical);
                renderer.setMarkup(poem_id); //Here returns:
setMarkup(org.gnome.gtk.DataColumnString) in org.gnome.gtk.CellRendererText
cannot be applied to (org.gnome.gtk.DataColumnInteger)

Hi guys,
this is my code, how convert DataColumnInteger to I can put it in
CellRendererText.?
is there CellRendererInteger? I cant find it!

-- 
Best Regards.
F.Baghery

Re: [java-gnome-hackers] RadioAction and RadioMenuItem coverage

[Andrew C. <an...@op...>]

On Fri, 2010-02-19 at 16:08 +0100, Guillaume Mazoyer wrote:
> Hello,
> 
> Well, now, everything is working. All the radio stuffs are working and
> implemented. RadioButtonGroup doesn't exist anymore

Uh, oops. No. We can't just delete it; it's been published API for many
releases so we have to keep it (and mark it deprecated). I've taken care
of that.

Merged to 'mainline'.

AfC
Sydney

Re: [java-gnome-hackers] RadioAction and RadioMenuItem coverage

[Guillaume M. <res...@gm...>]

Hello,

Well, now, everything is working. All the radio stuffs are working and
implemented. RadioButtonGroup doesn't exist anymore and RadioGroup is
taking its place. The RadioGroup is a generic group that can be used
with RadioButton, RadioAction, RadioMenuItem and RadioToolButton. It has
the same method and signal that the RadioButtonGroup had.

So I guess that the branch can be merged (to be a part of java-gnome
4.0.15) but it's up to Andrew to decide. If you have any comments or
improvements (that can be done), please let me now.

-- 
Guillaume Mazoyer - http://www.respawner.fr/

[java-gnome-hackers] Release imminent

[Andrew C. <an...@op...>]

Hey all,

This has been a pretty casual period, but there are a few API additions
in and it's time we did a release.

There's also a fix for the initialization check, and that alone makes me
want to cut another tarball as soon as possible :)

There are a few outstanding issues:

The memory pressure thing is a looming problem, but as it is
"correct" (we're not leaking) it's not super urgent. I'd like to see us
address the issue, but we're first going to have to come up with a
really rigorous way of *measuring* the impact; watching
`gnome-system-monitor`'s Writeable Memory column while "doing stuff"
with a long-running app like Quill isn't exactly repeatable or precise.

The business with calling Dialog's run() in another thread blocking is
annoying. There's at least a workaround strategy so it's not something
we need to hold off the release for.

Guillaume is hard at work on RadioMenuItem, RadioAction,
RadioToolbarButton and others stuff. We've raised the prospect of
changing our RadioButtonGroup into just "RadioGroup" which would be
wicked cool, as having all these different -Group classes would be silly
if we can at all avoid it. THIS is something I would really like to see
in, so if Guillaume thinks he can work on it some more over the next few
days we'll give it a shot.

The only other major thing is Vreixo's events patch. That's partially
merged, and the bits that are in work, but I'm not sure it does
everything he needed, so he or someone will need to have a look at that
if it's important.

So I'll do a 4.0.15 release candidate early next week, and we'll go from
there.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] RadioAction and RadioMenuItem coverage

[Andrew C. <an...@op...>]

On Mon, 2010-02-15 at 22:15 +0100, Guillaume Mazoyer wrote:
> Done. And the test case confirms what I was thinking.

Great. 

The extra check you put in [which was actually a no-op type check] was
misleading you. The error you were getting from GTK was in fact telling
you the problem - which was that you were passing a NULL down to a
constructor that doesn't accept them.

So here's what I did to make Guillaume's branch work. Mostly it was just
choosing different constructors to achieve the desired effect. I took a
guess and experimented with what happens if you call
gtk_radio_menu_action_new() with NULL as the GSList*. Turns out it
works.


=== modified file 'src/bindings/org/gnome/gtk/RadioMenuItem.java'
--- src/bindings/org/gnome/gtk/RadioMenuItem.java	2010-02-01 15:49:40 +0000
+++ src/bindings/org/gnome/gtk/RadioMenuItem.java	2010-02-15 21:36:47 +0000
@@ -73,11 +73,23 @@
      * @since 4.0.15
      */
     public RadioMenuItem(RadioMenuItemGroup group, String label) {
-        this(GtkRadioMenuItem.createRadioMenuItemWithLabelFromWidget(group.getMember(), label));
+        super(createFirstOrNext(group, label));
         group.setMember(this);
         enclosingGroup = group;
     }
 
+    private static long createFirstOrNext(RadioMenuItemGroup group, String label) {
+        final RadioMenuItem first;
+
+        first = group.getMember();
+
+        if (first == null) {
+            return GtkRadioMenuItem.createRadioMenuItemWithMnemonic(null, label);
+        } else {
+            return GtkRadioMenuItem.createRadioMenuItemWithMnemonicFromWidget(first, label);
+        }
+    }
+


Anyway, my fix to your branch is at 
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/radio-things

Merge away :)

On Fri, 2010-02-12 at 09:00 +0100, Guillaume Mazoyer wrote: 
> 	'hackers/guillaume/toggle-action'

Incidentally, if you copy a class verbatim, it'd be nice to put a note
saying where you got the code from. It would have made it easier to
realize that: 

$ diff src/bindings/org/gnome/gtk/RadioButtonGroup.java src/bindings/org/gnome/gtk/RadioMenuItemGroup.java

wasn't going to show anything meaningful.

That class sure is ulgy. And now there are two of them. :(

You're right that it'd be nice to be able to have some group thing that
was common for all the RadioWhatevers. Not sure how we'd do that,
though. 

AfC
Sydney



-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] RadioAction and RadioMenuItem coverage

[Guillaume M. <res...@gm...>]

> Write a test that fails in tests/bindings/, add it to the test suite,
> and then we can see what you're up to. This is often a good way to see
> how your API is shaping up. Failing that there are the tests/snapshots/
> and doc/examples/ trees too.
Done. And the test case confirms what I was thinking.

-- 
Guillaume Mazoyer - http://www.respawner.fr/

Re: [java-gnome-hackers] RadioAction and RadioMenuItem coverage

[Andrew C. <an...@op...>]

On Fri, 2010-02-12 at 09:00 +0100, Guillaume Mazoyer wrote:
> I took a look to the code code
> again and I still cannot see how to fix the error that I have.

Do you have a test case or example? I grabbed your branch but there's no
test coverage so it's a bit hard to duplicate the crash you're
experiencing.

Write a test that fails in tests/bindings/, add it to the test suite,
and then we can see what you're up to. This is often a good way to see
how your API is shaping up. Failing that there are the tests/snapshots/
and doc/examples/ trees too.

AfC
Sydney

[java-gnome-hackers] Initialization check

[Andrew C. <an...@op...>]

I attempted to get things back to warning clearly [rather than getting a
CRITICAL out of some GNOME library] if you haven't called Gtk.init() as
the first use of something in java-gnome.

I added isLibraryReady() to [org.freedesktop.bindings] Plumbing. It gets
called from most other packages' Plumbing static initializers.

The juggling between the sequencing of the static initializers and the
check is very tricky.

Anyway, as you're testing 'mainline' keep an eye out for this hopefully
preventing you from making a mistake about using java-gnome properly.

AfC
Sydney

Re: [java-gnome-hackers] RadioAction and RadioMenuItem coverage

[Guillaume M. <res...@gm...>]

Hello,

I was pretty busy these last days and I couldn't work on the
RadioMenuItemGroup. I'm back now, so I took a look to the code code
again and I still cannot see how to fix the error that I have.

The branch is available for the people who are interested to take a look
to it. You can found it at:

	bzr/java-gnome/hackers/guillaume/toggle-action/

-- 
Guillaume Mazoyer - http://www.respawner.fr/

Re: [java-gnome-hackers] Motion event and eventmask

[Andrew C. <an...@op...>]

On Fri, 2009-05-22 at 22:08 +0000, Vreixo Formoso Lopes wrote:
> ... an improved implementation of enable/disable events.
> The patch also includes ...

So I did a partial merge of Vreixo's 'event-masks' branch. Certainly all
the work exposing EventMask was excellent and that deserved to go in
regardless.

The part I wasn't comfortable with was the enableEvents() /
disableEvent() idea that Vreixo has. In unrelated work I found myself
exposing Widget's setEvents() and addEvents() methods, then remembered
Vreixo had worked on EventMask, and turned to his 'event-mask' branch.
Most of what he wrote for enableEvents() was sound, so I just used that
text for setEvents().

I also merged the MotionNotifyEvent interface and connect() stuff in
Widget.

Since I'm not entirely sure what he was doing that ran him into trouble,
so I'm sure we'll need a bit more [getEvents() + some more Flag stuff?]
to satisfy his need, but I wanted to get the good stuff in so we could
focus on the diff of just the difficult part.

++

I feel like I'm getting better at cherry picking. The trick for the
gatekeeper (me) is to `bzr revert` the bits we're not ready to accept,
then committing the remaining diff as the merge. That means

a) history isn't lost and we DO incorporate code we are ready to accept,

b) future diffs of the contributor's branch against 'mainline' are
smaller.

c) what goes into 'mainline' is clean but requires

d) people contributing branches with work-in-progress like this to then
"revert" when *they* next merge 'mainline' into their own
work-in-progress branch.

That way they keep their changes, (it's not up to me to tell them they
can't have whatever code they want) but they can continue to stay up to
date.

In hindsight, this is what John wrote about here:
http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html

That's not exactly how I manage things, but the basic idea is similar.
Interesting all the same.

++

Anyway, I'll try and warn when I've done a partial merge so that
contributors working on a given feature branch can be aware to be
careful if merging 'mainline'.

Speaking of which, 'event-masks' merged to 'mainline' as at revno 713.

AfC
Sydney

[java-gnome-hackers] RadioAction and RadioMenuItem coverage

[Guillaume M. <res...@gm...>]

Hello,

I'm facing some difficulty to add the coverage of RadioAction and
RadioMenuItem. As we spoke with Andrew several hours ago, I created a
RadioMenuItemGroup to avoid the complexity [and the idiocy] of the
GSList* to manage a group of widget. I did it like the existed
RadioButtonGroup. Here is an example of how to use my current code:

RadioMenuItemGroup group = new RadioMenuItemGroup();
RadioMenuItem item1 = new RadioMenuItem(group, "item1");
...

But I have an error when I try to use this previous piece of code.

org.gnome.glib.FatalError: Gtk-CRITICAL
gtk_radio_menu_item_new_with_label_from_widget: assertion
`GTK_IS_RADIO_MENU_ITEM (group)' failed
at
org.gnome.gtk.GtkRadioMenuItem.gtk_radio_menu_item_new_with_label_from_widget(Native Method)
at
org.gnome.gtk.GtkRadioMenuItem.createRadioMenuItemWithLabelFromWidget(GtkRadioMenuItem.java:143)
at org.gnome.gtk.RadioMenuItem.<init>(RadioMenuItem.java:76)

Into the RadioMenuItem constructor, I call the getMember() method from
the RadioMenuItemGroup which returns a RadioMenuItem. But the first call
of this method will return *null* because there will be no member in the
group.

So, I assume that the error is due to that group.getMember() == null.
Do you have any idea?

Thank you for your advice and your help.

-- 
Guillaume Mazoyer - http://www.respawner.fr/

[java-gnome-hackers] Dialog's run() blocking other threads

[Andrew C. <an...@op...>]

Guillaume hit an interesting problem: Dialog's run() is preventing his
other GTK-using threads from running. I talked about it with him on IRC,
and he filed https://bugzilla.gnome.org/show_bug.cgi?id=606796 for us.

The native gtk_dialog_run() is known to be magic. It has it's own pseudo
gtk main loop in order to implement the modal dialog effect. Not to
mention other voodoo-ness.
http://library.gnome.org/devel/gtk/stable/GtkDialog.html#gtk-dialog-run

We expect gtk_dialog_run() to release the GDK lock just like gtk_main()
does.  Reading the C code in GTK, it seems to be implemented the same.

So, the problem is that our lock is nesting in the signal handler.
That's fine, and to be expected. The reentrant lock we're using (a Java
object monitor) means that the signal handler code can in turn keep
making GTK calls and since it has the lock, they go through.

But Dialog's run() could reasonably be expected to "release everything"
and allow the rest of the code to run.

So for that case [only] we need to be all the way out of the Gdk$Lock.
That's not possible on the Java side [unless we replace the

        synchronized (lock) {
        	...
        }

blocks with a java.util.concurrent.locks.Lock implementation of our own,
along with the:

        lock.lock()
        try {
        	...
        } finally {
        	lock.unlock()
        }
        
pattern, to enable us to call unlock() elsewhere]

However, be fore we get that ugly & invasive, we may be able to do a
MonitorExit() / MonitorEnter() pair in C side
GdkDialogOverride.gtk_dialog_run implementation. That's not necessarily
a good idea. In fact, it's not really supposed to be allowed, but I
think it'll work; in the end it's a direct wrapper around a VM
instruction, and as far as I can tell it's just a counter in the
monitor.

We'll have to get our facts straight first. Guillaume said he'd run some
tests over the weekend to verify that what we think happens actually
happens [is still happening] with respect to gdk_threads_enter() and
gdk_threads_leave() calls.

As I noted on the bug (and Guillaume tested), there is a workaround for
anyone having this problem: use present() on the Dialog and then
connect() to Dialog.Response as necessary, letting the original main
loop do it's thing and leave GtkDialog's magic inner main loop out of
it.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] Res: The next stage in memory management

[Andrew C. <an...@op...>]

On Tue, 2010-01-12 at 17:29 +0000, Vreixo Formoso Lopes wrote: 
> Hi all,

Hey Vreixo, nice to see you.

> I hope to take a further look at this asap, but I'd like to give you
> some impressions about this issue:

Sure. Quick replies follow (and so anyone please feel free to re-reply
to the original message, or this).


> In any case, a "kill -9 whatever" will terminate the JVM without any cleanup (either in finalize() 
> or by other means) so I doubt "special circumstances" should be handled at all by java-gnome.

Sure. That said, full application termination isn't a case we're worried
about here. If the release() -> g_object_unref() -> free() doesn't run
at shutdown that doesn't really hurt because a few cycles later the
process will be destroyed by the kernel and its memory freed. But that's
GTK' & X's problem. As "users" of GTK, we need to Do The Right Thing in
all other circumstances.

> > The problem is that the full Java garbage collector [and I'm talking
> > about OpenJDK HotSpot here] does not ordinarily run until the VM thinks
> > it is out of heap. And that isn't going to happen anytime soon on most
> > systems. Which means that finalize() isn't get called until *MUCH* later
> > than we'd like, and we're holding on to tons of memory (allocated by
> > glib) unnecessarily.
> 
> I wonder if what we should do is to launch any java-gnome application with specific
> GC-related JVM options.

I hadn't thought of that. Maybe...

But -XX options aren't exactly something we can rely on. Still, if we
know we're running HotSpot VM 6 [say], then we should tune it as best we
know how.

And meanwhile there are the GLib memory related options. But I don't
think any of them (ie "always-malloc") are necessary for us [at least,
not unless we mess with the GLib allocator functions]

> > Which brings us back to the _other_ purpose of SoftReference,
> > WeakReference, and PhantomReferences: taking actions on Java objects as
> > they go through the lifecycle, including being able to do cleanup long
> > before finalize() gets called by the GC in it's second last phase.
> 
> In any case, does not the GC need to be called in order to the JVM detect an object
> has changed its reachability? In such case, using another kind of reference would be
> useless. Or am I missing something?

Good question.

My understanding is that *finalize* [-> disposal] happens very late (if
at all) and only in full GC.

So in all the work we did a few years back in ValidateMemoryManagement
etc, we were calling System.gc() and so manually triggering a full GC,
and seeing our objects release() -> removeToggleRef() all correctly.

Using a breakpoint in Eclipse's debugger the finalize() methods are
indeed getting called... but late in the game.


> In any case, does not the GC need to be called in order to the JVM
> detect an objecthas changed its reachability? In such case, using
> another kind of reference would be useless. Or am I missing something?

So my inference & observation is that

a) the GC runs fairly often, but the "full" GC does not.

b) ReferenceQueues are handled in a Thread separate from the GC, and
that thread runs like any other thread.

[see the code in java.lang.ref.Reference in OpenJDK
jdk/src/share/classes/java/lang/ref/Reference.java which is where the
ReferenceHandler thread gets started. I get that the GC treats it a bit
specially, but it's still Java code]

anyway, if (b) is true, then [say] WeakReferences being enqueued to the
queue they are registered to happens automatically & soon after they are
eligible. So we could react to that.

Whereas finalize() happens MUCH MUCH later.

[which sucks, but there you have it]

> 
> > Presumably we want another WeakReference, plus a ReferenceQueue. The
> > question is: what will poll the reference queue, and when?
> 
> What exactly are you thinking about? Do you plan that when an object changes its reachability 
> to, say, weak, a cleanup method will be invoked?

So interesting distinction here:

in the GObject ToggleRef code, we switch everything to and from
WeakReference. And later those go away.

But ReferenceQueues are for _after_ something finishes at a given
reachability.

As far as I can tell, a Reference gets enqueued to the ReferenceQueue it
is registered to after it _leaves_  (or is eligible to leave) that
reachability level.

Which would be all references to a given Java object being weak or less
[which is when the ToggleRef is the last Ref, and we don't have any
strong Java references in our Java code].

Which is when we are currently then waiting for finalize() to be
invoked, calling release(), -> g_object_remove_toggle_ref() -> free().

So, if we instead call release() in response to getting a
[Weak]Reference enqueued to a ReferenceQueue, it should be the same
point.

But maybe I'm missing something :)


> If so, why do we need another WeakReference?
> Can't we just use the weak reference we have on Plumbing? In such case, the
> 
> 
>         Plumbing.unregisterProxy(this);
> 
> we have on Proxy.finalize() can be invoked as part of such post-weak processing.

Except that is a WeakReference for Proxy only, not the Pointers (Boxeds,
etc which is what GValues and PangoLayoutLines are right?).

So I figured it would have to be a WeakReference created when Pointer
are constructed. ie call Plumbing.registerPointer() or so.

Of course, if we have to have a WeakReference for everything, then maybe
we can use it for registerProxy() too, rather than having a second one
there.

But your suggestion (?) of polling the queue when unregister*Proxy*() is
called could make sense. We just need to process the queue periodically.
Doesn't have to be in it's own thread.

++

Anyway, ReferenceQueues are just one idea. I'm not saying it's the best
way to go.

It's possible we could be more aggressive when we handle window
delete-event -> hide 'n all, or maybe special case handling of
expose-event, or...

AfC
Sydney

[java-gnome-hackers] Res: The next stage in memory management

[Vreixo F. L. <met...@ya...>]

Hi all,

I hope to take a further look at this asap, but I'd like to give you some impressions about this issue:


> Now, what most people meant when they talk about "unreliable" is that
> they are not "guaranteed" to be called; a number of circumstances
> [/implementations] just terminate the Java VM process without calling
> the finalizers of every bloody object

In any case, a "kill -9 whatever" will terminate the JVM without any cleanup (either in finalize() 
or by other means) so I doubt "special circumstances" should be handled at all by java-gnome.

>. So if (say) you're holding on to
> database client connections, they won't necessarily get cleared /
> closed / etc. Bad.

That's not necessarily true. When a process finalizes (either normal way or killed) Linux will
free the systems resources it was using. In particular, TCP connections are regularly closed 
(I mean, a TCP FIN packet is sent, however application-level close, if any, is not, as expected).

> The problem is that the full Java garbage collector [and I'm talking
> about OpenJDK HotSpot here] does not ordinarily run until the VM thinks
> it is out of heap. And that isn't going to happen anytime soon on most
> systems. Which means that finalize() isn't get called until *MUCH* later
> than we'd like, and we're holding on to tons of memory (allocated by
> glib) unnecessarily.

I wonder if what we should do is to launch any java-gnome application with specific
GC-related JVM options.

> Telling people just to call System.gc() doesn't really seem to address
> the weakness.

Afaik, in modern JVM System.gc() does nothing.

> Which brings us back to the _other_ purpose of SoftReference,
> WeakReference, and PhantomReferences: taking actions on Java objects as
> they go through the lifecycle, including being able to do cleanup long
> before finalize() gets called by the GC in it's second last phase.

In any case, does not the GC need to be called in order to the JVM detect an object
has changed its reachability? In such case, using another kind of reference would be
useless. Or am I missing something?

> Presumably we want another WeakReference, plus a ReferenceQueue. The
> question is: what will poll the reference queue, and when?

What exactly are you thinking about? Do you plan that when an object changes its reachability 
to, say, weak, a cleanup method will be invoked? If so, why do we need another WeakReference?
Can't we just use the weak reference we have on Plumbing? In such case, the


        Plumbing.unregisterProxy(this);

we have on Proxy.finalize() can be invoked as part of such post-weak processing.

> Sometime people use a separate thread for that. Another possibility
> would be to use an idle handler setup from the native side. A third
> option would be to poll the reference queue as a (generated) part of
> every JNI call.

The idle handler seems the best alternative to me, at least the one with less performance 
impact. On applications with high memory requirements, however, may the 3rd option
is the best. Anyway, we can offer this as a compilation or runtime option (maybe via a JVM
parameter or environment var?)

Cheers
Vreixo

PS: I'm glad to write to this list again! Congratulation to all of you for your hard work.


      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

[java-gnome-hackers] Adding COPYING file to the tarball

[Andrew C. <an...@op...>]

As mentioned on the -developer list, I've taken care of a niggling todo
item, which is to add full "GPL" headers to our source files, and the
"Classpath Exception" blurb to those files that are part of the
resultant library .jar & .so.

I already discussed this with our downstream Debian and Gentoo
packagers, but no one needs to freak out that we changed the licence or
something. It's still what it's been all along: java-gnome is made
available by its authors under the terms of the GNU General Public
Licence version 2, with the exception that you are allowed to link to
the library without triggering the GPL so long as you haven't changed
the library itself as released - if you have, the GPL applies.

This is the same licence that GNU Classpath's glibj was released under,
and was what Sun chose when they freed their Java implementatio as
OpenJDK.

Like I said, no change. Just a lot more verbose gunk in the file
headers :)

Now if we can just get Ohloh to stop choking when reading our repo...

AfC
Sydney


On Tue, 2010-01-05 at 16:00 +1100, Andrew Cowie wrote:
> On Thu, 2009-12-31 at 14:20 +0100, Alexander Boström wrote:

> > COPYING
> 
> yeah yeah :)
> 
> As it happens, I've just redone the copyright headers for another
> project of mine so that Ohloh will recognize it as GPL v2. I'll be doing
> the same thing over the next few days to java-gnome, presumably with the
> classpath exception text
> http://www.gnu.org/software/classpath/faq/faq.html#faq2_1 as well for
> the distributed part of the library.
> 
> And yes, I'll include a COPYING file. :)

[java-gnome-hackers] The next stage in memory management

[Andrew C. <an...@op...>]

Way back in the dark ages, we started the current version of java-gnome.
We [especially Vreixo] invested a huge amount of time in getting the
memory management correct, specifically the use of ToggleRefs to manage
the reference count that a java-gnome proxy has on a GObject, while
being able to return the existing proxy for a GObject if there is one,
using WeakReferences and the JNI equivalent. Magic no end.

Through extensive experience, that work has held up nicely.

If you were to look in the base class Pointer, you'd see a nice little
fragment I wrote four or so years ago as follows:


    /**
     * Parent release function. Will be called by the Java garbage collector
     * when it invokes the finalizer, so this is the time to release
     * references and free memory on the C side.
     */
    protected abstract void release();

    /*
     * This is a placeholder to remind us of the cleanup actions that will be
     * necessary, irrespective of the finalizer technique used.
     */
    protected void finalize() {
        release();
    }

Right from the get-go, I knew that we'd have to have our own code path
to free resources, and I also knew full well that Java's finalize()
mechanism is "unreliable" and that really if you need to clean up after
yourself you should be using PhantomReferences (or WeakReferences or
SoftReferences, depending).

Now, what most people meant when they talk about "unreliable" is that
they are not "guaranteed" to be called; a number of circumstances
[/implementations] just terminate the Java VM process without calling
the finalizers of every bloody object. So if (say) you're holding on to
database client connections, they won't necessarily get cleared /
closed / etc. Bad.

In normal usage, though, finalizers *do* indeed get called, and for our
purposes they were fine. And so the placeholder above has been doing us.

I've started to run into a circumstance where this is not ideal,
however. I'm doing something that is [org.gnome.pango] Layout &
LayoutLine heavy; down in Pango itself these use a lot of resources;
ordinarily that's fine because they are transient, but the thing I am
working on is generating a *lot* of them, and they aren't getting
free()'d until ... well, last time I ran the app I got myself > 100 MB
of writable memory before a full GC happened. Yeech.

The problem is that the full Java garbage collector [and I'm talking
about OpenJDK HotSpot here] does not ordinarily run until the VM thinks
it is out of heap. And that isn't going to happen anytime soon on most
systems. Which means that finalize() isn't get called until *MUCH* later
than we'd like, and we're holding on to tons of memory (allocated by
glib) unnecessarily.

Telling people just to call System.gc() doesn't really seem to address
the weakness.

Which brings us back to the _other_ purpose of SoftReference,
WeakReference, and PhantomReferences: taking actions on Java objects as
they go through the lifecycle, including being able to do cleanup long
before finalize() gets called by the GC in it's second last phase.
See file:///usr/share/doc/openjdk-6-doc/api/java/lang/ref/package-summary.html#reachability
for more details.

Presumably we want another WeakReference, plus a ReferenceQueue. The
question is: what will poll the reference queue, and when?

Sometime people use a separate thread for that. Another possibility
would be to use an idle handler setup from the native side. A third
option would be to poll the reference queue as a (generated) part of
every JNI call.

Thoughts?

AfC
Sydney

P.S. What I *really* want to do is override g_object_ref() and
g_object_unref(), but that'd only be possible with a LD_PRELOAD hack.
But if they were plugable, and in conjunction with setting the Glib
allocator function [which is plugable] to use (say) direct buffers, we
could really get cool about leak detection on both sides. But that's
another project.

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] IconView selection methods

[Andrew C. <an...@op...>]

On Wed, 2009-12-30 at 13:50 +0100, Guillaume Mazoyer wrote:
> I added the pathIsSelected(TreePath) method to know if a path is selected or not.

Lovely

> I'd rather name this method isSelected(TreePath). What do you think
> about that?

Hm.

a) for boolean property getters we have _not_ used the isXXX()
signature, preferring a useful getXXX() completion space across all
properties.

b) for *questions* we happily use isYYY().

However,

c) unless there's a really good reason, we try to stick to the
algorithmic mapping of the underlying library's naming.

So the question is, is this case a "really good reason"?

I'm not sure, but I agree isSelected() would be nice.

So sure :) go ahead.

There is a gtk_tree_selection_path_is_selected() in addition to the
gtk_icon_view_path_is_selected() you're asking about. If we change one,
we should [expose and] change the other too.

AfC
Sydney

Re: [java-gnome-hackers] IconView selection methods

[Guillaume M. <res...@gm...>]

Le mercredi 30 décembre 2009 à 12:30 +1100, Andrew Cowie a écrit :
> Have you got a test case or two? Maybe select a path and then make sure
> it actually _is_ selected, something like that?
Now it's done and available in the branch. By the way, I add the
pathIsSelected(TreePath) method to know if a path is selected or not.
I'd rather name this method isSelected(TreePath). What do you think
about that?

-- 
Guillaume Mazoyer - http://www.respawner.fr/