Thanks for mentioning submodules, since I was unaware of that option. They look useful, but perhaps a bit awkward for this situation. I might look into a "subtree merge" strategy, or the git-subtree code from Avery Pennarun.
Tabling submodules and related approaches for a moment... what problems do you see with rolling cprof directly into Presta? They are still separate library modules, so a developer who only wants the cprof portion can skip the presta:install step and use cprof independently. Perhaps I should separate the test cases too, just to make life easier for cprof-only developers. In an ideal world there would be an XQuery package installation system with dependency management. Meanwhile I am trying for the least evil solution. -- Mike On 2 Jun 2012, at 08:17 , Ryan Dew wrote: > Just poking through the code, this looks really awesome. Thanks for sharing! > I am already brainstorming cool ways to make use of this. > > One comment, though. Do you really want to move cprof into Presta? It seems > that cprof fills quite a different purpose than Presta (despite working with > the same xdmp functions), unless I'm missing something. Have you considered > including cprof into Presta as a git submodule? > > -Ryan Dew > > On Jun 1, 2012, at 6:20 PM, Michael Blakeley wrote: > >> https://github.com/mblakele/presta is now available. This library started >> when I noticed the new 'result' option for xdmp:spawn in MarkLogic 5.0. That >> looked handy, but xdmp:spawn still wanted me to supply a module path. I >> wanted to write XQuery tasks with arbitrary code strings, like this: >> >> for $i in 1 to 4 >> return xdmp:spawn-eval( >> 'xdmp:sleep(1000)', (), >> <options xmlns="xdmp:eval"> >> <result>true</result> >> </options>), >> xdmp:elapsed-time() >> >> ...and have all four tasks execute in parallel, using all my CPUs and >> returning the results. Here's what I ended up with: >> >> import module namespace presta="com.blakeley.presta" >> at "presta.xqy"; >> >> let $presta-id := presta:prepare('xdmp:sleep(1000)') >> for $i in 1 to 4 >> return presta:spawn( >> $presta-id, (), >> <options xmlns="xdmp:eval"> >> <result>true</result> >> </options>), >> xdmp:elapsed-time() >> >> The presta:spawn function works just like xdmp:spawn, and takes the same >> arguments - except that the first parameter is a presta id not a module >> path. We get that id by calling presta:prepare, which takes the XQuery >> string and stores it the Modules database. >> >> The id for a Presta module is based on xdmp:hash64, so preparing the same >> XQuery twice will return the same id. Presta tries not to update the Modules >> database any more than necessary - but it's still best to stash these ids >> somewhere if you can. >> >> Once prepared, we can also use a presta id with presta:invoke. This is handy >> for apps that eval the same strings frequently, because the Presta module >> works with the module cache. And we don't have to keep the XQuery around >> after it has been registered. This could be a way for developers using Java >> to get some of the performance benefits of invoke, without having to write >> every XQuery module in advance. >> >> But there's more to MarkLogic than XQuery. We can also call presta:prepare >> with XSLT, and then call presta:xslt-invoke. >> >> We need libraries, too. So you can call presta:import to install a library >> module where other Presta functions can find it. >> >> presta:import( >> 'lib-test.xqy', >> 'module namespace t="com.blakeley.presta.test"; >> declare function t:now() { fn:current-dateTime() };') >> >> presta:invoke( >> p:prepare( >> 'import module namespace t="com.blakeley.presta.test" >> at "lib-test.xqy"; >> t:now() >> >> I almost forgot about environments with multiple applications. Every >> app-server automatically gets its own Presta environment, based on the >> appserver id from xdmp:server(). If you want multiple servers to share the >> same Presta modules, we can call presta:appkey-set('my-app-key'). If you >> want to keep modules somewhere other than the Modules database, set the >> app-server modules location to any database you like. >> >> Of course I also wanted Presta to work with profiling. Presta supports >> cprof, and includes a copy of the cprof library. My plan is to discontinue >> cprof as a separate project, and include it as part of Presta. >> >> Finally, Presta works with the security model. Presta installs a new role >> that you can grant to any user. >> >> The code is at https://github.com/mblakele/presta - I hope it's useful. >> >> -- Mike >> _______________________________________________ >> General mailing list >> [email protected] >> http://community.marklogic.com/mailman/listinfo/general > > _______________________________________________ > General mailing list > [email protected] > http://community.marklogic.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://community.marklogic.com/mailman/listinfo/general
