Re: [basex-talk] Problem with module-import via relative / absolute path (WEBPATH, REST-Interface)

[Christian Grün]

Hi Günter,

You’ll have to move your module to the correct sub-directory [1]:

  URL: http://kleist-digital.de/ns/kleist
  File location: /Applications/basex/repo/de/kleist-digital/ns/kleist.xqm

Hope this helps
Christian

[1] http://docs.basex.org/wiki/Repository#URI_Rewriting



On Fri, Apr 1, 2016 at 9:55 PM, kleist-digital  wrote:
> Hi Christian,
>
> thanks for the tipp. I tried, but get the message "Module not found: 
> http://kleist-digital.de/ns/kleist“
>
> The working solution with absolute path is:
> import module namespace kleist = "http://kleist-digital.de/ns/kleist; at 
> "file:///Users/gdunzwolff/Documents/kleist/BaseXWeb/modules/kleist-functions.xqm“;
>
> My RepoPath is:
> REPOPATH = /Applications/basex/repo
>
> The module is now in Applications/basex/repo and is called 
> kleist-functions.xqm.
> In the module importing file the header is:
> import module namespace kleist = "http://kleist-digital.de/ns/kleist“;
>
> With http://localhost/rest?run=xqs/list_ba_flyer.xq I get
> Module not found: http://kleist-digital.de/ns/kleist. There is no more ask 
> for kleist-functions.xqm.
>
> How do I have to name the module in repo, so that it will be found. Or do I 
> have to change the import-statement?
>
> Günter
>
>> Am 01.04.2016 um 17:58 schrieb Christian Grün :
>>
>> Hi Günter,
>>
>> You may be generally better off moving all your modules to the repo
>> directory. This way, there will be no need anymore to specify the
>> module location. Did you already think about it?
>>
>> Christian
>>
>>
>> On Fri, Apr 1, 2016 at 12:26 PM, Günter Dunz-Wolff
>>  wrote:
>>> Hi all,
>>>
>>> in my queries I have to import module namespace, for example in the file 
>>> test.xq something like
>>> import module namespace kleist = "http://kleist-digital.de/ns/kleist; at 
>>> "../modules/kleist-functions.xqm";
>>>
>>> I'm calling the query via REST like
>>> http://localhost/rest?run=xqs/test.xq
>>>
>>> The webpath is configured like
>>> # HTTP Services
>>> WEBPATH = /Users/xxx/Documents/kleist/BaseXWeb
>>> RESTPATH =
>>>
>>> When I'm using the absolute path, everything works fine:
>>> import module namespace kleist = "http://kleist-digital.de/ns/kleist; at 
>>> "file:///Users/xxx/Documents/kleist/BaseXWeb/modules/kleist-functions.xqm";
>>>
>>> When I'm using the relative path for importing the module namespace like
>>> import module namespace kleist = "http://kleist-digital.de/ns/kleist; at 
>>> "../modules/kleist-functions.xqm";
>>> I'll get the following error:
>>> "Could not retrieve module: /Users/modules/kleist-functions.xqm"
>>> The correct address should be: 
>>> Users/xxx/Documents/kleist/BaseXWeb/modules/kleist-functions.xqm
>>>
>>> What's wrong in my configuration? Btw, I need the relative path for 
>>> portability to my remote server.
>>>
>>> Any help would be great, thanks a lot,
>>> Best regards, Günter
>>
>
>

Re: [basex-talk] Problem with module-import via relative / absolute path (WEBPATH, REST-Interface)

[Andy Bunce]

Ignoring the repo..
I can replicate this with the default config

If I create webapp/test.xq with just
static-base-uri()
then
/rest?rest?run=test.xq returns the expected

file:///C:/Program%20Files%20(x86)/BaseX/webapp/test.xq

If I change the module to
import module namespace df = 'ns' at "another.xqm";
static-base-uri()

Stopped at ., 2/1:
[XQST0059] Could not retrieve module: C:/Program Files
(x86)/basex/bin/another.xqm.

Suggesting it maybe resolving against the working directory?

/Andy

On 1 April 2016 at 20:55, kleist-digital  wrote:

> Hi Christian,
>
> thanks for the tipp. I tried, but get the message "Module not found:
> http://kleist-digital.de/ns/kleist“
>
> The working solution with absolute path is:
> import module namespace kleist = "http://kleist-digital.de/ns/kleist; at
> "file:///Users/gdunzwolff/Documents/kleist/BaseXWeb/modules/kleist-functions.xqm“;
>
> My RepoPath is:
> REPOPATH = /Applications/basex/repo
>
> The module is now in Applications/basex/repo and is called
> kleist-functions.xqm.
> In the module importing file the header is:
> import module namespace kleist = "http://kleist-digital.de/ns/kleist“;
>
> With http://localhost/rest?run=xqs/list_ba_flyer.xq I get
> Module not found: http://kleist-digital.de/ns/kleist. There is no more
> ask for kleist-functions.xqm.
>
> How do I have to name the module in repo, so that it will be found. Or do
> I have to change the import-statement?
>
> Günter
>
> > Am 01.04.2016 um 17:58 schrieb Christian Grün  >:
> >
> > Hi Günter,
> >
> > You may be generally better off moving all your modules to the repo
> > directory. This way, there will be no need anymore to specify the
> > module location. Did you already think about it?
> >
> > Christian
> >
> >
> > On Fri, Apr 1, 2016 at 12:26 PM, Günter Dunz-Wolff
> >  wrote:
> >> Hi all,
> >>
> >> in my queries I have to import module namespace, for example in the
> file test.xq something like
> >> import module namespace kleist = "http://kleist-digital.de/ns/kleist;
> at "../modules/kleist-functions.xqm";
> >>
> >> I'm calling the query via REST like
> >> http://localhost/rest?run=xqs/test.xq
> >>
> >> The webpath is configured like
> >> # HTTP Services
> >> WEBPATH = /Users/xxx/Documents/kleist/BaseXWeb
> >> RESTPATH =
> >>
> >> When I'm using the absolute path, everything works fine:
> >> import module namespace kleist = "http://kleist-digital.de/ns/kleist;
> at
> "file:///Users/xxx/Documents/kleist/BaseXWeb/modules/kleist-functions.xqm";
> >>
> >> When I'm using the relative path for importing the module namespace like
> >> import module namespace kleist = "http://kleist-digital.de/ns/kleist;
> at "../modules/kleist-functions.xqm";
> >> I'll get the following error:
> >> "Could not retrieve module: /Users/modules/kleist-functions.xqm"
> >> The correct address should be:
> Users/xxx/Documents/kleist/BaseXWeb/modules/kleist-functions.xqm
> >>
> >> What's wrong in my configuration? Btw, I need the relative path for
> portability to my remote server.
> >>
> >> Any help would be great, thanks a lot,
> >> Best regards, Günter
> >
>
>
>

Re: [basex-talk] Problem with module-import via relative / absolute path (WEBPATH, REST-Interface)

[kleist-digital]

Hi Christian,

thanks for the tipp. I tried, but get the message "Module not found: 
http://kleist-digital.de/ns/kleist“

The working solution with absolute path is:
import module namespace kleist = "http://kleist-digital.de/ns/kleist; at 
"file:///Users/gdunzwolff/Documents/kleist/BaseXWeb/modules/kleist-functions.xqm“;

My RepoPath is:
REPOPATH = /Applications/basex/repo

The module is now in Applications/basex/repo and is called kleist-functions.xqm.
In the module importing file the header is: 
import module namespace kleist = "http://kleist-digital.de/ns/kleist“;

With http://localhost/rest?run=xqs/list_ba_flyer.xq I get
Module not found: http://kleist-digital.de/ns/kleist. There is no more ask for 
kleist-functions.xqm.

How do I have to name the module in repo, so that it will be found. Or do I 
have to change the import-statement?

Günter

> Am 01.04.2016 um 17:58 schrieb Christian Grün :
> 
> Hi Günter,
> 
> You may be generally better off moving all your modules to the repo
> directory. This way, there will be no need anymore to specify the
> module location. Did you already think about it?
> 
> Christian
> 
> 
> On Fri, Apr 1, 2016 at 12:26 PM, Günter Dunz-Wolff
>  wrote:
>> Hi all,
>> 
>> in my queries I have to import module namespace, for example in the file 
>> test.xq something like
>> import module namespace kleist = "http://kleist-digital.de/ns/kleist; at 
>> "../modules/kleist-functions.xqm";
>> 
>> I'm calling the query via REST like
>> http://localhost/rest?run=xqs/test.xq
>> 
>> The webpath is configured like
>> # HTTP Services
>> WEBPATH = /Users/xxx/Documents/kleist/BaseXWeb
>> RESTPATH =
>> 
>> When I'm using the absolute path, everything works fine:
>> import module namespace kleist = "http://kleist-digital.de/ns/kleist; at 
>> "file:///Users/xxx/Documents/kleist/BaseXWeb/modules/kleist-functions.xqm";
>> 
>> When I'm using the relative path for importing the module namespace like
>> import module namespace kleist = "http://kleist-digital.de/ns/kleist; at 
>> "../modules/kleist-functions.xqm";
>> I'll get the following error:
>> "Could not retrieve module: /Users/modules/kleist-functions.xqm"
>> The correct address should be: 
>> Users/xxx/Documents/kleist/BaseXWeb/modules/kleist-functions.xqm
>> 
>> What's wrong in my configuration? Btw, I need the relative path for 
>> portability to my remote server.
>> 
>> Any help would be great, thanks a lot,
>> Best regards, Günter
> 

Re: [basex-talk] Expected behaviour with full disk

[Christian Grün]

Hi James,

I’m sorry, there is general solution for that on database level; if a
disk is full, basically anything can be happen.

However, as you are using RESTXQ, you could check memory via XQuery:

  declare namespace file = 'java:java.io.File';
  let $free := file:getFreeSpace(file:new('/'))
  return if($free < 1) then
error((), "Less than 100 MB left on disk") else
( (: continue :) )

This way, you can also decide what is going to happen if the disk runs
out of space (raise an error? send an e-mail? etc.). By the way,
raising an error will probably be the most elegant solution, as you
can catch the error via %rest:error and do some more things [1].

Hope this helps,
Christian

[1] http://docs.basex.org/wiki/RESTXQ#Error_Handling



On Fri, Apr 1, 2016 at 4:48 PM, James Ball  wrote:
> Hello,
>
> I’m having some problems with BaseX in situations where there it runs out of
> disk space.
>
> I’m delivering XML files to BaseX 8.4 using RestXQ.
>
> A request is made and the XML is added to a database depending on some
> criteria. I receive many hundreds of thousands of requests and everything
> works well unless I run out of disk space.
>
> What I would expect to happen is that BaseX would try to add the document,
> find it couldn’t due to the disk being full and return a server error (e.g.
> 500) and the transaction would be aborted leaving the database as it was
> before the request. Any further requests would all get errors returned.
>
> What I’m seeing is that when a request is made that causes the disk to
> become full BaseX gets part way through adding the document, fails and
> returns an error but also leaves the database corrupted. Usually the server
> has to be restarted and then any database that has been affected has to be
> deleted - it’s rare to be able to save anything from it.
>
> The errors vary but it is usually a NullPointer exception and then
> java.nio.channels.OverlappingFileLockException. for further requests.
>
> I’ve tried turning off logging and setting parallel to 1 to see if that made
> any difference but it doesn’t.
>
> Is what I’m seeing unique to my setup or do others see this?
>
> Is there anything I can do to make BaseX just stop accepting requests when
> disk space runs out to protect my databases?
>
> Many thanks, James

Re: [basex-talk] Matching multiple names across a list of sequences of names

[Christian Grün]

Hi Graydon,

Do you think there’d be a chance for us to get a minimized,
self-contained example, which demonstrates the n^2 solution?

Thanks  in advance,
Christian



On Fri, Apr 1, 2016 at 5:24 PM, Graydon Saunders  wrote:
> Hello -
>
> I've got a problem I'm not sure how to best approach.
>
> I've got triplets of names -- class.operation.specifier -- that I need to
> match against much longer sequences of names. (Which are in attributes in an
> XML hierarchy; each sequence of names derives from a path to a leaf
> element.)
>
> If there is a match (as there usually is not) one of the names in the
> sequence of names will match to the class, a subsequent name to the
> operation,  and a name subsequent to that match to the specifier. (All
> simple string values.)
>
> The naive n^2 version is much too slow for the amount of data involved.
>
> Is there an efficient way to do this kind of matching?
>
> Thanks!
> Graydon

Re: [basex-talk] Problem with module-import via relative / absolute path (WEBPATH, REST-Interface)

[Christian Grün]

Hi Günter,

You may be generally better off moving all your modules to the repo
directory. This way, there will be no need anymore to specify the
module location. Did you already think about it?

Christian


On Fri, Apr 1, 2016 at 12:26 PM, Günter Dunz-Wolff
 wrote:
> Hi all,
>
> in my queries I have to import module namespace, for example in the file 
> test.xq something like
> import module namespace kleist = "http://kleist-digital.de/ns/kleist; at 
> "../modules/kleist-functions.xqm";
>
> I'm calling the query via REST like
> http://localhost/rest?run=xqs/test.xq
>
> The webpath is configured like
> # HTTP Services
> WEBPATH = /Users/xxx/Documents/kleist/BaseXWeb
> RESTPATH =
>
> When I'm using the absolute path, everything works fine:
> import module namespace kleist = "http://kleist-digital.de/ns/kleist; at 
> "file:///Users/xxx/Documents/kleist/BaseXWeb/modules/kleist-functions.xqm";
>
> When I'm using the relative path for importing the module namespace like
> import module namespace kleist = "http://kleist-digital.de/ns/kleist; at 
> "../modules/kleist-functions.xqm";
> I'll get the following error:
> "Could not retrieve module: /Users/modules/kleist-functions.xqm"
> The correct address should be: 
> Users/xxx/Documents/kleist/BaseXWeb/modules/kleist-functions.xqm
>
> What's wrong in my configuration? Btw, I need the relative path for 
> portability to my remote server.
>
> Any help would be great, thanks a lot,
> Best regards, Günter

Re: [basex-talk] Expected behaviour with full disk

[Etanchaud Fabrice]

Hello James,

Did you try to set ADDCACHE ?
This way you might run out of disk space during disk caching, before database 
corruption occurs.
Be careful, you may have to serialize the XML in order to use this option with 
db:add/db:replace (I read you are in the REST-XQ layer).

Otherwise, the only way to prevent database corruption might be to check disk 
size regularly and reject new data by program…

http://docs.basex.org/wiki/Options#ADDCACHE
http://docs.basex.org/wiki/Database_Module#db:add


Best regards,
Fabrice Etanchaud
Horanet Smart Objects
FR-85200 Fontenay le Comte

De : basex-talk-boun...@mailman.uni-konstanz.de 
[mailto:basex-talk-boun...@mailman.uni-konstanz.de] De la part de James Ball
Envoyé : vendredi 1 avril 2016 16:48
À : BaseX 
Objet : [basex-talk] Expected behaviour with full disk

Hello,

I’m having some problems with BaseX in situations where there it runs out of 
disk space.

I’m delivering XML files to BaseX 8.4 using RestXQ.

A request is made and the XML is added to a database depending on some 
criteria. I receive many hundreds of thousands of requests and everything works 
well unless I run out of disk space.
J
What I would expect to happen is that BaseX would try to add the document, find 
it couldn’t due to the disk being full and return a server error (e.g. 500) and 
the transaction would be aborted leaving the database as it was before the 
request. Any further requests would all get errors returned.

What I’m seeing is that when a request is made that causes the disk to become 
full BaseX gets part way through adding the document, fails and returns an 
error but also leaves the database corrupted. Usually the server has to be 
restarted and then any database that has been affected has to be deleted - it’s 
rare to be able to save anything from it.

The errors vary but it is usually a NullPointer exception and then 
java.nio.channels.OverlappingFileLockException. for further requests.

I’ve tried turning off logging and setting parallel to 1 to see if that made 
any difference but it doesn’t.

Is what I’m seeing unique to my setup or do others see this?

Is there anything I can do to make BaseX just stop accepting requests when disk 
space runs out to protect my databases?

Many thanks, James

[basex-talk] Matching multiple names across a list of sequences of names

[Graydon Saunders]

Hello -

I've got a problem I'm not sure how to best approach.

I've got triplets of names -- class.operation.specifier -- that I need to
match against much longer sequences of names. (Which are in attributes in
an XML hierarchy; each sequence of names derives from a path to a leaf
element.)

If there is a match (as there usually is not) one of the names in the
sequence of names will match to the class, a subsequent name to the
operation,  and a name subsequent to that match to the specifier. (All
simple string values.)

The naive n^2 version is much too slow for the amount of data involved.

Is there an efficient way to do this kind of matching?

Thanks!
Graydon

Re: [basex-talk] Expected behaviour with full disk

[Strasser Pablo]

Hi,
On 01. 04. 16 16:48, James Ball wrote:


Is what I’m seeing unique to my setup or do others see this?

I have seen exactly the same behaviour in case of network  hard drive 
loosing connection causing the Kernel to make the filesystem read only. 
However, I don't really expect BaseX to manage this kind of case 
contrary to disk full situation.


Pablo

Re: [basex-talk] slow GUI-editor when using package-manager eXPath

[Rob Stapper]

I see the processor working like crazy (100%) but it doesn't affect the GUI 
accepting characters from the keyboard. Good job.

-Oorspronkelijk bericht-
Van: Christian Grün [mailto:christian.gr...@gmail.com] 
Verzonden: vrijdag 1 april 2016 15:47
Aan: Rob Stapper
CC: BaseX
Onderwerp: Re: [basex-talk] slow GUI-editor when using package-manager eXPath

Hi Rob,

I think I’ve found a solution that does justice to both older and newer 
systems: query parsing will now be generally delayed for some ms), and only one 
query parsing process will be active at the same time (before, every key click 
triggered an extra thread).

Even if you have switched to another mechanism now, could you give it a try [1]?

Looking forward to your feedback,
Christian

[1] http://files.basex.org/releases/latest


On Fri, Apr 1, 2016 at 3:11 PM, Rob Stapper  wrote:
> Hi Christian,
>
> Thanx for having a closer look at it.
>
> I have already abandoned the ex-path package mechanism, it just was to slow 
> to work with on my computer.
> Now I can type away once again. Once in a while my computer has to take a 
> breath, probably updating the project files, and I'll have to wait for a 
> second, but this doesn't bother me.
> The problem with the ex-path mechanism was that I had to wait with every 
> keystroke.
> It looks to me that the timing-mechanism when using of ex-path is different 
> than without using ex-path.
>
> So if you can do something about the timing, just like you proposed below, I 
> could again use ex-path.
>
> In the meanwhile I've been thinking about reorganizing my modules.
> Maybe it would be good practice if each package is accessed by just 
> one interface module which addresses the other modules through a 
> relative path. I haven't tested this
>
> Let me know if you have figured something out, I'll be happy to test it for 
> you.
>
> Take care,
> Rob
>
> -Oorspronkelijk bericht-
> Van: Christian Grün [mailto:christian.gr...@gmail.com]
> Verzonden: vrijdag 1 april 2016 14:06
> Aan: Rob Stapper
> CC: BaseX
> Onderwerp: Re: [basex-talk] slow GUI-editor when using package-manager 
> eXPath
>
> Hi Rob,
>
> I managed to play around with BaseX on an older machine (Celeron, 1.3 GHz, 
> 224 MB RAM), and I was surprised to see it worked pretty well.
> Maybe it was due to Windows XP, though, and the fact that it was a fresh 
> installation.
>
> I had a closer look at the files you sent to me, and the most noticeable 
> delays I noticed happened when editing an XQuery file with numerous module 
> imports. The reason for that is that all the imported modules need to be 
> parsed with each key click.
>
> Spontaneously, I got two ideas how this could be improved:
>
> * XQuery parsing could be delayed for some milliseconds. This way, it would 
> only be parsed if a user has (presumably) finished his input.
>
> * An obsolete query parsing thread could be stopped before a new parsing 
> thread is started.
>
> * The least thrilling solution: A new option in the Preferences dialog to 
> disable realtime parsing, and only parse if a file is saved.
>
> I’ll see what can be done.
>
> Cheers,
> Christian
>
>
>
> On Thu, Mar 10, 2016 at 9:45 AM, Rob Stapper  wrote:
>> Hi Christian,
>>
>> New tools, new challenges.
>>
>> I’ve rearranged my source-code in packages/libraries conform the 
>> eXPath-specs in BaseX now.
>>
>> But since than the GUI-editor is becoming very slow, even unworkably slow.
>>
>> What is causing this and can you give me any tips how speed up the 
>> GUI-editor?
>>
>>
>>
>> I’ve got 7 libraries now. The one with the largest interface counts 
>> 11 entries in file:expath-pkg.xml, all public entries, the smallest 
>> library counts one entry.
>>
>>
>>
>> TIA,
>>
>> Rob
>

[basex-talk] Expected behaviour with full disk

[James Ball]

Hello,

I’m having some problems with BaseX in situations where there it runs out of 
disk space.

I’m delivering XML files to BaseX 8.4 using RestXQ.

A request is made and the XML is added to a database depending on some 
criteria. I receive many hundreds of thousands of requests and everything works 
well unless I run out of disk space.

What I would expect to happen is that BaseX would try to add the document, find 
it couldn’t due to the disk being full and return a server error (e.g. 500) and 
the transaction would be aborted leaving the database as it was before the 
request. Any further requests would all get errors returned.

What I’m seeing is that when a request is made that causes the disk to become 
full BaseX gets part way through adding the document, fails and returns an 
error but also leaves the database corrupted. Usually the server has to be 
restarted and then any database that has been affected has to be deleted - it’s 
rare to be able to save anything from it.

The errors vary but it is usually a NullPointer exception and then 
java.nio.channels.OverlappingFileLockException. for further requests.  

I’ve tried turning off logging and setting parallel to 1 to see if that made 
any difference but it doesn’t.

Is what I’m seeing unique to my setup or do others see this?

Is there anything I can do to make BaseX just stop accepting requests when disk 
space runs out to protect my databases?

Many thanks, James

Re: [basex-talk] slow GUI-editor when using package-manager eXPath

[Rob Stapper]

Hi Christian,

Absolutely brilliant, no hick-ups what so ever. Double-checked it.

Have a goof weekend,
Rob


-Oorspronkelijk bericht-
Van: Christian Grün [mailto:christian.gr...@gmail.com] 
Verzonden: vrijdag 1 april 2016 15:47
Aan: Rob Stapper
CC: BaseX
Onderwerp: Re: [basex-talk] slow GUI-editor when using package-manager eXPath

Hi Rob,

I think I’ve found a solution that does justice to both older and newer 
systems: query parsing will now be generally delayed for some ms), and only one 
query parsing process will be active at the same time (before, every key click 
triggered an extra thread).

Even if you have switched to another mechanism now, could you give it a try [1]?

Looking forward to your feedback,
Christian

[1] http://files.basex.org/releases/latest


On Fri, Apr 1, 2016 at 3:11 PM, Rob Stapper  wrote:
> Hi Christian,
>
> Thanx for having a closer look at it.
>
> I have already abandoned the ex-path package mechanism, it just was to slow 
> to work with on my computer.
> Now I can type away once again. Once in a while my computer has to take a 
> breath, probably updating the project files, and I'll have to wait for a 
> second, but this doesn't bother me.
> The problem with the ex-path mechanism was that I had to wait with every 
> keystroke.
> It looks to me that the timing-mechanism when using of ex-path is different 
> than without using ex-path.
>
> So if you can do something about the timing, just like you proposed below, I 
> could again use ex-path.
>
> In the meanwhile I've been thinking about reorganizing my modules.
> Maybe it would be good practice if each package is accessed by just 
> one interface module which addresses the other modules through a 
> relative path. I haven't tested this
>
> Let me know if you have figured something out, I'll be happy to test it for 
> you.
>
> Take care,
> Rob
>
> -Oorspronkelijk bericht-
> Van: Christian Grün [mailto:christian.gr...@gmail.com]
> Verzonden: vrijdag 1 april 2016 14:06
> Aan: Rob Stapper
> CC: BaseX
> Onderwerp: Re: [basex-talk] slow GUI-editor when using package-manager 
> eXPath
>
> Hi Rob,
>
> I managed to play around with BaseX on an older machine (Celeron, 1.3 GHz, 
> 224 MB RAM), and I was surprised to see it worked pretty well.
> Maybe it was due to Windows XP, though, and the fact that it was a fresh 
> installation.
>
> I had a closer look at the files you sent to me, and the most noticeable 
> delays I noticed happened when editing an XQuery file with numerous module 
> imports. The reason for that is that all the imported modules need to be 
> parsed with each key click.
>
> Spontaneously, I got two ideas how this could be improved:
>
> * XQuery parsing could be delayed for some milliseconds. This way, it would 
> only be parsed if a user has (presumably) finished his input.
>
> * An obsolete query parsing thread could be stopped before a new parsing 
> thread is started.
>
> * The least thrilling solution: A new option in the Preferences dialog to 
> disable realtime parsing, and only parse if a file is saved.
>
> I’ll see what can be done.
>
> Cheers,
> Christian
>
>
>
> On Thu, Mar 10, 2016 at 9:45 AM, Rob Stapper  wrote:
>> Hi Christian,
>>
>> New tools, new challenges.
>>
>> I’ve rearranged my source-code in packages/libraries conform the 
>> eXPath-specs in BaseX now.
>>
>> But since than the GUI-editor is becoming very slow, even unworkably slow.
>>
>> What is causing this and can you give me any tips how speed up the 
>> GUI-editor?
>>
>>
>>
>> I’ve got 7 libraries now. The one with the largest interface counts 
>> 11 entries in file:expath-pkg.xml, all public entries, the smallest 
>> library counts one entry.
>>
>>
>>
>> TIA,
>>
>> Rob
>

Re: [basex-talk] slow GUI-editor when using package-manager eXPath

[Christian Grün]

Hi Rob,

I think I’ve found a solution that does justice to both older and
newer systems: query parsing will now be generally delayed for some
ms), and only one query parsing process will be active at the same
time (before, every key click triggered an extra thread).

Even if you have switched to another mechanism now, could you give it a try [1]?

Looking forward to your feedback,
Christian

[1] http://files.basex.org/releases/latest


On Fri, Apr 1, 2016 at 3:11 PM, Rob Stapper  wrote:
> Hi Christian,
>
> Thanx for having a closer look at it.
>
> I have already abandoned the ex-path package mechanism, it just was to slow 
> to work with on my computer.
> Now I can type away once again. Once in a while my computer has to take a 
> breath, probably updating the project files, and I'll have to wait for a 
> second, but this doesn't bother me.
> The problem with the ex-path mechanism was that I had to wait with every 
> keystroke.
> It looks to me that the timing-mechanism when using of ex-path is different 
> than without using ex-path.
>
> So if you can do something about the timing, just like you proposed below, I 
> could again use ex-path.
>
> In the meanwhile I've been thinking about reorganizing my modules.
> Maybe it would be good practice if each package is accessed by just one 
> interface module which addresses the other modules through a relative path. I 
> haven't tested this
>
> Let me know if you have figured something out, I'll be happy to test it for 
> you.
>
> Take care,
> Rob
>
> -Oorspronkelijk bericht-
> Van: Christian Grün [mailto:christian.gr...@gmail.com]
> Verzonden: vrijdag 1 april 2016 14:06
> Aan: Rob Stapper
> CC: BaseX
> Onderwerp: Re: [basex-talk] slow GUI-editor when using package-manager eXPath
>
> Hi Rob,
>
> I managed to play around with BaseX on an older machine (Celeron, 1.3 GHz, 
> 224 MB RAM), and I was surprised to see it worked pretty well.
> Maybe it was due to Windows XP, though, and the fact that it was a fresh 
> installation.
>
> I had a closer look at the files you sent to me, and the most noticeable 
> delays I noticed happened when editing an XQuery file with numerous module 
> imports. The reason for that is that all the imported modules need to be 
> parsed with each key click.
>
> Spontaneously, I got two ideas how this could be improved:
>
> * XQuery parsing could be delayed for some milliseconds. This way, it would 
> only be parsed if a user has (presumably) finished his input.
>
> * An obsolete query parsing thread could be stopped before a new parsing 
> thread is started.
>
> * The least thrilling solution: A new option in the Preferences dialog to 
> disable realtime parsing, and only parse if a file is saved.
>
> I’ll see what can be done.
>
> Cheers,
> Christian
>
>
>
> On Thu, Mar 10, 2016 at 9:45 AM, Rob Stapper  wrote:
>> Hi Christian,
>>
>> New tools, new challenges.
>>
>> I’ve rearranged my source-code in packages/libraries conform the
>> eXPath-specs in BaseX now.
>>
>> But since than the GUI-editor is becoming very slow, even unworkably slow.
>>
>> What is causing this and can you give me any tips how speed up the
>> GUI-editor?
>>
>>
>>
>> I’ve got 7 libraries now. The one with the largest interface counts 11
>> entries in file:expath-pkg.xml, all public entries, the smallest
>> library counts one entry.
>>
>>
>>
>> TIA,
>>
>> Rob
>

Re: [basex-talk] slow GUI-editor when using package-manager eXPath

[Rob Stapper]

Hi Christian,

Thanx for having a closer look at it.

I have already abandoned the ex-path package mechanism, it just was to slow to 
work with on my computer.
Now I can type away once again. Once in a while my computer has to take a 
breath, probably updating the project files, and I'll have to wait for a 
second, but this doesn't bother me. 
The problem with the ex-path mechanism was that I had to wait with every 
keystroke.
It looks to me that the timing-mechanism when using of ex-path is different 
than without using ex-path.

So if you can do something about the timing, just like you proposed below, I 
could again use ex-path.

In the meanwhile I've been thinking about reorganizing my modules.
Maybe it would be good practice if each package is accessed by just one 
interface module which addresses the other modules through a relative path. I 
haven't tested this 

Let me know if you have figured something out, I'll be happy to test it for you.

Take care,
Rob

-Oorspronkelijk bericht-
Van: Christian Grün [mailto:christian.gr...@gmail.com] 
Verzonden: vrijdag 1 april 2016 14:06
Aan: Rob Stapper
CC: BaseX
Onderwerp: Re: [basex-talk] slow GUI-editor when using package-manager eXPath

Hi Rob,

I managed to play around with BaseX on an older machine (Celeron, 1.3 GHz, 224 
MB RAM), and I was surprised to see it worked pretty well.
Maybe it was due to Windows XP, though, and the fact that it was a fresh 
installation.

I had a closer look at the files you sent to me, and the most noticeable delays 
I noticed happened when editing an XQuery file with numerous module imports. 
The reason for that is that all the imported modules need to be parsed with 
each key click.

Spontaneously, I got two ideas how this could be improved:

* XQuery parsing could be delayed for some milliseconds. This way, it would 
only be parsed if a user has (presumably) finished his input.

* An obsolete query parsing thread could be stopped before a new parsing thread 
is started.

* The least thrilling solution: A new option in the Preferences dialog to 
disable realtime parsing, and only parse if a file is saved.

I’ll see what can be done.

Cheers,
Christian



On Thu, Mar 10, 2016 at 9:45 AM, Rob Stapper  wrote:
> Hi Christian,
>
> New tools, new challenges.
>
> I’ve rearranged my source-code in packages/libraries conform the 
> eXPath-specs in BaseX now.
>
> But since than the GUI-editor is becoming very slow, even unworkably slow.
>
> What is causing this and can you give me any tips how speed up the 
> GUI-editor?
>
>
>
> I’ve got 7 libraries now. The one with the largest interface counts 11 
> entries in file:expath-pkg.xml, all public entries, the smallest 
> library counts one entry.
>
>
>
> TIA,
>
> Rob

Re: [basex-talk] slow GUI-editor when using package-manager eXPath

[Christian Grün]

Hi Rob,

I managed to play around with BaseX on an older machine (Celeron, 1.3
GHz, 224 MB RAM), and I was surprised to see it worked pretty well.
Maybe it was due to Windows XP, though, and the fact that it was a
fresh installation.

I had a closer look at the files you sent to me, and the most
noticeable delays I noticed happened when editing an XQuery file with
numerous module imports. The reason for that is that all the imported
modules need to be parsed with each key click.

Spontaneously, I got two ideas how this could be improved:

* XQuery parsing could be delayed for some milliseconds. This way, it
would only be parsed if a user has (presumably) finished his input.

* An obsolete query parsing thread could be stopped before a new
parsing thread is started.

* The least thrilling solution: A new option in the Preferences dialog
to disable realtime parsing, and only parse if a file is saved.

I’ll see what can be done.

Cheers,
Christian



On Thu, Mar 10, 2016 at 9:45 AM, Rob Stapper  wrote:
> Hi Christian,
>
> New tools, new challenges.
>
> I’ve rearranged my source-code in packages/libraries conform the
> eXPath-specs in BaseX now.
>
> But since than the GUI-editor is becoming very slow, even unworkably slow.
>
> What is causing this and can you give me any tips how speed up the
> GUI-editor?
>
>
>
> I’ve got 7 libraries now. The one with the largest interface counts 11
> entries in file:expath-pkg.xml, all public entries, the smallest library
> counts one entry.
>
>
>
> TIA,
>
> Rob