Rob Eden | 22 Apr 16:29 2014
Picon

CI build?

Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any
devs that want it.

Rob
Holger Brands | 18 Apr 16:29 2014

JavaFX extension & Issue Browser

Hi,

I just committed the first version of a JavaFX-based Issue Browser demo application.
It's still work in progress, but has already similar functionality as the SWT-based browser.

Kudos to Rob: your EventObservableList adapter seems to work like a charm ;-)

I also expanded the JavaFX extension a bit:
I added a JavaFxThreadProxyEventList and a GlazedListsFx factory class.
There is also a new JavaFx-based TextMatcherEditor (TextInputControlMatcherEditor).

Work on this continues after the GitHub migration...

Holger

Rob Eden | 17 Apr 17:45 2014
Picon

Fwd: [JIRA] Resolved: (GLAZEDLISTS-556) DebugList Locking is not thread safe

Hey Holger -

Just checking: Is “1.10.0” the correct “Fix Version” for current bugs?

Rob

Begin forwarded message:

From: "reden (JIRA)" <jira-no-reply <at> java.net>
Subject: [JIRA] Resolved: (GLAZEDLISTS-556) DebugList Locking is not thread safe
Date: April 17, 2014 at 10:01:49 AM CDT


    [ https://java.net/jira/browse/GLAZEDLISTS-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

reden resolved GLAZEDLISTS-556.
-------------------------------

   Fix Version/s: 1.10.0
      Resolution: Fixed

Changes applies in svn change 2376:
{quote}
Fix of GLAZEDLISTS-556: applied patch from user "goochjj" with slight modification:
- Fixed spelling of "acquire"
- Removed check in beforeWriteOperation that was seeing if a read lock was held instead. It was redundant (since trying to get a write lock when a read lock is held would already throw an error) or wrong (since downgrading a write lock to a read lock is permitted) and was causing issues with unit tests.
{quote}

DebugList Locking is not thread safe
------------------------------------

               Key: GLAZEDLISTS-556
               URL: https://java.net/jira/browse/GLAZEDLISTS-556
           Project: glazedlists
        Issue Type: Bug
        Components: core
  Affects Versions: current
       Environment: All supported environments
          Reporter: goochjj
          Assignee: reden
           Fix For: 1.10.0

       Attachments: 0001-updates-to-DebugList-and-DebugLock-semantics.patch

 Original Estimate: 15 minutes
Remaining Estimate: 15 minutes

DebugLock uses an ArrayList internally to track Threads that have locked the delegate.  The access to the ArrayList is (mostly) done within the locked area of the locks; however, our locks are reentrant, and the read lock allows multiple readers.  Plus checking uses the contains method which is run from an unlocked thread.
When instantiating threadsHoldingLock it should be wrapped in a Collections.synchronizedList call.
In addition, I have enhanced the checks to detect deadlocks caused by the inability to upgrade a read lock to a write lock.
See attached patch.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



Fabian Zeindl | 20 Dec 17:48 2011
Picon

Serialize SortedList

Hi,
 is there any way to serialize a SortedList, so i won't have to do the
sorting all the time? Since AbstractTableComparatorChooser is serializable…

Regards
Fabian Zeindl

--
View this message in context: http://glazedlists.1045722.n5.nabble.com/Serialize-SortedList-tp5089414p5089414.html
Sent from the GlazedLists - Dev mailing list archive at Nabble.com.

Holger Brands | 11 Dec 11:12 2011

Re: AutoCompleteSupport

Hi Tobias,

I'll let James comment and answer your specific questions, because he is the author of this component.
Please keep in mind that AutoCompleteSupport mimics the firefox address field as it were at that time, a few years back.

Because of backward compatibility reasons I think AutoCompleteSupport will stay more or less the same.
But if you want to contribute an alternative implementation/component, we'd appreciate it a lot.
If it turns out to be stable and useful, I'd be happy to include it in GlazedLists.

Sounds good?
Other opinions out there?

Thanks,
Holger


2011/12/7 tobias.schulte <at> gliderpilot.de <tobias.schulte <at> gliderpilot.de>

Hi,

I am in the process of refactoring AutoCompleteSupport for my needs. I want to make it so, that it does not alter the editable property of the JComboBox any more but instead in readonly mode behaves more like the language selector at https://gist.github.com/. In editable mode it will behave as in non-strict mode.

I will remove strict and beepOnStrictViolation and any code handling these, because these are not necessary any more.

hidesPopupOnFocusLost is not necessary IMHO, because it is just a workaround for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5100422. It just increases complexity and therefore I will drop it.

I want to drop any complexity from the editable combobox. The AutoCompletSupport wants to mimic the firefox address field. But firefox does not autocomplete, it just pops up a popup with suggestions. I think a lot of complexity can be dropped when the combobox behaves in editable mode exactly as the firefox address bar. The problem with the actual behavior is IMO with backspace. Backspace does behave strangely in non-strict mode.

What is the reason for isTableCellEditor? Why must we handle comboboxes differently when used as TableCellEditor?

What do you think about all this?

Regards,

Tobias


Picon

AutoCompleteSupport

Hi,

I am in the process of refactoring AutoCompleteSupport for my needs. I want to make it so, that it does not alter the editable property of the JComboBox any more but instead in readonly mode behaves more like the language selector at https://gist.github.com/. In editable mode it will behave as in non-strict mode.

I will remove strict and beepOnStrictViolation and any code handling these, because these are not necessary any more.

hidesPopupOnFocusLost is not necessary IMHO, because it is just a workaround for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5100422. It just increases complexity and therefore I will drop it.

I want to drop any complexity from the editable combobox. The AutoCompletSupport wants to mimic the firefox address field. But firefox does not autocomplete, it just pops up a popup with suggestions. I think a lot of complexity can be dropped when the combobox behaves in editable mode exactly as the firefox address bar. The problem with the actual behavior is IMO with backspace. Backspace does behave strangely in non-strict mode.

What is the reason for isTableCellEditor? Why must we handle comboboxes differently when used as TableCellEditor?

What do you think about all this?

Regards,

Tobias

tobias.schulte | 29 Nov 14:47 2011
Picon

AutoCompleteSupport

Hi,

TextComponentMatcherEditor calls text.split("[ \t]") in refilter, when
mode == CONTAINS. 

In my opinion, AutoCompleteSupport should do the same in
applyFilter(String newFilter). 

With this changed, in non-strict mode I would be able to type "java 6"
in the AutoCompleteTestApp to find http://java.sun.com/javase/6/. 

A better case might be a dropdown box with customers (id, name,
surname, city). In a dialog you want the user to be able to select the
customer. The change would allow the user to type "name surname" or
"surname name" or "partial_id name" and find the customer.

What do you think,

Tobias

Holger Brands | 27 Nov 16:54 2011

modifying EventList from ListEventListener disallowed?

Hey guys,

just to confirm: is it true, that modifying the source list from an event listener is disallowed?
Consider the following example:
BasicEventList->SortedList->ReadonlyList

The listener on the ReadonlyList listens for an insert event and in turn deletes the first item from
the BasicEventList. While the list is of course modified, no delete event is fired:

    public void testModifyFromListener() throws Exception{
        final BasicEventList<String> unsortedList = new BasicEventList<String>();
        unsortedList.addAll(GlazedListsTests.stringToList("ABCDEFG"));
        unsortedList.addListEventListener(new ListEventListener<String>() {
            public void listChanged(ListEvent<String> listChanges) {
                System.err.println(Thread.currentThread() + ": UNSORTEDLIST=" + listChanges);
            }
        });
        final SortedList<String> sortedList = SortedList.create(unsortedList);
        sortedList.addListEventListener(new ListEventListener<String>() {
            public void listChanged(ListEvent<String> listChanges) {
                System.err.println(Thread.currentThread() + ": SORTEDLIST=" + listChanges);
            }
        });
       
        final EventList<String> readonlyList = GlazedLists.readOnlyList(sortedList);
        readonlyList.addListEventListener(new ListEventListener<String>() {
            public void listChanged(ListEvent<String> listChanges) {
                System.err.println(Thread.currentThread() + ": READONLYLIST=" + listChanges);
                while(listChanges.next()) {                       
                    // get the current change info
                    int index = listChanges.getIndex();
                    int changeType = listChanges.getType();

                    // on insert, do a delete
                    if(changeType == ListEvent.INSERT) {
                        listChanges.getSourceList().getReadWriteLock().writeLock().lock();
                        if (listChanges.getSourceList().get(index).equals("H")) {
                            System.err.println("MODIFYING unsortedList");
                            unsortedList.remove(0); //WILL NOT BE BROADCASTED!
                        }
                        listChanges.getSourceList().getReadWriteLock().writeLock().unlock();
                    }
                }
            }
        });
        unsortedList.getReadWriteLock().writeLock().lock();
        unsortedList.add("H");
        unsortedList.getReadWriteLock().writeLock().unlock();
        Thread.sleep(5000L);
        System.err.println("UNSORTEDLIST= " + unsortedList);
    }

Is this behavoiur expected?
I guess so, but would like to confirm it. Perhaps we should document this better?

Please see http://java.net/jira/browse/GLAZEDLISTS-531 for another example.

Thanks,
Holger




Gmane