Menu
▾
▴
exist-development — eXist Developer's List
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(22) |
Nov
(85) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(47) |
Feb
(127) |
Mar
(268) |
Apr
(78) |
May
(47) |
Jun
(38) |
Jul
(131) |
Aug
(221) |
Sep
(187) |
Oct
(54) |
Nov
(111) |
Dec
(84) |
| 2011 |
Jan
(152) |
Feb
(106) |
Mar
(94) |
Apr
(90) |
May
(53) |
Jun
(20) |
Jul
(24) |
Aug
(37) |
Sep
(32) |
Oct
(70) |
Nov
(22) |
Dec
(15) |
| 2012 |
Jan
(33) |
Feb
(110) |
Mar
(24) |
Apr
(1) |
May
(11) |
Jun
(8) |
Jul
(12) |
Aug
(37) |
Sep
(39) |
Oct
(81) |
Nov
(38) |
Dec
(50) |
| 2013 |
Jan
(23) |
Feb
(53) |
Mar
(23) |
Apr
(5) |
May
(19) |
Jun
(16) |
Jul
(16) |
Aug
(9) |
Sep
(21) |
Oct
(1) |
Nov
(2) |
Dec
(8) |
| 2014 |
Jan
(16) |
Feb
(6) |
Mar
(27) |
Apr
(1) |
May
(10) |
Jun
(1) |
Jul
(4) |
Aug
(10) |
Sep
(19) |
Oct
(22) |
Nov
(4) |
Dec
(6) |
| 2015 |
Jan
(3) |
Feb
(6) |
Mar
(9) |
Apr
|
May
(11) |
Jun
(23) |
Jul
(14) |
Aug
(10) |
Sep
(10) |
Oct
(9) |
Nov
(18) |
Dec
(4) |
| 2016 |
Jan
(5) |
Feb
(5) |
Mar
|
Apr
(2) |
May
(15) |
Jun
(2) |
Jul
(8) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(2) |
Feb
(12) |
Mar
(22) |
Apr
(6) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(3) |
Aug
|
Sep
(7) |
Oct
(19) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Evgeny G. <gaz...@gm...> - 2010-09-02 14:00:23
|
hello!
next abstract code:
declare function local:eval($p){
for $x in $p return
typeswitch($x)
case $c as element(a01) return local:eval($c/node())
case $c as element(a02) return local:eval($c/node())
case $c as element(a03) return local:eval($c/node())
case $c as element(a04) return local:eval($c/node())
case $c as element(a05) return local:eval($c/node())
case $c as element(a06) return local:eval($c/node())
default return $x
};
local:eval(<x/>)
evaluating at 10-18ms
if number of cases is 7 then ~40ms, if 8 then ~250ms,
9 cases are evaluating ~2500ms
10 - ~28000ms
11 - ~360000ms
...and etc
without recursions all work very quickly even for some thousands cases.
But if you see the recursion is not called in example above.
Any ideas?
--
Evgeny
|
|
From: Evgeny G. <gaz...@gm...> - 2010-09-02 13:25:24
|
Like I have another problem. New problem with typeswitch -- Evgeny |
|
From: Adam R. <ad...@ex...> - 2010-09-02 13:23:46
|
No there is a branch, where I started refactoring and splitting out module concerns from the XQueryContext to cope with this. It is pretty good, but it now fails one test that previously passed. I could really do with some help on this, as I got stuck and could not see why this test passes in trunk but not in my branch, if you want to take a look - The test that fails is - testCircularImports. The branch is - http://exist.svn.sourceforge.net/svnroot/exist/branches/adam/context-cleanup3/ On 2 September 2010 13:34, Evgeny Gazdovsky <gaz...@gm...> wrote: > Hi! > Is module import promlem solved? > Like I have one in current trunk > -- > Evgeny > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Jason S. <js...@in...> - 2010-09-02 13:12:39
|
Adam, Wolfgang is correct. The locking mechanism needed (useful) is tied to the database design. In some designs, you don't need locks at all. The current eXist design allows live writes (mutation), so you need locking to limit access. The actual locking mechanism, however, could change significantly based on the underlying database implementation. -----Original Message----- From: Wolfgang Meier [mailto:wol...@ex...] Sent: Thursday, September 02, 2010 6:43 AM To: Adam Retter Cc: Jason Smith; Paul Ryan; eXist development; Michael J. Pelikan; Todd Gochenour Subject: Re: [Exist-development] [Exist-open] Performance of concurrent read queries. > Is there not a whole class of lock free concurrent algorithms though? As I said many times before: you cannot see locking in isolation. It is tightly connected with transaction management, caching, log sequence numbers, checkpoints and other concepts. Any change to locking has to take all those other aspects into account. Wolfgang |
|
From: Jason S. <js...@in...> - 2010-09-02 13:01:35
|
When a deadlock occurs, the part of the code that is responsible for starting and controlling the transaction must catch the deadlock exception, rollback to the previous state, and restart the operation. One thread in the deadlock proceeds, the other thread in the deadlock must yield and restart. Currently, eXist is not fully transactional, so there are conditions on restarting. From: pet...@go... [mailto:pet...@go...] On Behalf Of Peter Crowther Sent: Thursday, September 02, 2010 6:18 AM To: Jason Smith Cc: eXist development Subject: Re: [Exist-development] [Exist-open] Performance of concurrent read queries. On 1 September 2010 18:09, Jason Smith <js...@in...<mailto:js...@in...>> wrote: Other databases do have high concurrency. I don't know about XML databases though. I've worked with one in particular that is commercial. It has a collection-based locking model, and it throws deadlock errors occasionally. When this happens, you rollback and start over. I think I just had an allergic reaction to a pronoun :-). Let's just take the pronoun out of that paragraph and be clear about what we're talking about here. In particular, what is "you"? In order to be able to start over, "you" must be able to roll back to a point that is well-defined. This generally requires transaction boundaries to be controllable from "you"; if not, "you" cannot determine the point from which to start over. In general, the only sensible "you" for this purpose is the calling application. Does eXist have transaction boundaries that are controllable from the calling application? If not, what other values of "you" might make sense for this approach? - Peter |
|
From: Wolfgang M. <wol...@ex...> - 2010-09-02 12:43:31
|
> Is there not a whole class of lock free concurrent algorithms though? As I said many times before: you cannot see locking in isolation. It is tightly connected with transaction management, caching, log sequence numbers, checkpoints and other concepts. Any change to locking has to take all those other aspects into account. Wolfgang |
|
From: Wolfgang M. <wol...@ex...> - 2010-09-02 12:41:04
|
> Does eXist have transaction boundaries that are controllable from the > calling application? If not, what other values of "you" might make sense > for this approach? If we decouple resources from the collection, it would actually become much easier to make transactions user-controllable and support full rollbacks. The redo/undo methods are already there, but due to how indexes are designed, we cannot use them except for recovery. The proposed redesign would make this all much simpler. Wolfgang |
|
From: Evgeny G. <gaz...@gm...> - 2010-09-02 12:34:37
|
Hi! Is module import promlem solved? Like I have one in current trunk -- Evgeny |
|
From: Evgeny G. <gaz...@gm...> - 2010-09-02 12:27:51
|
During restoring data from users.xml diggest password is not coping into account. Where just stored the link between account and groups? -- Evgeny |
|
From: Peter C. <pet...@me...> - 2010-09-02 12:18:01
|
On 1 September 2010 18:09, Jason Smith <js...@in...> wrote: > Other databases do have high concurrency. I don't know about XML databases > though. I've worked with one in particular that is commercial. It has a > collection-based locking model, and it throws deadlock errors occasionally. > When this happens, you rollback and start over. > > I think I just had an allergic reaction to a pronoun :-). Let's just take the pronoun out of that paragraph and be clear about what we're talking about here. In particular, what is "you"? In order to be able to start over, "you" must be able to roll back to a point that is well-defined. This generally requires transaction boundaries to be controllable from "you"; if not, "you" cannot determine the point from which to start over. In general, the only sensible "you" for this purpose is the calling application. Does eXist have transaction boundaries that are controllable from the calling application? If not, what other values of "you" might make sense for this approach? - Peter |
|
From: Adam R. <ad...@ex...> - 2010-09-02 11:23:38
|
On 1 September 2010 18:09, Jason Smith <js...@in...> wrote:
> If used from the front-end APIs, eXist does not deadlock on typical XQueries. I'm not sure what you mean by "collections are always ordered the same" though. I can reference fn:collection("...") in multiple places in a single XPath, and these are not guaranteed to execute in the same order from one XQuery to the next. Fn:collection("...") must acquire a collection lock at some point, correct?
>
> Also, keep in mind that deadlock detection in eXist is currently broken, and I don't think it can be fixed. I'm working on a write-up.
>
> Other databases do have high concurrency. I don't know about XML databases though. I've worked with one in particular that is commercial. It has a collection-based locking model, and it throws deadlock errors occasionally. When this happens, you rollback and start over. And this other database appears to have some concurrency limitations as well, just from some of the testing we've done (very preliminary).
>
> So this is what is driving the conversation - how do we get to granular, concurrent access without killing ourselves with deadlocking? A small number of intention locks is manageable. Too few results in limited concurrency. Too many results in a really difficult deadlock problem (detection is expensive). Any solution that does not need locking at all should get CAREFUL consideration!!! :-) IMHO
Is there not a whole class of lock free concurrent algorithms though?
For example CAS (Compare and Swap) is available in Java I believe. I
know that Scala exploit this for their parallel programming
constructs.
http://en.wikipedia.org/wiki/Compare-and-swap
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/package-summary.html
>
>
>
>
>
> -----Original Message-----
> From: Wolfgang Meier [mailto:wol...@ex...]
> Sent: Wednesday, September 01, 2010 9:24 AM
> To: Jason Smith
> Cc: Adam Retter; Paul Ryan; eXist development; Michael J. Pelikan; Todd Gochenour
> Subject: Re: [Exist-development] [Exist-open] Performance of concurrent read queries.
>
>> The problem with deadlocks (the one I ran into) doesn't actually have anything to do with
>> the collection hierarchy. They are simply caused by taking two locks out of order.
>
> Seems we need a bunch of low-level test cases first (there are some
> higher level tests I used to debug similar issues). Sure, thread T1
> can take a lock on doc A, then doc B, while thread T2 locks B then A
> (see XQuery below). This case should indeed be handled by the deadlock
> detection. However, in most cases eXist does take locks in order (due
> to the fact that collections are always ordered the same).
>
>> If I understand this correctly, the new design will need to manage, potentially, hundreds
>> of thousands of locks that can be taken in arbitrary order.
>
> Most traditional databases use an even finer granularity (single
> pages, records, tuples). The new design would in no way be different
> from the current situation. The query optimizer can effectively limit
> the number of resources to be locked. I'm convinced that investing
> time into improving the optimizer is the best way to achieve quick
> improvements.
>
> By redesigning the storage backend, you can increase performance by
> 50% or maybe 70% if things go well. Improvements to the query
> optimizer often result in performance wins up to 500% and more. I just
> did it again for some full text queries (not committed yet).
>
>> 2) If you have more than one lock, guarantee that all locks are taken in the same order every time.
>
> Given the possibilities of XQuery, this is going to be difficult to
> guarantee,e.g.:
>
> let $doc := request:get-parameter("doc", ())
> let $a := doc($doc)/root
> let $b := doc($doc//link/@href/string())
> return
> (: do something, even read-only, with $a and $b :)
>
> Since $b is determined by querying $a, you don't know in advance where
> it will point to. If there's a circular link between $a and $b, you
> deadlock. Allowing dirty reads helps a bit here.
>
>> 3) Don't use locking at all. Use a scheme that avoids the need for locking.
>
> There are (relational) databases which avoid locking, e.g. by using a
> shadow page concept on low-level storage and make the transaction fail
> if a conflict occurs when it is committed. This requires a different
> design on all levels though - up to the user who has to live with the
> fact that transactions can fail and need to be redone.
>
>> Option 2 is actually feasible. This is the Clojure approach to the world - all data
>> structures are read only, and you "mutate" something by reconstructing a new copy with
>> the changes (sharing the old data wherever possible).
>
> Yes, it is feasible, see above. But very difficult to implement.
>
>> I am assuming, going forward, that the structures in the database are intended to be
>> mutable, and they need to be protected by locks that can be taken in arbitrary order. If
>> that is correct, then deadlocks are going to occur.
>
> Correct. See above.
>
> Wolfgang
>
--
Adam Retter
eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb
|
|
From: Adam R. <ad...@ex...> - 2010-09-02 10:54:20
|
I am using Chrome on MacOSX and Chromium on Ubuntu Linux and have not seem any issues. On 2 September 2010 11:21, Wolfgang Meier <wol...@ex...> wrote: >> It seems to block longer for function modules that have more functions in them (eg. more content) so I suspect it's an >> issue with the javascript having to loop over all the functions being displayed. > > Function search and browsing is rather instantaneous on my machine > (using Firefox 4b4). Firebug does also not show any resources being > loaded from external sources, except for the sourceforge logo. > > Wolfgang > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
|
From: Wolfgang M. <wol...@ex...> - 2010-09-02 10:21:59
|
> It seems to block longer for function modules that have more functions in them (eg. more content) so I suspect it's an > issue with the javascript having to loop over all the functions being displayed. Function search and browsing is rather instantaneous on my machine (using Firefox 4b4). Firebug does also not show any resources being loaded from external sources, except for the sourceforge logo. Wolfgang |
|
From: Dmitriy S. <sha...@gm...> - 2010-09-02 06:30:07
|
On Wed, 2010-09-01 at 21:29 +0200, Wolfgang Meier wrote: > > Wow steady on there! Thats a bit early! how about 3pm UTC? > > I have an unexpected appointment tomorrow. Could we move the > conference to 6pm UTC? If not, I'll need to see how I can plug in. Fine for me. -- Cheers, Dmitriy Shabanov |
|
From: Dmitriy S. <sha...@gm...> - 2010-09-02 06:20:09
|
On Wed, 2010-09-01 at 15:05 -0400, Andrzej Jan Taramina wrote: > > Automatic /db/system/users.xml migration does not work. I tried our > app with an existing database on the latest SVN > build, and it doesn't pick up some of the users we already have > defined in the /db/system/users.xml file. How do you do db migration? restore from backup? or just run on existing data? > Is this not working yet? What rev do you use? -- Cheers, Dmitriy Shabanov |
|
From: Loren C. <lor...@gm...> - 2010-09-01 19:34:06
|
My only time constraint is 12:00 - 13:00 CDT (UTC - 5). I have a lunch meeting. Loren On Sep 1, 2010, at 02:29 PM, Wolfgang Meier wrote: >> Wow steady on there! Thats a bit early! how about 3pm UTC? > > I have an unexpected appointment tomorrow. Could we move the > conference to 6pm UTC? If not, I'll need to see how I can plug in. > > Wolfgang |
|
From: Wolfgang M. <wol...@ex...> - 2010-09-01 19:29:44
|
> Wow steady on there! Thats a bit early! how about 3pm UTC? I have an unexpected appointment tomorrow. Could we move the conference to 6pm UTC? If not, I'll need to see how I can plug in. Wolfgang |
|
From: Andrzej J. T. <an...@ch...> - 2010-09-01 19:06:10
|
Dmitriy: >>>> TODO: >>>> 1. fix backup restore, automatic /db/system/users.xml migration question >>>> 2. principal delete procedure >>>> 3. make sure that old clients will work with new API, as example oXygen >>>> with old libs >>>> 4. stabilization >>> >>> I'm really keen on 1 & 4. Any ETA on when you think that might be ready for testing with existing databases? > The items 1 & 2 should be done. Let me know if any problem. Automatic /db/system/users.xml migration does not work. I tried our app with an existing database on the latest SVN build, and it doesn't pick up some of the users we already have defined in the /db/system/users.xml file. Is this not working yet? Thanks! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2010-09-01 17:58:02
|
>> Not sure if it's because it's hitting an external site...or if it's >> because the js code is just looping too much. > > How big is result set? If yes - it's a looping, if no - it's loading ... It seems to block longer for function modules that have more functions in them (eg. more content) so I suspect it's an issue with the javascript having to loop over all the functions being displayed. Never used to do this....not sure what all that JS is doing anyway. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Dmitriy S. <sha...@gm...> - 2010-09-01 17:21:57
|
On Wed, 2010-09-01 at 13:15 -0400, Andrzej Jan Taramina wrote: > > Not sure if it's because it's hitting an external site...or if it's > because the js code is just looping too much. How big is result set? If yes - it's a looping, if no - it's loading ... -- Cheers, Dmitriy Shabanov |
|
From: Andrzej J. T. <an...@ch...> - 2010-09-01 17:14:53
|
> How about this one? > > <div class="banner"> > <a href="http://sourceforge.net/projects/exist"> > <img xmlns="http://exist-db.org/NS/sidebar" > xmlns:xi="http://www.w3.org/2001/XInclude" > src="http://sourceforge.net/sflogo.php?group_id=17691&type=4" > width="125" height="37" border="0" alt="SourceForge Logo" /> > </a> > </div> Nevermind....it's on the left nav area...and that's fine. The problem isn't with sourcing those external images....it's when you select a function namespace and hit the browse button on the XQuery Function Doc page. It's definitely the javascript that is doing a lot of fancy formatting that is blocking on something and locking up the browser and even the whole machine for an inordinate amount of time. Not sure if it's because it's hitting an external site...or if it's because the js code is just looping too much. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Dmitriy S. <sha...@gm...> - 2010-09-01 17:13:14
|
On Wed, 2010-09-01 at 13:04 -0400, Andrzej Jan Taramina wrote: > > How about this one? > > > > <div class="banner"> > > <a href="http://sourceforge.net/projects/exist"> > > <img xmlns="http://exist-db.org/NS/sidebar" > > xmlns:xi="http://www.w3.org/2001/XInclude" > > src="http://sourceforge.net/sflogo.php?group_id=17691&type=4" > > width="125" height="37" border="0" alt="SourceForge Logo" /> > > </a> > > </div> > > Where is that snipped located/generated? You should check page source. Generated .... some there around :-) it should be hardcoded, so easy to find by search. -- Cheers, Dmitriy Shabanov |
|
From: Jason S. <js...@in...> - 2010-09-01 17:09:34
|
If used from the front-end APIs, eXist does not deadlock on typical XQueries. I'm not sure what you mean by "collections are always ordered the same" though. I can reference fn:collection("...") in multiple places in a single XPath, and these are not guaranteed to execute in the same order from one XQuery to the next. Fn:collection("...") must acquire a collection lock at some point, correct?
Also, keep in mind that deadlock detection in eXist is currently broken, and I don't think it can be fixed. I'm working on a write-up.
Other databases do have high concurrency. I don't know about XML databases though. I've worked with one in particular that is commercial. It has a collection-based locking model, and it throws deadlock errors occasionally. When this happens, you rollback and start over. And this other database appears to have some concurrency limitations as well, just from some of the testing we've done (very preliminary).
So this is what is driving the conversation - how do we get to granular, concurrent access without killing ourselves with deadlocking? A small number of intention locks is manageable. Too few results in limited concurrency. Too many results in a really difficult deadlock problem (detection is expensive). Any solution that does not need locking at all should get CAREFUL consideration!!! :-) IMHO
-----Original Message-----
From: Wolfgang Meier [mailto:wol...@ex...]
Sent: Wednesday, September 01, 2010 9:24 AM
To: Jason Smith
Cc: Adam Retter; Paul Ryan; eXist development; Michael J. Pelikan; Todd Gochenour
Subject: Re: [Exist-development] [Exist-open] Performance of concurrent read queries.
> The problem with deadlocks (the one I ran into) doesn't actually have anything to do with
> the collection hierarchy. They are simply caused by taking two locks out of order.
Seems we need a bunch of low-level test cases first (there are some
higher level tests I used to debug similar issues). Sure, thread T1
can take a lock on doc A, then doc B, while thread T2 locks B then A
(see XQuery below). This case should indeed be handled by the deadlock
detection. However, in most cases eXist does take locks in order (due
to the fact that collections are always ordered the same).
> If I understand this correctly, the new design will need to manage, potentially, hundreds
> of thousands of locks that can be taken in arbitrary order.
Most traditional databases use an even finer granularity (single
pages, records, tuples). The new design would in no way be different
from the current situation. The query optimizer can effectively limit
the number of resources to be locked. I'm convinced that investing
time into improving the optimizer is the best way to achieve quick
improvements.
By redesigning the storage backend, you can increase performance by
50% or maybe 70% if things go well. Improvements to the query
optimizer often result in performance wins up to 500% and more. I just
did it again for some full text queries (not committed yet).
> 2) If you have more than one lock, guarantee that all locks are taken in the same order every time.
Given the possibilities of XQuery, this is going to be difficult to
guarantee,e.g.:
let $doc := request:get-parameter("doc", ())
let $a := doc($doc)/root
let $b := doc($doc//link/@href/string())
return
(: do something, even read-only, with $a and $b :)
Since $b is determined by querying $a, you don't know in advance where
it will point to. If there's a circular link between $a and $b, you
deadlock. Allowing dirty reads helps a bit here.
> 3) Don't use locking at all. Use a scheme that avoids the need for locking.
There are (relational) databases which avoid locking, e.g. by using a
shadow page concept on low-level storage and make the transaction fail
if a conflict occurs when it is committed. This requires a different
design on all levels though - up to the user who has to live with the
fact that transactions can fail and need to be redone.
> Option 2 is actually feasible. This is the Clojure approach to the world - all data
> structures are read only, and you "mutate" something by reconstructing a new copy with
> the changes (sharing the old data wherever possible).
Yes, it is feasible, see above. But very difficult to implement.
> I am assuming, going forward, that the structures in the database are intended to be
> mutable, and they need to be protected by locks that can be taken in arbitrary order. If
> that is correct, then deadlocks are going to occur.
Correct. See above.
Wolfgang
|
|
From: Andrzej J. T. <an...@ch...> - 2010-09-01 17:03:51
|
> How about this one? > > <div class="banner"> > <a href="http://sourceforge.net/projects/exist"> > <img xmlns="http://exist-db.org/NS/sidebar" > xmlns:xi="http://www.w3.org/2001/XInclude" > src="http://sourceforge.net/sflogo.php?group_id=17691&type=4" > width="125" height="37" border="0" alt="SourceForge Logo" /> > </a> > </div> Where is that snipped located/generated? -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Dmitriy S. <sha...@gm...> - 2010-09-01 16:41:06
|
On Wed, 2010-09-01 at 12:29 -0400, Andrzej Jan Taramina wrote: > Wolfgang: > > >>> documentation, the page hits sourceforge.net?!!?!?! > > > > Yes, sourceforge.net has been quite slow during the past days. > > > >>> This doesn't seem right... > >> > >> Logos? > > > > Indeed. Could we just remove them everywhere and just keep them for index.xml? > > It's not the logos...they are being sourced from the local instance. > > I think it's something in the javascript that is being used to do fancy formatting of the function doc entries. I'll > bet it's trying to grab other .js libraries from external sources, when it should be sourcing them locally. Could be > the YUI stuff perhaps? How about this one? <div class="banner"> <a href="http://sourceforge.net/projects/exist"> <img xmlns="http://exist-db.org/NS/sidebar" xmlns:xi="http://www.w3.org/2001/XInclude" src="http://sourceforge.net/sflogo.php?group_id=17691&type=4" width="125" height="37" border="0" alt="SourceForge Logo" /> </a> </div> -- Cheers, Dmitriy Shabanov |
64 messages has been excluded from this view by a project administrator.
