Beefed up protege memory

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Beefed up protege memory

Nick Drummond
Hi All,

Apologies for cross posting. Odd to be asking a question.

Has anyone experimented with allocating extra memory to the JVM running
protege?
On windows, editing the Protege.lax file allows this (original values
commented out):

#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.INITIAL
#   -----------------------------------------
#   initial heap size

#lax.nl.java.option.java.heap.size.initial=10000000
lax.nl.java.option.java.heap.size.initial=200m


#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
#   -------------------------------------
#   maximum heap size

#lax.nl.java.option.java.heap.size.max=100000000
lax.nl.java.option.java.heap.size.max=400m

This appears to give a nice speed increase on my machine (running 1G
memory on a reasonable laptop)
I've had to do it for several "experiments", but don't generally for
everyday use.

Alternative question could be - has anyone experienced problems running
out of memory in Protege?

Nick

--

Nick Drummond

http://www.cs.man.ac.uk/~drummond/ <http://www.cs.man.ac.uk/%7Edrummond/>
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Beefed up protege memory

Jochem Liem
Dear Nick,

My first move after installing a new beta is editing the Protege.lax
file. I also know of another PhD-student, and a master student who do
the same.

We are all experiencing a significant speed increase and no problems
whatsoever.

--
lax.nl.java.option.java.heap.size.initial=100000000
lax.nl.java.option.java.heap.size.max=200000000
--

Best regards,
Jochem



Nick Drummond wrote:

> Hi All,
>
> Apologies for cross posting. Odd to be asking a question.
>
> Has anyone experimented with allocating extra memory to the JVM running
> protege?
> On windows, editing the Protege.lax file allows this (original values
> commented out):
>
> #   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.INITIAL
> #   -----------------------------------------
> #   initial heap size
>
> #lax.nl.java.option.java.heap.size.initial=10000000
> lax.nl.java.option.java.heap.size.initial=200m
>
>
> #   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
> #   -------------------------------------
> #   maximum heap size
>
> #lax.nl.java.option.java.heap.size.max=100000000
> lax.nl.java.option.java.heap.size.max=400m
>
> This appears to give a nice speed increase on my machine (running 1G
> memory on a reasonable laptop)
> I've had to do it for several "experiments", but don't generally for
> everyday use.
>
> Alternative question could be - has anyone experienced problems running
> out of memory in Protege?
>
> Nick
>

-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Beefed up protege memory

John Goodwin
In reply to this post by Nick Drummond
Thanks for those suggestions Nick.

I certainly have fun out of memory on Protégé many times unfortunately (likewise all other tools run out).

However the sort of ontologies I use have statements of the kind

A_1 -> p allValuesFrom (B_1....B_600ish)
...
A_500 -> p allValuesFrom (C_1....C_600ish)

So probably not surprising that this challenges Protégé a bit.

John


----------------------------------------------------------------------
Dr John Goodwin
Research Scientist
Research and Innovation
Ordnance Survey

Tel: (+44) 023 80730 5756
Fax: (+44) 023 8030 5072
email: [hidden email]
www.ordnancesurvey.co.uk/research

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Nick Drummond
Sent: 14 February 2006 12:49
To: [hidden email]; [hidden email]
Subject: [protege-owl] Beefed up protege memory

Hi All,

Apologies for cross posting. Odd to be asking a question.

Has anyone experimented with allocating extra memory to the JVM running protege?
On windows, editing the Protege.lax file allows this (original values commented out):

#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.INITIAL
#   -----------------------------------------
#   initial heap size

#lax.nl.java.option.java.heap.size.initial=10000000
lax.nl.java.option.java.heap.size.initial=200m


#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
#   -------------------------------------
#   maximum heap size

#lax.nl.java.option.java.heap.size.max=100000000
lax.nl.java.option.java.heap.size.max=400m

This appears to give a nice speed increase on my machine (running 1G memory on a reasonable laptop) I've had to do it for several "experiments", but don't generally for everyday use.

Alternative question could be - has anyone experienced problems running out of memory in Protege?

Nick

--

Nick Drummond

http://www.cs.man.ac.uk/~drummond/ <http://www.cs.man.ac.uk/%7Edrummond/>
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

.


This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person.

Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice.

Thank you for your cooperation.

Ordnance Survey
Romsey Road
Southampton SO16 4GU
Tel: 023 8079 2000
http://www.ordnancesurvey.co.uk

-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Beefed up protege memory

De Coronado, Sherri (NIH/NCI) [E]
In reply to this post by Nick Drummond
Yes, using NCI Thesaurus in database mode, we routinely have to increase
the heap size to avoid running out of memory.  It does speed it up
considerably as well, although it's certainly not lightening fast in
database mode.  I have increased max heap size to 700m on a machine with
2 Gig, but haven't tried increasing initial heap size.  Will try that as
well to see if it provides added benefits!  Thanks.

Sherri de Coronado
Enterprise Vocabulary Services
NCI Center for Bioinformatics

-----Original Message-----
From: Nick Drummond [mailto:[hidden email]]
Sent: Tuesday, February 14, 2006 7:49 AM
To: [hidden email]; [hidden email]
Subject: [protege-owl] Beefed up protege memory

Hi All,

Apologies for cross posting. Odd to be asking a question.

Has anyone experimented with allocating extra memory to the JVM running
protege?
On windows, editing the Protege.lax file allows this (original values
commented out):

#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.INITIAL
#   -----------------------------------------
#   initial heap size

#lax.nl.java.option.java.heap.size.initial=10000000
lax.nl.java.option.java.heap.size.initial=200m


#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
#   -------------------------------------
#   maximum heap size

#lax.nl.java.option.java.heap.size.max=100000000
lax.nl.java.option.java.heap.size.max=400m

This appears to give a nice speed increase on my machine (running 1G
memory on a reasonable laptop)
I've had to do it for several "experiments", but don't generally for
everyday use.

Alternative question could be - has anyone experienced problems running
out of memory in Protege?

Nick

--

Nick Drummond

http://www.cs.man.ac.uk/~drummond/
<http://www.cs.man.ac.uk/%7Edrummond/>
------------------------------------------------------------------------
-
To unsubscribe go to
http://protege.stanford.edu/community/subscribe.html
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Beefed up protege memory

Ronnie Valkky
In reply to this post by John Goodwin
Hi John and Nick,

Out of memory does happen sometimes, for example in Save/Save as,  side
effect being things such as 0kb=your lost your data.
Feedback to developers: it would save time if Protege installation did not
destroy the old Protege.lax !

I use the following setting which also allocate space for more threads in
java:
#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.INITIAL
#   -----------------------------------------
#   initial heap size 100mb = java parameter -Xms<size> = -Xms104857600
#   note: the bigger the heap, the less space for thread stacks (these are
*not* in the Java heap)
lax.nl.java.option.java.heap.size.initial=100m

#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
#   -------------------------------------
#   maximum heap size 256mb = java parameter -Xmx<size> = - Xmx26843456
lax.nl.java.option.java.heap.size.max=256m
#   LAX.NL.JAVA.OPTION.JAVA.THREAD.SIZE.INITIAL - not supported
#   -------------------------------------
#   initial heap size 256kb (default 64kb) = java parameter -Xss<size>
#   note: if -Xss is set to less than the minimum value, the minimum value
will be used automatically
#lax.nl.java.option.java.thread.size.initial=256k
#   LAX.NL.JAVA.OPTION.ADDITIONAL
#   -------------------------------------
#   initial heap for threads 256kb (default 64kb) = java parameter -Xss256k
lax.nl.java.option.additional=-Xss256k

cheers Ronnie
http://www.icewaves.com/0000/legal_email_waves.html

----- Original Message -----
From: "John Goodwin" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, February 14, 2006 6:24 PM
Subject: [protege-owl] Re: Beefed up protege memory


> Thanks for those suggestions Nick.
>
> I certainly have fun out of memory on Protégé many times unfortunately
(likewise all other tools run out).

>
> However the sort of ontologies I use have statements of the kind
>
> A_1 -> p allValuesFrom (B_1....B_600ish)
> ...
> A_500 -> p allValuesFrom (C_1....C_600ish)
>
> So probably not surprising that this challenges Protégé a bit.
>
> John
>
>
> ----------------------------------------------------------------------
> Dr John Goodwin
> Research Scientist
> Research and Innovation
> Ordnance Survey
>
> Tel: (+44) 023 80730 5756
> Fax: (+44) 023 8030 5072
> email: [hidden email]
> www.ordnancesurvey.co.uk/research
>
> -----Original Message-----
> From: [hidden email]
[mailto:[hidden email]] On Behalf Of Nick Drummond
> Sent: 14 February 2006 12:49
> To: [hidden email]; [hidden email]
> Subject: [protege-owl] Beefed up protege memory
>
> Hi All,
>
> Apologies for cross posting. Odd to be asking a question.
>
> Has anyone experimented with allocating extra memory to the JVM running
protege?
> On windows, editing the Protege.lax file allows this (original values
commented out):

>
> #   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.INITIAL
> #   -----------------------------------------
> #   initial heap size
>
> #lax.nl.java.option.java.heap.size.initial=10000000
> lax.nl.java.option.java.heap.size.initial=200m
>
>
> #   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
> #   -------------------------------------
> #   maximum heap size
>
> #lax.nl.java.option.java.heap.size.max=100000000
> lax.nl.java.option.java.heap.size.max=400m
>
> This appears to give a nice speed increase on my machine (running 1G
memory on a reasonable laptop) I've had to do it for several "experiments",
but don't generally for everyday use.
>
> Alternative question could be - has anyone experienced problems running
out of memory in Protege?

>
> Nick
>
> --
>
> Nick Drummond
>
> http://www.cs.man.ac.uk/~drummond/ <http://www.cs.man.ac.uk/%7Edrummond/>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
> .
>
>
> This email is only intended for the person to whom it is addressed and may
contain confidential information. If you have received this email in error,
please notify the sender and delete this email which must not be copied,
distributed or disclosed to any other person.
>
> Unless stated otherwise, the contents of this email are personal to the
writer and do not represent the official view of Ordnance Survey. Nor can
any contract be formed on Ordnance Survey's behalf via email. We reserve the
right to monitor emails and attachments without prior notice.

>
> Thank you for your cooperation.
>
> Ordnance Survey
> Romsey Road
> Southampton SO16 4GU
> Tel: 023 8079 2000
> http://www.ordnancesurvey.co.uk
>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Beefed up protege memory

Ronnie Valkky
In reply to this post by De Coronado, Sherri (NIH/NCI) [E]
Hi Sherry,

You can also try to tune:
#   LAX.NL.JAVA.OPTION.ADDITIONAL
#   -------------------------------------
#   initial heap for threads 256kb (default 64kb) = java parameter -Xss256k
lax.nl.java.option.additional=-Xss256k  <------------ tuning this affects
that

Note: the bigger the heap, the less space for thread stacks (these are *not*
in the Java heap)
lax.nl.java.option.java.heap.size.initial=100m <-------- that

Threading is a mechanism built in java to speed up java applications.

Above might help you depending on how threading has been utlized in Protege
OWL software.

cheers
Ronnie
http://www.icewaves.com/0000/legal_email_waves.html

----- Original Message -----
From: "De Coronado, Sherri (NIH/NCI) [E]" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, February 14, 2006 6:44 PM
Subject: [protege-owl] Re: Beefed up protege memory


> Yes, using NCI Thesaurus in database mode, we routinely have to increase
> the heap size to avoid running out of memory.  It does speed it up
> considerably as well, although it's certainly not lightening fast in
> database mode.  I have increased max heap size to 700m on a machine with
> 2 Gig, but haven't tried increasing initial heap size.  Will try that as
> well to see if it provides added benefits!  Thanks.
>
> Sherri de Coronado
> Enterprise Vocabulary Services
> NCI Center for Bioinformatics
>
> -----Original Message-----
> From: Nick Drummond [mailto:[hidden email]]
> Sent: Tuesday, February 14, 2006 7:49 AM
> To: [hidden email]; [hidden email]
> Subject: [protege-owl] Beefed up protege memory
>
> Hi All,
>
> Apologies for cross posting. Odd to be asking a question.
>
> Has anyone experimented with allocating extra memory to the JVM running
> protege?
> On windows, editing the Protege.lax file allows this (original values
> commented out):
>
> #   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.INITIAL
> #   -----------------------------------------
> #   initial heap size
>
> #lax.nl.java.option.java.heap.size.initial=10000000
> lax.nl.java.option.java.heap.size.initial=200m
>
>
> #   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
> #   -------------------------------------
> #   maximum heap size
>
> #lax.nl.java.option.java.heap.size.max=100000000
> lax.nl.java.option.java.heap.size.max=400m
>
> This appears to give a nice speed increase on my machine (running 1G
> memory on a reasonable laptop)
> I've had to do it for several "experiments", but don't generally for
> everyday use.
>
> Alternative question could be - has anyone experienced problems running
> out of memory in Protege?
>
> Nick
>
> --
>
> Nick Drummond
>
> http://www.cs.man.ac.uk/~drummond/
> <http://www.cs.man.ac.uk/%7Edrummond/>
> ------------------------------------------------------------------------
> -
> To unsubscribe go to
> http://protege.stanford.edu/community/subscribe.html
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Beefed up protege memory

Ronnie Valkky
In reply to this post by Jochem Liem
Hi Jochem,

We have used the following settings, which are near the ones you are using:
lax.nl.java.option.java.heap.size.initial=100m
lax.nl.java.option.java.heap.size.max=256m
lax.nl.java.option.additional=-Xss256k <-------- we increased also this
(default 64kb)

Have you tried the last one ?

Best reagrds
Ronnie
http://www.icewaves.com/0000/legal_email_waves.html

----- Original Message -----
From: "Jochem Liem" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, February 14, 2006 3:58 PM
Subject: [protege-owl] Re: Beefed up protege memory


> Dear Nick,
>
> My first move after installing a new beta is editing the Protege.lax
> file. I also know of another PhD-student, and a master student who do
> the same.
>
> We are all experiencing a significant speed increase and no problems
> whatsoever.
>
> --
> lax.nl.java.option.java.heap.size.initial=100000000
> lax.nl.java.option.java.heap.size.max=200000000
> --
>
> Best regards,
> Jochem
>
>
>
> Nick Drummond wrote:
> > Hi All,
> >
> > Apologies for cross posting. Odd to be asking a question.
> >
> > Has anyone experimented with allocating extra memory to the JVM running
> > protege?
> > On windows, editing the Protege.lax file allows this (original values
> > commented out):
> >
> > #   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.INITIAL
> > #   -----------------------------------------
> > #   initial heap size
> >
> > #lax.nl.java.option.java.heap.size.initial=10000000
> > lax.nl.java.option.java.heap.size.initial=200m
> >
> >
> > #   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
> > #   -------------------------------------
> > #   maximum heap size
> >
> > #lax.nl.java.option.java.heap.size.max=100000000
> > lax.nl.java.option.java.heap.size.max=400m
> >
> > This appears to give a nice speed increase on my machine (running 1G
> > memory on a reasonable laptop)
> > I've had to do it for several "experiments", but don't generally for
> > everyday use.
> >
> > Alternative question could be - has anyone experienced problems running
> > out of memory in Protege?
> >
> > Nick
> >
>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Beefed up protege memory

Jochem Liem
Dear Ronnie,

Thanks for the info.

Although far from a proper benchmark, I tried to compare the loading
times with different min-heap/max-heap/thread-heap sizes (3 runs). I
loaded a small ontology [1] with about 3500 triples with different settings.

                  (10mb/100mb/64k) (10mb/100mb/264k) (200mb/400mb/264k)
Triple loading         1980ms           1840ms             1760ms
Loading completed      2298ms           2150ms             2050ms

                  (200mb/400mb/64k)
Triple loading         1750ms
Loading completed      1980ms

The runs with a smaller threadheapsize somehow are a bit faster, but
this could be chance (although 2 further runs with 264k thread-heap gave
about the same results). The interface seems more responsive with more
memory, but there is no fast way to measure this.

Best regards,
Jochem

[1] http://staff.science.uva.nl/~jliem/ontologies/model.owl


Ronnie Valkky wrote:

> Hi Jochem,
>
> We have used the following settings, which are near the ones you are using:
> lax.nl.java.option.java.heap.size.initial=100m
> lax.nl.java.option.java.heap.size.max=256m
> lax.nl.java.option.additional=-Xss256k <-------- we increased also this
> (default 64kb)
>
> Have you tried the last one ?
>
> Best reagrds
> Ronnie
> http://www.icewaves.com/0000/legal_email_waves.html
>
> ----- Original Message -----
> From: "Jochem Liem" <[hidden email]>
> To: <[hidden email]>
> Sent: Tuesday, February 14, 2006 3:58 PM
> Subject: [protege-owl] Re: Beefed up protege memory
>
>
>
>>Dear Nick,
>>
>>My first move after installing a new beta is editing the Protege.lax
>>file. I also know of another PhD-student, and a master student who do
>>the same.
>>
>>We are all experiencing a significant speed increase and no problems
>>whatsoever.
>>
>>--
>>lax.nl.java.option.java.heap.size.initial=100000000
>>lax.nl.java.option.java.heap.size.max=200000000
>>--
>>
>>Best regards,
>>Jochem
>>
>>
>>
>>Nick Drummond wrote:
>>
>>>Hi All,
>>>
>>>Apologies for cross posting. Odd to be asking a question.
>>>
>>>Has anyone experimented with allocating extra memory to the JVM running
>>>protege?
>>>On windows, editing the Protege.lax file allows this (original values
>>>commented out):
>>>
>>>#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.INITIAL
>>>#   -----------------------------------------
>>>#   initial heap size
>>>
>>>#lax.nl.java.option.java.heap.size.initial=10000000
>>>lax.nl.java.option.java.heap.size.initial=200m
>>>
>>>
>>>#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
>>>#   -------------------------------------
>>>#   maximum heap size
>>>
>>>#lax.nl.java.option.java.heap.size.max=100000000
>>>lax.nl.java.option.java.heap.size.max=400m
>>>
>>>This appears to give a nice speed increase on my machine (running 1G
>>>memory on a reasonable laptop)
>>>I've had to do it for several "experiments", but don't generally for
>>>everyday use.
>>>
>>>Alternative question could be - has anyone experienced problems running
>>>out of memory in Protege?
>>>
>>>Nick
>>>
>>
>>-------------------------------------------------------------------------
>>To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>>
>>
>
>
>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>

-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Beefed up protege memory

Nick Drummond
In reply to this post by John Goodwin
John,

Are these closure statements? ie (B_1 or B_2 or... B600)
A number of the internal mechanisms in Protege (including creating
browser text) use recursion and this has caused me problems in the past.

Have you ever experienced a stack overflow?

I have had to bump up the stack size (I didn't do this in the lax file,
just on the command line - but I think you can use
lax.nl.java.option.java.heap.size.max=whatever)

Nick

John Goodwin wrote:

>Thanks for those suggestions Nick.
>
>I certainly have fun out of memory on Protégé many times unfortunately (likewise all other tools run out).
>
>However the sort of ontologies I use have statements of the kind
>
>A_1 -> p allValuesFrom (B_1....B_600ish)
>...
>A_500 -> p allValuesFrom (C_1....C_600ish)
>
>So probably not surprising that this challenges Protégé a bit.
>
>John
>
>
>----------------------------------------------------------------------
>Dr John Goodwin
>Research Scientist
>Research and Innovation
>Ordnance Survey
>
>Tel: (+44) 023 80730 5756
>Fax: (+44) 023 8030 5072
>email: [hidden email]
>www.ordnancesurvey.co.uk/research
>
>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On Behalf Of Nick Drummond
>Sent: 14 February 2006 12:49
>To: [hidden email]; [hidden email]
>Subject: [protege-owl] Beefed up protege memory
>
>Hi All,
>
>Apologies for cross posting. Odd to be asking a question.
>
>Has anyone experimented with allocating extra memory to the JVM running protege?
>On windows, editing the Protege.lax file allows this (original values commented out):
>
>#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.INITIAL
>#   -----------------------------------------
>#   initial heap size
>
>#lax.nl.java.option.java.heap.size.initial=10000000
>lax.nl.java.option.java.heap.size.initial=200m
>
>
>#   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
>#   -------------------------------------
>#   maximum heap size
>
>#lax.nl.java.option.java.heap.size.max=100000000
>lax.nl.java.option.java.heap.size.max=400m
>
>This appears to give a nice speed increase on my machine (running 1G memory on a reasonable laptop) I've had to do it for several "experiments", but don't generally for everyday use.
>
>Alternative question could be - has anyone experienced problems running out of memory in Protege?
>
>Nick
>
>  
>

--

Nick Drummond

http://www.cs.man.ac.uk/~drummond/ <http://www.cs.man.ac.uk/%7Edrummond/>
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Adding a class destroyed all classes and project

Ronnie Valkky
Hi,

Adding a new class to OWL model distroyed the whole project and owl file.
I use Protege OWL build 243. Does the following log file dump tell
developers anything ?

2006.02.15 15:48:04.390 EET FINE: Exception caught --
java.util.NoSuchElementException
 at
java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:367)
 at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:376)
 at
edu.stanford.smi.protegex.owl.ui.cls.ToggleSuperclassExplorerAction.getSelec
tedClass(ToggleSuperclassExplorerAction.java:79)
 at
edu.stanford.smi.protegex.owl.ui.cls.ToggleSuperclassExplorerAction.access$1
00(ToggleSuperclassExplorerAction.java:19)
 at
edu.stanford.smi.protegex.owl.ui.cls.ToggleSuperclassExplorerAction$1.select
ionChanged(ToggleSuperclassExplorerAction.java:38)
 at edu.stanford.smi.protege.util.SelectionEventDispatcher.postEvent(Unknown
Source)
 at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
Source)
 at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
Source)
 at
edu.stanford.smi.protege.util.SelectableContainer.notifySelectionListeners(U
nknown Source)
 at
edu.stanford.smi.protege.util.SelectableContainer$1.selectionChanged(Unknown
Source)
 at edu.stanford.smi.protege.util.SelectionEventDispatcher.postEvent(Unknown
Source)
 at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
Source)
 at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
Source)
 at
edu.stanford.smi.protege.util.SelectableContainer.notifySelectionListeners(U
nknown Source)
 at
edu.stanford.smi.protege.util.SelectableContainer$1.selectionChanged(Unknown
Source)
 at edu.stanford.smi.protege.util.SelectionEventDispatcher.postEvent(Unknown
Source)
 at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
Source)
 at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
Source)
 at
edu.stanford.smi.protege.util.SelectableTree.notifySelectionListeners(Unknow
n Source)
 at
edu.stanford.smi.protege.util.TreeSelectionListenerAdapter.valueChanged(Unkn
own Source)
 at javax.swing.JTree.fireValueChanged(JTree.java:2399)
 at javax.swing.JTree$TreeSelectionRedirector.valueChanged(JTree.java:2770)
 at
javax.swing.tree.DefaultTreeSelectionModel.fireValueChanged(DefaultTreeSelec
tionModel.java:629)
 at
javax.swing.tree.DefaultTreeSelectionModel.notifyPathChange(DefaultTreeSelec
tionModel.java:1078)
 at
javax.swing.tree.DefaultTreeSelectionModel.removeSelectionPaths(DefaultTreeS
electionModel.java:497)
 at javax.swing.JTree.removeDescendantSelectedPaths(JTree.java:3095)
 at javax.swing.JTree.removeDescendantSelectedPaths(JTree.java:3145)
 at javax.swing.JTree$TreeModelHandler.treeNodesRemoved(JTree.java:3229)
 at
javax.swing.tree.DefaultTreeModel.fireTreeNodesRemoved(DefaultTreeModel.java
:528)
 at
javax.swing.tree.DefaultTreeModel.nodesWereRemoved(DefaultTreeModel.java:308
)
 at
edu.stanford.smi.protege.util.LazyTreeRoot.notifyChildNodeRemoved(Unknown
Source)
 at
edu.stanford.smi.protege.util.LazyTreeNode.notifyChildNodeRemoved(Unknown
Source)
 at edu.stanford.smi.protege.util.LazyTreeNode.childRemoved(Unknown Source)
 at
edu.stanford.smi.protegex.owl.ui.cls.ClassTreeNode$1.directSubclassMoved(Cla
ssTreeNode.java:40)
 at
edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.dispatchCl
sEvent(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.dispatchEv
ent(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.dispatchEv
ents(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.dispatchEv
ents(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.dispatchEv
ents(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.moveDirect
Subclass(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.undo.MoveDirectSubclassCommand.doI
t(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.undo.UndoFrameStore.simpleCommandE
xecute(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.undo.UndoFrameStore.execute(Unknow
n Source)
 at
edu.stanford.smi.protege.model.framestore.undo.UndoFrameStore.moveDirectSubc
lass(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.ArgumentCheckingFrameStore.moveDir
ectSubclass(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.ChangeMonitorFrameStore.moveDirect
Subclass(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.FrameStoreAdapter.moveDirectSubcla
ss(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.FrameStoreAdapter.moveDirectSubcla
ss(Unknown Source)
 at
edu.stanford.smi.protege.model.framestore.FrameStoreAdapter.moveDirectSubcla
ss(Unknown Source)
 at
edu.stanford.smi.protege.model.DefaultKnowledgeBase.moveDirectSubclass(Unkno
wn Source)
 at
edu.stanford.smi.protege.model.DefaultKnowledgeBase.moveDirectSubclass(Unkno
wn Source)
 at edu.stanford.smi.protege.model.DefaultCls.moveDirectSubclass(Unknown
Source)
 at edu.stanford.smi.protege.ui.ClsesTreeTarget.dropCls(Unknown Source)
 at edu.stanford.smi.protege.ui.ClsesTreeTarget.doDrop(Unknown Source)
 at edu.stanford.smi.protege.util.TreeTarget.doDrop(Unknown Source)
 at edu.stanford.smi.protege.util.TreeTarget.drop(Unknown Source)
 at java.awt.dnd.DropTarget.drop(DropTarget.java:430)
 at
sun.awt.dnd.SunDropTargetContextPeer.processDropMessage(SunDropTargetContext
Peer.java:500)
 at
sun.awt.dnd.SunDropTargetContextPeer.access$800(SunDropTargetContextPeer.jav
a:53)
 at
sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchDropEvent(SunDr
opTargetContextPeer.java:812)
 at
sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchEvent(SunDropTa
rgetContextPeer.java:736)
 at sun.awt.dnd.SunDropTargetEvent.dispatch(SunDropTargetEvent.java:29)
 at java.awt.Component.dispatchEventImpl(Component.java:3826)
 at java.awt.Container.dispatchEventImpl(Container.java:2024)
 at java.awt.Component.dispatchEvent(Component.java:3803)
 at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
 at
java.awt.LightweightDispatcher.processDropTargetEvent(Container.java:3963)
 at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3817)
 at java.awt.Container.dispatchEventImpl(Container.java:2010)
 at java.awt.Window.dispatchEventImpl(Window.java:1774)
 at java.awt.Component.dispatchEvent(Component.java:3803)
 at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
 at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja
va:242)
 at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
:163)
 at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
 at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
 at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

2006.02.15 15:48:04.406 EET WARNING: java.lang.IllegalArgumentException:
path in TreePath must be non null and not empty.
 at javax.swing.tree.TreePath.<init>(TreePath.java:60)
 at edu.stanford.smi.protege.util.ComponentUtilities.setSelectedNode(Unknown
Source)
 at edu.stanford.smi.protege.ui.ClsesTreeTarget.dropCls(Unknown Source)
 at edu.stanford.smi.protege.ui.ClsesTreeTarget.doDrop(Unknown Source)
 at edu.stanford.smi.protege.util.TreeTarget.doDrop(Unknown Source)
 at edu.stanford.smi.protege.util.TreeTarget.drop(Unknown Source)
 at java.awt.dnd.DropTarget.drop(DropTarget.java:430)
 at
sun.awt.dnd.SunDropTargetContextPeer.processDropMessage(SunDropTargetContext
Peer.java:500)
 at
sun.awt.dnd.SunDropTargetContextPeer.access$800(SunDropTargetContextPeer.jav
a:53)
 at
sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchDropEvent(SunDr
opTargetContextPeer.java:812)
 at
sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchEvent(SunDropTa
rgetContextPeer.java:736)
 at sun.awt.dnd.SunDropTargetEvent.dispatch(SunDropTargetEvent.java:29)
 at java.awt.Component.dispatchEventImpl(Component.java:3826)
 at java.awt.Container.dispatchEventImpl(Container.java:2024)
 at java.awt.Component.dispatchEvent(Component.java:3803)
 at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
 at
java.awt.LightweightDispatcher.processDropTargetEvent(Container.java:3963)
 at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3817)
 at java.awt.Container.dispatchEventImpl(Container.java:2010)
 at java.awt.Window.dispatchEventImpl(Window.java:1774)
 at java.awt.Component.dispatchEvent(Component.java:3803)
 at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
 at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja
va:242)
 at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
:163)
 at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
 at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
 at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

Any ideas welcome.
Ronnie



-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Jamblaya properties were not built automatically

Ronnie Valkky
In reply to this post by Nick Drummond
Hi,

When creating a new project with Proteqe having Jamlaya tab,
it did not create the file x.pprjx__Jambalaya.properties
where x= project name. When opening the project later on the Protege OWL
console displayed,
that it could not open the above file.

Manually creating the file x.pprjx__Jambalaya.properties to the right folder
with just a comment line:
#--- Jambalaya, x  Project Properties ---
helped to solve the problem.

However, this might be confusing to some users ?

cheers,
Ronnie


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Jamblaya properties were not built automatically

Nick Drummond
Ronnie,

Thanks, I've CCed your message to the Jambalaya people.
Am I right in assuming this is just a warning and it doesn't affect your
project?

Nick

Ronnie Valkky wrote:

>Hi,
>
>When creating a new project with Proteqe having Jamlaya tab,
>it did not create the file x.pprjx__Jambalaya.properties
>where x= project name. When opening the project later on the Protege OWL
>console displayed,
>that it could not open the above file.
>
>Manually creating the file x.pprjx__Jambalaya.properties to the right folder
>with just a comment line:
>#--- Jambalaya, x  Project Properties ---
>helped to solve the problem.
>
>However, this might be confusing to some users ?
>
>cheers,
>Ronnie
>
>
>-------------------------------------------------------------------------
>To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>
>  
>

--

Nick Drummond

http://www.cs.man.ac.uk/~drummond/ <http://www.cs.man.ac.uk/%7Edrummond/>
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Adding a class destroyed all classes and project

Nick Drummond
In reply to this post by Ronnie Valkky
Ronnie,

I'm sorry to hear about that.
Thanks for the stack trace - I'll add it to the bugtracker and
investigate as soon as possible.

Nick

Ronnie Valkky wrote:

>Hi,
>
>Adding a new class to OWL model distroyed the whole project and owl file.
>I use Protege OWL build 243. Does the following log file dump tell
>developers anything ?
>
>2006.02.15 15:48:04.390 EET FINE: Exception caught --
>java.util.NoSuchElementException
> at
>java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:367)
> at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:376)
> at
>edu.stanford.smi.protegex.owl.ui.cls.ToggleSuperclassExplorerAction.getSelec
>tedClass(ToggleSuperclassExplorerAction.java:79)
> at
>edu.stanford.smi.protegex.owl.ui.cls.ToggleSuperclassExplorerAction.access$1
>00(ToggleSuperclassExplorerAction.java:19)
> at
>edu.stanford.smi.protegex.owl.ui.cls.ToggleSuperclassExplorerAction$1.select
>ionChanged(ToggleSuperclassExplorerAction.java:38)
> at edu.stanford.smi.protege.util.SelectionEventDispatcher.postEvent(Unknown
>Source)
> at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
>Source)
> at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
>Source)
> at
>edu.stanford.smi.protege.util.SelectableContainer.notifySelectionListeners(U
>nknown Source)
> at
>edu.stanford.smi.protege.util.SelectableContainer$1.selectionChanged(Unknown
>Source)
> at edu.stanford.smi.protege.util.SelectionEventDispatcher.postEvent(Unknown
>Source)
> at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
>Source)
> at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
>Source)
> at
>edu.stanford.smi.protege.util.SelectableContainer.notifySelectionListeners(U
>nknown Source)
> at
>edu.stanford.smi.protege.util.SelectableContainer$1.selectionChanged(Unknown
>Source)
> at edu.stanford.smi.protege.util.SelectionEventDispatcher.postEvent(Unknown
>Source)
> at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
>Source)
> at edu.stanford.smi.protege.util.ListenerCollection.postEvent(Unknown
>Source)
> at
>edu.stanford.smi.protege.util.SelectableTree.notifySelectionListeners(Unknow
>n Source)
> at
>edu.stanford.smi.protege.util.TreeSelectionListenerAdapter.valueChanged(Unkn
>own Source)
> at javax.swing.JTree.fireValueChanged(JTree.java:2399)
> at javax.swing.JTree$TreeSelectionRedirector.valueChanged(JTree.java:2770)
> at
>javax.swing.tree.DefaultTreeSelectionModel.fireValueChanged(DefaultTreeSelec
>tionModel.java:629)
> at
>javax.swing.tree.DefaultTreeSelectionModel.notifyPathChange(DefaultTreeSelec
>tionModel.java:1078)
> at
>javax.swing.tree.DefaultTreeSelectionModel.removeSelectionPaths(DefaultTreeS
>electionModel.java:497)
> at javax.swing.JTree.removeDescendantSelectedPaths(JTree.java:3095)
> at javax.swing.JTree.removeDescendantSelectedPaths(JTree.java:3145)
> at javax.swing.JTree$TreeModelHandler.treeNodesRemoved(JTree.java:3229)
> at
>javax.swing.tree.DefaultTreeModel.fireTreeNodesRemoved(DefaultTreeModel.java
>:528)
> at
>javax.swing.tree.DefaultTreeModel.nodesWereRemoved(DefaultTreeModel.java:308
>)
> at
>edu.stanford.smi.protege.util.LazyTreeRoot.notifyChildNodeRemoved(Unknown
>Source)
> at
>edu.stanford.smi.protege.util.LazyTreeNode.notifyChildNodeRemoved(Unknown
>Source)
> at edu.stanford.smi.protege.util.LazyTreeNode.childRemoved(Unknown Source)
> at
>edu.stanford.smi.protegex.owl.ui.cls.ClassTreeNode$1.directSubclassMoved(Cla
>ssTreeNode.java:40)
> at
>edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.dispatchCl
>sEvent(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.dispatchEv
>ent(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.dispatchEv
>ents(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.dispatchEv
>ents(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.dispatchEv
>ents(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.EventDispatchFrameStore.moveDirect
>Subclass(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.undo.MoveDirectSubclassCommand.doI
>t(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.undo.UndoFrameStore.simpleCommandE
>xecute(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.undo.UndoFrameStore.execute(Unknow
>n Source)
> at
>edu.stanford.smi.protege.model.framestore.undo.UndoFrameStore.moveDirectSubc
>lass(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.ArgumentCheckingFrameStore.moveDir
>ectSubclass(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.ChangeMonitorFrameStore.moveDirect
>Subclass(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.FrameStoreAdapter.moveDirectSubcla
>ss(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.FrameStoreAdapter.moveDirectSubcla
>ss(Unknown Source)
> at
>edu.stanford.smi.protege.model.framestore.FrameStoreAdapter.moveDirectSubcla
>ss(Unknown Source)
> at
>edu.stanford.smi.protege.model.DefaultKnowledgeBase.moveDirectSubclass(Unkno
>wn Source)
> at
>edu.stanford.smi.protege.model.DefaultKnowledgeBase.moveDirectSubclass(Unkno
>wn Source)
> at edu.stanford.smi.protege.model.DefaultCls.moveDirectSubclass(Unknown
>Source)
> at edu.stanford.smi.protege.ui.ClsesTreeTarget.dropCls(Unknown Source)
> at edu.stanford.smi.protege.ui.ClsesTreeTarget.doDrop(Unknown Source)
> at edu.stanford.smi.protege.util.TreeTarget.doDrop(Unknown Source)
> at edu.stanford.smi.protege.util.TreeTarget.drop(Unknown Source)
> at java.awt.dnd.DropTarget.drop(DropTarget.java:430)
> at
>sun.awt.dnd.SunDropTargetContextPeer.processDropMessage(SunDropTargetContext
>Peer.java:500)
> at
>sun.awt.dnd.SunDropTargetContextPeer.access$800(SunDropTargetContextPeer.jav
>a:53)
> at
>sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchDropEvent(SunDr
>opTargetContextPeer.java:812)
> at
>sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchEvent(SunDropTa
>rgetContextPeer.java:736)
> at sun.awt.dnd.SunDropTargetEvent.dispatch(SunDropTargetEvent.java:29)
> at java.awt.Component.dispatchEventImpl(Component.java:3826)
> at java.awt.Container.dispatchEventImpl(Container.java:2024)
> at java.awt.Component.dispatchEvent(Component.java:3803)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
> at
>java.awt.LightweightDispatcher.processDropTargetEvent(Container.java:3963)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3817)
> at java.awt.Container.dispatchEventImpl(Container.java:2010)
> at java.awt.Window.dispatchEventImpl(Window.java:1774)
> at java.awt.Component.dispatchEvent(Component.java:3803)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
> at
>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja
>va:242)
> at
>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
>:163)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
>
>2006.02.15 15:48:04.406 EET WARNING: java.lang.IllegalArgumentException:
>path in TreePath must be non null and not empty.
> at javax.swing.tree.TreePath.<init>(TreePath.java:60)
> at edu.stanford.smi.protege.util.ComponentUtilities.setSelectedNode(Unknown
>Source)
> at edu.stanford.smi.protege.ui.ClsesTreeTarget.dropCls(Unknown Source)
> at edu.stanford.smi.protege.ui.ClsesTreeTarget.doDrop(Unknown Source)
> at edu.stanford.smi.protege.util.TreeTarget.doDrop(Unknown Source)
> at edu.stanford.smi.protege.util.TreeTarget.drop(Unknown Source)
> at java.awt.dnd.DropTarget.drop(DropTarget.java:430)
> at
>sun.awt.dnd.SunDropTargetContextPeer.processDropMessage(SunDropTargetContext
>Peer.java:500)
> at
>sun.awt.dnd.SunDropTargetContextPeer.access$800(SunDropTargetContextPeer.jav
>a:53)
> at
>sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchDropEvent(SunDr
>opTargetContextPeer.java:812)
> at
>sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchEvent(SunDropTa
>rgetContextPeer.java:736)
> at sun.awt.dnd.SunDropTargetEvent.dispatch(SunDropTargetEvent.java:29)
> at java.awt.Component.dispatchEventImpl(Component.java:3826)
> at java.awt.Container.dispatchEventImpl(Container.java:2024)
> at java.awt.Component.dispatchEvent(Component.java:3803)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
> at
>java.awt.LightweightDispatcher.processDropTargetEvent(Container.java:3963)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3817)
> at java.awt.Container.dispatchEventImpl(Container.java:2010)
> at java.awt.Window.dispatchEventImpl(Window.java:1774)
> at java.awt.Component.dispatchEvent(Component.java:3803)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
> at
>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja
>va:242)
> at
>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
>:163)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
>
>Any ideas welcome.
>Ronnie
>
>
>
>-------------------------------------------------------------------------
>To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>
>  
>

--

Nick Drummond

http://www.cs.man.ac.uk/~drummond/ <http://www.cs.man.ac.uk/%7Edrummond/>
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Jamblaya properties were not built automatically

Ronnie Valkky
In reply to this post by Nick Drummond
Hi Nick,

It was just a minor surprise and didn't affect our project.

Jambalaya guys as well as you have done great products,  these are just
minor things.

cheers,
Ronnie

----- Original Message -----
From: "Nick Drummond" <[hidden email]>
To: <[hidden email]>
Cc: <[hidden email]>
Sent: Thursday, February 16, 2006 3:30 PM
Subject: [protege-owl] Re: Jamblaya properties were not built automatically


> Ronnie,
>
> Thanks, I've CCed your message to the Jambalaya people.
> Am I right in assuming this is just a warning and it doesn't affect your
> project?
>
> Nick
>
> Ronnie Valkky wrote:
>
> >Hi,
> >
> >When creating a new project with Proteqe having Jamlaya tab,
> >it did not create the file x.pprjx__Jambalaya.properties
> >where x= project name. When opening the project later on the Protege OWL
> >console displayed,
> >that it could not open the above file.
> >
> >Manually creating the file x.pprjx__Jambalaya.properties to the right
folder

> >with just a comment line:
> >#--- Jambalaya, x  Project Properties ---
> >helped to solve the problem.
> >
> >However, this might be confusing to some users ?
> >
> >cheers,
> >Ronnie
> >
> >
> >-------------------------------------------------------------------------
> >To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
> >
> >
> >
> >
>
> --
>
> Nick Drummond
>
> http://www.cs.man.ac.uk/~drummond/ <http://www.cs.man.ac.uk/%7Edrummond/>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Jamblaya properties were not built automatically

Chris Callendar
In reply to this post by Nick Drummond
Hi Nick & Ronnnie,

Thanks for bringing this to my attention.  
I agree that it is unnecessary to display that warning.  I've
changed it so that if the properties file doesn't exist, it
is now created and no warning is printed.
 
Chris Callendar
The Chisel Group
University of Victoria, Canada
http://www.thechiselgroup.org/
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Nick Drummond
> Sent: February 16, 2006 5:30 AM
> To: [hidden email]
> Cc: [hidden email]
> Subject: [protege-owl] Re: Jamblaya properties were not built
> automatically
>
> Ronnie,
>
> Thanks, I've CCed your message to the Jambalaya people.
> Am I right in assuming this is just a warning and it doesn't
> affect your project?
>
> Nick
>
> Ronnie Valkky wrote:
>
> >Hi,
> >
> >When creating a new project with Proteqe having Jamlaya tab,
> it did not
> >create the file x.pprjx__Jambalaya.properties where x= project name.
> >When opening the project later on the Protege OWL console displayed,
> >that it could not open the above file.
> >
> >Manually creating the file x.pprjx__Jambalaya.properties to
> the right
> >folder with just a comment line:
> >#--- Jambalaya, x  Project Properties --- helped to solve
> the problem.
> >
> >However, this might be confusing to some users ?
> >
> >cheers,
> >Ronnie
> >
> >
> >-------------------------------------------------------------
> ----------
> >-- To unsubscribe go to
> >http://protege.stanford.edu/community/subscribe.html
> >
> >
> >  
> >
>
> --
>
> Nick Drummond
>
> http://www.cs.man.ac.uk/~drummond/ 
> <http://www.cs.man.ac.uk/%7Edrummond/>
> --------------------------------------------------------------
> -----------
> To unsubscribe go to
> http://protege.stanford.edu/community/subscribe.html
>
>
>


-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html

Reply | Threaded
Open this post in threaded view
|

Re: Beefed up protege memory

Nick Drummond
In reply to this post by Jochem Liem
Does anyone mind if I start a protege wiki page on optimising Protege,
that could include this info?

And, you know other (obvious?) hints like removing unneccessary plugins etc.

Nick

Jochem Liem wrote:

> Dear Ronnie,
>
> Thanks for the info.
>
> Although far from a proper benchmark, I tried to compare the loading
> times with different min-heap/max-heap/thread-heap sizes (3 runs). I
> loaded a small ontology [1] with about 3500 triples with different
> settings.
>
>                  (10mb/100mb/64k) (10mb/100mb/264k) (200mb/400mb/264k)
> Triple loading         1980ms           1840ms             1760ms
> Loading completed      2298ms           2150ms             2050ms
>
>                  (200mb/400mb/64k)
> Triple loading         1750ms
> Loading completed      1980ms
>
> The runs with a smaller threadheapsize somehow are a bit faster, but
> this could be chance (although 2 further runs with 264k thread-heap
> gave about the same results). The interface seems more responsive with
> more memory, but there is no fast way to measure this.
>
> Best regards,
> Jochem
>
> [1] http://staff.science.uva.nl/~jliem/ontologies/model.owl
>
>
> Ronnie Valkky wrote:
>
>> Hi Jochem,
>>
>> We have used the following settings, which are near the ones you are
>> using:
>> lax.nl.java.option.java.heap.size.initial=100m
>> lax.nl.java.option.java.heap.size.max=256m
>> lax.nl.java.option.additional=-Xss256k <-------- we increased also this
>> (default 64kb)
>>
>> Have you tried the last one ?
>>
>> Best reagrds
>> Ronnie
>> http://www.icewaves.com/0000/legal_email_waves.html
>>
>> ----- Original Message -----
>> From: "Jochem Liem" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Tuesday, February 14, 2006 3:58 PM
>> Subject: [protege-owl] Re: Beefed up protege memory
>>
>>
>>
>>> Dear Nick,
>>>
>>> My first move after installing a new beta is editing the Protege.lax
>>> file. I also know of another PhD-student, and a master student who do
>>> the same.
>>>
>>> We are all experiencing a significant speed increase and no problems
>>> whatsoever.
>>>
>>> --
>>> lax.nl.java.option.java.heap.size.initial=100000000
>>> lax.nl.java.option.java.heap.size.max=200000000
>>> --
>>>
>>> Best regards,
>>> Jochem
>>>
>>>
>>>
>>> Nick Drummond wrote:
>>>
>>>> Hi All,
>>>>
>>>> Apologies for cross posting. Odd to be asking a question.
>>>>
>>>> Has anyone experimented with allocating extra memory to the JVM
>>>> running
>>>> protege?
>>>> On windows, editing the Protege.lax file allows this (original values
>>>> commented out):
>>>>
>>>> #   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.INITIAL
>>>> #   -----------------------------------------
>>>> #   initial heap size
>>>>
>>>> #lax.nl.java.option.java.heap.size.initial=10000000
>>>> lax.nl.java.option.java.heap.size.initial=200m
>>>>
>>>>
>>>> #   LAX.NL.JAVA.OPTION.JAVA.HEAP.SIZE.MAX
>>>> #   -------------------------------------
>>>> #   maximum heap size
>>>>
>>>> #lax.nl.java.option.java.heap.size.max=100000000
>>>> lax.nl.java.option.java.heap.size.max=400m
>>>>
>>>> This appears to give a nice speed increase on my machine (running 1G
>>>> memory on a reasonable laptop)
>>>> I've had to do it for several "experiments", but don't generally for
>>>> everyday use.
>>>>
>>>> Alternative question could be - has anyone experienced problems
>>>> running
>>>> out of memory in Protege?
>>>>
>>>> Nick
>>>>
>>>
>>> -------------------------------------------------------------------------
>>>
>>> To unsubscribe go to
>>> http://protege.stanford.edu/community/subscribe.html
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------------------------
>>
>> To unsubscribe go to
>> http://protege.stanford.edu/community/subscribe.html
>>
>
> -------------------------------------------------------------------------
> To unsubscribe go to http://protege.stanford.edu/community/subscribe.html
>
>

--

Nick Drummond

http://www.cs.man.ac.uk/~drummond/ <http://www.cs.man.ac.uk/%7Edrummond/>
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html