Menu
▾
▴
grailrtls-developers — List for those developing code
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(13) |
Feb
(2) |
Mar
(2) |
Apr
(17) |
May
(12) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Robert M. <ro...@cs...> - 2012-05-08 04:22:55
|
Following-up on my earlier email, a minor tweak in the URI:
The snapshot URL:
http://localhost:9998/grailrest/snapshot/?uri=core.3.anchor.wifi.receiver.060B6BD8.*&attribute=location.xoffset×tamp=1333256400000
Returns:
[{"attributes":[{"attributeName":"location.xoffset","origin":"romoore","creationDate":1332887102428,"expirationDate":0,"data":"69.5"}],"uri":"core.3.anchor.wifi.receiver.060B6BD8AED6"},{"attributes":[{"attributeName":"location.xoffset","origin":"romoore","creationDate":1332886618186,"expirationDate":0,"data":"69.0"}],"uri":"core.3.anchor.wifi.receiver.060B6BD8AED5"}]
The range request URL:
http://localhost:9998/grailrest/range/?uri=ee.*&start=0&end=1336453781000&attribute=location.xoffset
Returns:
[{"attributes":[{"attributeName":"location.xoffset","origin":"romoore","creationDate":1335564959603,"expirationDate":1335565050704,"data":"1600.0"},{"attributeName":"location.xoffset","origin":"romoore","creationDate":1335565050704,"expirationDate":1335625674435,"data":"1550.0"},{"attributeName":"location.xoffset","origin":"romoore","creationDate":1335625674435,"expirationDate":1335625685412,"data":"1500.0"},{"attributeName":"location.xoffset","origin":"romoore","creationDate":1335625685412,"expirationDate":1335625714146,"data":"1450.0"},{"attributeName":"location.xoffset","origin":"romoore","creationDate":1335625714146,"expirationDate":0,"data":"1425.0"}],"uri":"ee.chair.105"}]
What does everyone think? I have it in a private repo on bitbucket
right now, I'll push to Grail later this week after I get some feedback.
--Rob
On 05/07/2012 11:29 PM, Robert Moore wrote:
> Hi GRAIL developers,
>
> I'm putting together a rather quick-and-dirty RESTful interface for
> GRAIL that produces JSON output. Here's the first example I have, which
> is a simple URI snapshot search:
>
> http://localhost:9998/snapshot?uri=core.2
>
> [{"attributes":[{"attributeName":"creation","origin":"test.solver","creationDate":1328650583130,"expirationDate":0,"data":""},{"attributeName":"dimension.width","origin":"test.solver","creationDate":1331156841221,"expirationDate":0,"data":"200.0"},{"attributeName":"dimension.height","origin":"test.solver","creationDate":1331156855931,"expirationDate":0,"data":"88.0"},{"attributeName":"dimension.units","origin":"test.solver","creationDate":1331157674031,"expirationDate":0,"data":"feet"},{"attributeName":"image.url","origin":"test.solver","creationDate":1331161316404,"expirationDate":0,"data":"http://eden.rutgers.edu/~romoore/core2.jpg"}],"uri":"core.2"}]
>
>
> Just a taste of the JSON being returned. Feel free to comment on how we
> should handle things. Obviously I'll be creating more complex URL
> parsing, including support for POST and perhaps even session management
> later on.
>
> What does everyone think?
>
> --Rob
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Grailrtls-developers mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers
|
|
From: Robert M. <ro...@cs...> - 2012-05-08 03:29:19
|
Hi GRAIL developers,
I'm putting together a rather quick-and-dirty RESTful interface for
GRAIL that produces JSON output. Here's the first example I have, which
is a simple URI snapshot search:
http://localhost:9998/snapshot?uri=core.2
[{"attributes":[{"attributeName":"creation","origin":"test.solver","creationDate":1328650583130,"expirationDate":0,"data":""},{"attributeName":"dimension.width","origin":"test.solver","creationDate":1331156841221,"expirationDate":0,"data":"200.0"},{"attributeName":"dimension.height","origin":"test.solver","creationDate":1331156855931,"expirationDate":0,"data":"88.0"},{"attributeName":"dimension.units","origin":"test.solver","creationDate":1331157674031,"expirationDate":0,"data":"feet"},{"attributeName":"image.url","origin":"test.solver","creationDate":1331161316404,"expirationDate":0,"data":"http://eden.rutgers.edu/~romoore/core2.jpg"}],"uri":"core.2"}]
Just a taste of the JSON being returned. Feel free to comment on how we
should handle things. Obviously I'll be creating more complex URL
parsing, including support for POST and perhaps even session management
later on.
What does everyone think?
--Rob
|
|
From: Robert M. <ro...@cs...> - 2012-04-11 13:14:54
|
If you find a specific example of this, please let me know. I haven't encountered solvers that don't run due to missing dependencies in the JARs, but I could have missed one. If they are missing, it would definitely have been an oversight on my part. --Rob On 04/11/2012 08:51 AM, Douglas Motto wrote: > Compared to other dependency retrieval and compile times for other > software, the couple of minutes (at most) that I have seen for the build > of the aggregator and/or solvers to me is relatively short. > > > One thing I've seen, and this is probably due to my inexperience with > maven, is that the "-with-dependencies" jar file seems to be missing > dependencies (for solver builds). I would have to readjust the > classpath to include the raw classes or other jar libs (that I thought > would be included), but figured I would mention it here. > > Doug > > On 4/10/12 10:51 PM, Robert Moore wrote: >> The maven dependencies are primarily caused by maven being a modular >> build system. The first time you build, you need to download large >> chunks of maven's basic components (compiler module, testing module, >> etc.). In addition, the Java components have a few dependencies (I >> think around 8), and use some fairly standard plug-ins (javadoc, site, >> build-jar, etc.). The first build is a killer for any maven project, >> but most of the components are re-used across projects. >> >> Once the dependencies are downloaded and installed, the aggregator >> should build in 10-40 seconds, depending on the host. Also, if we use >> non-snapshot versions, then we don't need to rebuild the libraries it >> uses, bringing the time to 4-10 seconds. >> >> --Rob >> >> On 04/10/2012 10:40 PM, bf...@ed... wrote: >>> I agree with the monolithic script, if only because it makes it easier for >>> find when you browse the directory and it might be more famililar to some >>> people. >>> >>> On a semi-related note, I sat down with Jun today to build the aggregator >>> and world model and Mavan took a LONG time to download all of its >>> dependencies even though it was just building the aggregator. He was on >>> wireless, but still the wait was several minutes with no indication of >>> when it would finish before it even started building. Are all of these >>> dependencies necessary? Or is there a way to only download the ones for >>> the current target? >>> >>> -Ben >>> >>>> I guess its a switch from the docs here... >>>> >>>> http://sourceforge.net/apps/mediawiki/grailrtls/index.php?title=Developer_Setup_Guide >>>> >>>> >>>> No matter what's used...java-like's "build.sh" or C's "make"...I suggest >>>> that both WM and aggregator build similarly. >>>> >>>> >>>> It appears more than not, "build.sh" appears to follow the similar >>>> targets/modules as "make" does, so if you wanted to follow others, you'd >>>> specify the component as the first argument and keep the monolith. >>>> Anything non-supported wouldn't build for "all". So for example, say >>>> "solver-fridge" is including in the repo for distribution, but it isn't >>>> guaranteed to be supported (as it's a end user "contrib"ed). In which >>>> case "build.sh all" wouldn't build "solver-fridge" but "build.sh >>>> solver-fridge" obviously would. >>>> >>>> >>>> Instead of writing one from scratch, here's a good "build.sh" script to >>>> "borrow" off of as a template... >>>> >>>> http://cgit.freedesktop.org/xorg/util/modular/tree/build.sh >>>> >>>> >>>> Doug >>>> >>>> On 4/10/12 9:23 PM, Robert Moore wrote: >>>>> I was just curious if people, especially Ben, cared whether we used a >>>>> monolithic script or a bunch of small scripts. Init scripts can be >>>>> handled separately, but these are just conveniences for invoking maven >>>>> and running from the generated .jar files. >>>>> >>>>> --Rob >>>>> >>>>> On 04/10/2012 07:30 PM, Douglas Motto wrote: >>>>>> Have you considered "make" (or "cmake") for the build? (one step >>>>>> further would be to use configure to setup/test the build environment >>>>>> for dependencies) >>>>>> >>>>>> >>>>>> For the run scripts, if you stick to *nix, why not use SysVinit... >>>>>> >>>>>> /etc/init.d/{servicename} [start|stop|status] >>>>>> >>>>>> >>>>>> Doug >>>>>> >>>>>> >>>>>> On 4/10/12 7:09 PM, Robert Moore wrote: >>>>>>> Hi Ben, >>>>>>> >>>>>>> I'm writing up some build/run scripts for the Java components, but >>>>>>> not >>>>>>> sure which approach is better: >>>>>>> >>>>>>> $> ./build.sh >>>>>>> Usage: build.sh [COMPONENT] >>>>>>> Where COMPONENT is one of: >>>>>>> aggregator >>>>>>> simulation >>>>>>> solver-passive-motion >>>>>>> solver-notification >>>>>>> solver-fridge >>>>>>> tutorials >>>>>>> $> ./build.sh aggregator >>>>>>> $> ./run.sh aggregator >>>>>>> >>>>>>> OR >>>>>>> >>>>>>> $> ./build-aggregator.sh >>>>>>> $> ./run-aggregator.sh >>>>>>> >>>>>>> $> ./build-simulation.sh >>>>>>> >>>>>>> $> ./run-tutorials.sh >>>>>>> >>>>>>> Basically, 2 big scripts with lotsa options, or many smaller scripts >>>>>>> (that would actually reference some infrastructure scripts)? >>>>>>> Thoughts? >>>>>>> >>>>>>> --Rob >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Better than sec? Nothing is better than sec when it comes to >>>>>>> monitoring Big Data applications. Try Boundary one-second >>>>>>> resolution app monitoring today. Free. >>>>>>> http://p.sf.net/sfu/Boundary-dev2dev >>>>>>> _______________________________________________ >>>>>>> Grailrtls-developers mailing list >>>>>>> Gra...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>>>>> >>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Better than sec? Nothing is better than sec when it comes to >>>>> monitoring Big Data applications. Try Boundary one-second >>>>> resolution app monitoring today. Free. >>>>> http://p.sf.net/sfu/Boundary-dev2dev >>>>> _______________________________________________ >>>>> Grailrtls-developers mailing list >>>>> Gra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>>> >>>> >>>> >>>> -- >>>> -------------------------------------------------------- >>>> Douglas Motto >>>> dm...@cs... >>>> >>>> Systems Administrator/Programmer -- LCSR/DCS >>>> Rutgers, The State University of New Jersey >>>> -------------------------------------------------------- >>>> >>>> ------------------------------------------------------------------------------ >>>> Better than sec? Nothing is better than sec when it comes to >>>> monitoring Big Data applications. Try Boundary one-second >>>> resolution app monitoring today. Free. >>>> http://p.sf.net/sfu/Boundary-dev2dev >>>> _______________________________________________ >>>> Grailrtls-developers mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Better than sec? Nothing is better than sec when it comes to >>> monitoring Big Data applications. Try Boundary one-second >>> resolution app monitoring today. Free. >>> http://p.sf.net/sfu/Boundary-dev2dev >>> _______________________________________________ >>> Grailrtls-developers mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Grailrtls-developers mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > > > |
|
From: Douglas M. <dm...@cs...> - 2012-04-11 12:51:23
|
Compared to other dependency retrieval and compile times for other software, the couple of minutes (at most) that I have seen for the build of the aggregator and/or solvers to me is relatively short. One thing I've seen, and this is probably due to my inexperience with maven, is that the "-with-dependencies" jar file seems to be missing dependencies (for solver builds). I would have to readjust the classpath to include the raw classes or other jar libs (that I thought would be included), but figured I would mention it here. Doug On 4/10/12 10:51 PM, Robert Moore wrote: > The maven dependencies are primarily caused by maven being a modular > build system. The first time you build, you need to download large > chunks of maven's basic components (compiler module, testing module, > etc.). In addition, the Java components have a few dependencies (I > think around 8), and use some fairly standard plug-ins (javadoc, site, > build-jar, etc.). The first build is a killer for any maven project, > but most of the components are re-used across projects. > > Once the dependencies are downloaded and installed, the aggregator > should build in 10-40 seconds, depending on the host. Also, if we use > non-snapshot versions, then we don't need to rebuild the libraries it > uses, bringing the time to 4-10 seconds. > > --Rob > > On 04/10/2012 10:40 PM, bf...@ed... wrote: >> I agree with the monolithic script, if only because it makes it easier for >> find when you browse the directory and it might be more famililar to some >> people. >> >> On a semi-related note, I sat down with Jun today to build the aggregator >> and world model and Mavan took a LONG time to download all of its >> dependencies even though it was just building the aggregator. He was on >> wireless, but still the wait was several minutes with no indication of >> when it would finish before it even started building. Are all of these >> dependencies necessary? Or is there a way to only download the ones for >> the current target? >> >> -Ben >> >>> I guess its a switch from the docs here... >>> >>> http://sourceforge.net/apps/mediawiki/grailrtls/index.php?title=Developer_Setup_Guide >>> >>> >>> No matter what's used...java-like's "build.sh" or C's "make"...I suggest >>> that both WM and aggregator build similarly. >>> >>> >>> It appears more than not, "build.sh" appears to follow the similar >>> targets/modules as "make" does, so if you wanted to follow others, you'd >>> specify the component as the first argument and keep the monolith. >>> Anything non-supported wouldn't build for "all". So for example, say >>> "solver-fridge" is including in the repo for distribution, but it isn't >>> guaranteed to be supported (as it's a end user "contrib"ed). In which >>> case "build.sh all" wouldn't build "solver-fridge" but "build.sh >>> solver-fridge" obviously would. >>> >>> >>> Instead of writing one from scratch, here's a good "build.sh" script to >>> "borrow" off of as a template... >>> >>> http://cgit.freedesktop.org/xorg/util/modular/tree/build.sh >>> >>> >>> Doug >>> >>> On 4/10/12 9:23 PM, Robert Moore wrote: >>>> I was just curious if people, especially Ben, cared whether we used a >>>> monolithic script or a bunch of small scripts. Init scripts can be >>>> handled separately, but these are just conveniences for invoking maven >>>> and running from the generated .jar files. >>>> >>>> --Rob >>>> >>>> On 04/10/2012 07:30 PM, Douglas Motto wrote: >>>>> Have you considered "make" (or "cmake") for the build? (one step >>>>> further would be to use configure to setup/test the build environment >>>>> for dependencies) >>>>> >>>>> >>>>> For the run scripts, if you stick to *nix, why not use SysVinit... >>>>> >>>>> /etc/init.d/{servicename} [start|stop|status] >>>>> >>>>> >>>>> Doug >>>>> >>>>> >>>>> On 4/10/12 7:09 PM, Robert Moore wrote: >>>>>> Hi Ben, >>>>>> >>>>>> I'm writing up some build/run scripts for the Java components, but >>>>>> not >>>>>> sure which approach is better: >>>>>> >>>>>> $> ./build.sh >>>>>> Usage: build.sh [COMPONENT] >>>>>> Where COMPONENT is one of: >>>>>> aggregator >>>>>> simulation >>>>>> solver-passive-motion >>>>>> solver-notification >>>>>> solver-fridge >>>>>> tutorials >>>>>> $> ./build.sh aggregator >>>>>> $> ./run.sh aggregator >>>>>> >>>>>> OR >>>>>> >>>>>> $> ./build-aggregator.sh >>>>>> $> ./run-aggregator.sh >>>>>> >>>>>> $> ./build-simulation.sh >>>>>> >>>>>> $> ./run-tutorials.sh >>>>>> >>>>>> Basically, 2 big scripts with lotsa options, or many smaller scripts >>>>>> (that would actually reference some infrastructure scripts)? >>>>>> Thoughts? >>>>>> >>>>>> --Rob >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Better than sec? Nothing is better than sec when it comes to >>>>>> monitoring Big Data applications. Try Boundary one-second >>>>>> resolution app monitoring today. Free. >>>>>> http://p.sf.net/sfu/Boundary-dev2dev >>>>>> _______________________________________________ >>>>>> Grailrtls-developers mailing list >>>>>> Gra...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>>>> >>>>> >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Better than sec? Nothing is better than sec when it comes to >>>> monitoring Big Data applications. Try Boundary one-second >>>> resolution app monitoring today. Free. >>>> http://p.sf.net/sfu/Boundary-dev2dev >>>> _______________________________________________ >>>> Grailrtls-developers mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>> >>> >>> >>> -- >>> -------------------------------------------------------- >>> Douglas Motto >>> dm...@cs... >>> >>> Systems Administrator/Programmer -- LCSR/DCS >>> Rutgers, The State University of New Jersey >>> -------------------------------------------------------- >>> >>> ------------------------------------------------------------------------------ >>> Better than sec? Nothing is better than sec when it comes to >>> monitoring Big Data applications. Try Boundary one-second >>> resolution app monitoring today. Free. >>> http://p.sf.net/sfu/Boundary-dev2dev >>> _______________________________________________ >>> Grailrtls-developers mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>> >> >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Grailrtls-developers mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers -- -------------------------------------------------------- Douglas Motto dm...@cs... Systems Administrator/Programmer -- LCSR/DCS Rutgers, The State University of New Jersey -------------------------------------------------------- |
|
From: Robert M. <ro...@cs...> - 2012-04-11 02:51:08
|
The maven dependencies are primarily caused by maven being a modular build system. The first time you build, you need to download large chunks of maven's basic components (compiler module, testing module, etc.). In addition, the Java components have a few dependencies (I think around 8), and use some fairly standard plug-ins (javadoc, site, build-jar, etc.). The first build is a killer for any maven project, but most of the components are re-used across projects. Once the dependencies are downloaded and installed, the aggregator should build in 10-40 seconds, depending on the host. Also, if we use non-snapshot versions, then we don't need to rebuild the libraries it uses, bringing the time to 4-10 seconds. --Rob On 04/10/2012 10:40 PM, bf...@ed... wrote: > I agree with the monolithic script, if only because it makes it easier for > find when you browse the directory and it might be more famililar to some > people. > > On a semi-related note, I sat down with Jun today to build the aggregator > and world model and Mavan took a LONG time to download all of its > dependencies even though it was just building the aggregator. He was on > wireless, but still the wait was several minutes with no indication of > when it would finish before it even started building. Are all of these > dependencies necessary? Or is there a way to only download the ones for > the current target? > > -Ben > >> I guess its a switch from the docs here... >> >> http://sourceforge.net/apps/mediawiki/grailrtls/index.php?title=Developer_Setup_Guide >> >> >> No matter what's used...java-like's "build.sh" or C's "make"...I suggest >> that both WM and aggregator build similarly. >> >> >> It appears more than not, "build.sh" appears to follow the similar >> targets/modules as "make" does, so if you wanted to follow others, you'd >> specify the component as the first argument and keep the monolith. >> Anything non-supported wouldn't build for "all". So for example, say >> "solver-fridge" is including in the repo for distribution, but it isn't >> guaranteed to be supported (as it's a end user "contrib"ed). In which >> case "build.sh all" wouldn't build "solver-fridge" but "build.sh >> solver-fridge" obviously would. >> >> >> Instead of writing one from scratch, here's a good "build.sh" script to >> "borrow" off of as a template... >> >> http://cgit.freedesktop.org/xorg/util/modular/tree/build.sh >> >> >> Doug >> >> On 4/10/12 9:23 PM, Robert Moore wrote: >>> I was just curious if people, especially Ben, cared whether we used a >>> monolithic script or a bunch of small scripts. Init scripts can be >>> handled separately, but these are just conveniences for invoking maven >>> and running from the generated .jar files. >>> >>> --Rob >>> >>> On 04/10/2012 07:30 PM, Douglas Motto wrote: >>>> Have you considered "make" (or "cmake") for the build? (one step >>>> further would be to use configure to setup/test the build environment >>>> for dependencies) >>>> >>>> >>>> For the run scripts, if you stick to *nix, why not use SysVinit... >>>> >>>> /etc/init.d/{servicename} [start|stop|status] >>>> >>>> >>>> Doug >>>> >>>> >>>> On 4/10/12 7:09 PM, Robert Moore wrote: >>>>> Hi Ben, >>>>> >>>>> I'm writing up some build/run scripts for the Java components, but >>>>> not >>>>> sure which approach is better: >>>>> >>>>> $> ./build.sh >>>>> Usage: build.sh [COMPONENT] >>>>> Where COMPONENT is one of: >>>>> aggregator >>>>> simulation >>>>> solver-passive-motion >>>>> solver-notification >>>>> solver-fridge >>>>> tutorials >>>>> $> ./build.sh aggregator >>>>> $> ./run.sh aggregator >>>>> >>>>> OR >>>>> >>>>> $> ./build-aggregator.sh >>>>> $> ./run-aggregator.sh >>>>> >>>>> $> ./build-simulation.sh >>>>> >>>>> $> ./run-tutorials.sh >>>>> >>>>> Basically, 2 big scripts with lotsa options, or many smaller scripts >>>>> (that would actually reference some infrastructure scripts)? >>>>> Thoughts? >>>>> >>>>> --Rob >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Better than sec? Nothing is better than sec when it comes to >>>>> monitoring Big Data applications. Try Boundary one-second >>>>> resolution app monitoring today. Free. >>>>> http://p.sf.net/sfu/Boundary-dev2dev >>>>> _______________________________________________ >>>>> Grailrtls-developers mailing list >>>>> Gra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> Better than sec? Nothing is better than sec when it comes to >>> monitoring Big Data applications. Try Boundary one-second >>> resolution app monitoring today. Free. >>> http://p.sf.net/sfu/Boundary-dev2dev >>> _______________________________________________ >>> Grailrtls-developers mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >> >> >> >> -- >> -------------------------------------------------------- >> Douglas Motto >> dm...@cs... >> >> Systems Administrator/Programmer -- LCSR/DCS >> Rutgers, The State University of New Jersey >> -------------------------------------------------------- >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Grailrtls-developers mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >> > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers |
|
From: <bf...@ed...> - 2012-04-11 02:43:32
|
Ruby doesn't compile itself, but the modules for GRAIL do get packaged into a gem (ruby package) which is then installed. We might want to set up a top level build script (I already have a make file in the top level that builds the aggregator and world model) that just compiles and installs the library files. This would make it easier for people to download the code, download the binaries for the aggregator and world model, build and install the libraries, and start programming. Of course we should have binary packages for different linuxes too, but maybe I'm getting too far ahead. -Ben > I don't believe it's a switch from the documentation. If you go down to > "Compiling the Java Components", you'll see steps to invoke Maven for > both the stand-alone dependencies and the GRAIL modules. The same > instructions are included in the "BUILD" file in the grail3_java > directory. > > I'll go with the monolithic approach unless anyone has a good reason not > to. It's less extensible, but I think it'll look more like the make > directives for the C/C++ code. I think we could do something similar > for ruby (not sure if they already have a build utility). > > --Rob > > On 04/10/2012 10:27 PM, Douglas Motto wrote: >> I guess its a switch from the docs here... >> >> http://sourceforge.net/apps/mediawiki/grailrtls/index.php?title=Developer_Setup_Guide >> >> >> No matter what's used...java-like's "build.sh" or C's "make"...I suggest >> that both WM and aggregator build similarly. >> >> >> It appears more than not, "build.sh" appears to follow the similar >> targets/modules as "make" does, so if you wanted to follow others, you'd >> specify the component as the first argument and keep the monolith. >> Anything non-supported wouldn't build for "all". So for example, say >> "solver-fridge" is including in the repo for distribution, but it isn't >> guaranteed to be supported (as it's a end user "contrib"ed). In which >> case "build.sh all" wouldn't build "solver-fridge" but "build.sh >> solver-fridge" obviously would. >> >> >> Instead of writing one from scratch, here's a good "build.sh" script to >> "borrow" off of as a template... >> >> http://cgit.freedesktop.org/xorg/util/modular/tree/build.sh >> >> >> Doug >> >> On 4/10/12 9:23 PM, Robert Moore wrote: >>> I was just curious if people, especially Ben, cared whether we used a >>> monolithic script or a bunch of small scripts. Init scripts can be >>> handled separately, but these are just conveniences for invoking maven >>> and running from the generated .jar files. >>> >>> --Rob >>> >>> On 04/10/2012 07:30 PM, Douglas Motto wrote: >>>> Have you considered "make" (or "cmake") for the build? (one step >>>> further would be to use configure to setup/test the build environment >>>> for dependencies) >>>> >>>> >>>> For the run scripts, if you stick to *nix, why not use SysVinit... >>>> >>>> /etc/init.d/{servicename} [start|stop|status] >>>> >>>> >>>> Doug >>>> >>>> >>>> On 4/10/12 7:09 PM, Robert Moore wrote: >>>>> Hi Ben, >>>>> >>>>> I'm writing up some build/run scripts for the Java components, but >>>>> not >>>>> sure which approach is better: >>>>> >>>>> $> ./build.sh >>>>> Usage: build.sh [COMPONENT] >>>>> Where COMPONENT is one of: >>>>> aggregator >>>>> simulation >>>>> solver-passive-motion >>>>> solver-notification >>>>> solver-fridge >>>>> tutorials >>>>> $> ./build.sh aggregator >>>>> $> ./run.sh aggregator >>>>> >>>>> OR >>>>> >>>>> $> ./build-aggregator.sh >>>>> $> ./run-aggregator.sh >>>>> >>>>> $> ./build-simulation.sh >>>>> >>>>> $> ./run-tutorials.sh >>>>> >>>>> Basically, 2 big scripts with lotsa options, or many smaller scripts >>>>> (that would actually reference some infrastructure scripts)? >>>>> Thoughts? >>>>> >>>>> --Rob >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Better than sec? Nothing is better than sec when it comes to >>>>> monitoring Big Data applications. Try Boundary one-second >>>>> resolution app monitoring today. Free. >>>>> http://p.sf.net/sfu/Boundary-dev2dev >>>>> _______________________________________________ >>>>> Grailrtls-developers mailing list >>>>> Gra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> Better than sec? Nothing is better than sec when it comes to >>> monitoring Big Data applications. Try Boundary one-second >>> resolution app monitoring today. Free. >>> http://p.sf.net/sfu/Boundary-dev2dev >>> _______________________________________________ >>> Grailrtls-developers mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >> >> >> > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > |
|
From: <bf...@ed...> - 2012-04-11 02:40:32
|
I agree with the monolithic script, if only because it makes it easier for find when you browse the directory and it might be more famililar to some people. On a semi-related note, I sat down with Jun today to build the aggregator and world model and Mavan took a LONG time to download all of its dependencies even though it was just building the aggregator. He was on wireless, but still the wait was several minutes with no indication of when it would finish before it even started building. Are all of these dependencies necessary? Or is there a way to only download the ones for the current target? -Ben > I guess its a switch from the docs here... > > http://sourceforge.net/apps/mediawiki/grailrtls/index.php?title=Developer_Setup_Guide > > > No matter what's used...java-like's "build.sh" or C's "make"...I suggest > that both WM and aggregator build similarly. > > > It appears more than not, "build.sh" appears to follow the similar > targets/modules as "make" does, so if you wanted to follow others, you'd > specify the component as the first argument and keep the monolith. > Anything non-supported wouldn't build for "all". So for example, say > "solver-fridge" is including in the repo for distribution, but it isn't > guaranteed to be supported (as it's a end user "contrib"ed). In which > case "build.sh all" wouldn't build "solver-fridge" but "build.sh > solver-fridge" obviously would. > > > Instead of writing one from scratch, here's a good "build.sh" script to > "borrow" off of as a template... > > http://cgit.freedesktop.org/xorg/util/modular/tree/build.sh > > > Doug > > On 4/10/12 9:23 PM, Robert Moore wrote: >> I was just curious if people, especially Ben, cared whether we used a >> monolithic script or a bunch of small scripts. Init scripts can be >> handled separately, but these are just conveniences for invoking maven >> and running from the generated .jar files. >> >> --Rob >> >> On 04/10/2012 07:30 PM, Douglas Motto wrote: >>> Have you considered "make" (or "cmake") for the build? (one step >>> further would be to use configure to setup/test the build environment >>> for dependencies) >>> >>> >>> For the run scripts, if you stick to *nix, why not use SysVinit... >>> >>> /etc/init.d/{servicename} [start|stop|status] >>> >>> >>> Doug >>> >>> >>> On 4/10/12 7:09 PM, Robert Moore wrote: >>>> Hi Ben, >>>> >>>> I'm writing up some build/run scripts for the Java components, but >>>> not >>>> sure which approach is better: >>>> >>>> $> ./build.sh >>>> Usage: build.sh [COMPONENT] >>>> Where COMPONENT is one of: >>>> aggregator >>>> simulation >>>> solver-passive-motion >>>> solver-notification >>>> solver-fridge >>>> tutorials >>>> $> ./build.sh aggregator >>>> $> ./run.sh aggregator >>>> >>>> OR >>>> >>>> $> ./build-aggregator.sh >>>> $> ./run-aggregator.sh >>>> >>>> $> ./build-simulation.sh >>>> >>>> $> ./run-tutorials.sh >>>> >>>> Basically, 2 big scripts with lotsa options, or many smaller scripts >>>> (that would actually reference some infrastructure scripts)? >>>> Thoughts? >>>> >>>> --Rob >>>> >>>> ------------------------------------------------------------------------------ >>>> Better than sec? Nothing is better than sec when it comes to >>>> monitoring Big Data applications. Try Boundary one-second >>>> resolution app monitoring today. Free. >>>> http://p.sf.net/sfu/Boundary-dev2dev >>>> _______________________________________________ >>>> Grailrtls-developers mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Grailrtls-developers mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > > > > -- > -------------------------------------------------------- > Douglas Motto > dm...@cs... > > Systems Administrator/Programmer -- LCSR/DCS > Rutgers, The State University of New Jersey > -------------------------------------------------------- > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > |
|
From: Robert M. <ro...@cs...> - 2012-04-11 02:39:54
|
I don't believe it's a switch from the documentation. If you go down to "Compiling the Java Components", you'll see steps to invoke Maven for both the stand-alone dependencies and the GRAIL modules. The same instructions are included in the "BUILD" file in the grail3_java directory. I'll go with the monolithic approach unless anyone has a good reason not to. It's less extensible, but I think it'll look more like the make directives for the C/C++ code. I think we could do something similar for ruby (not sure if they already have a build utility). --Rob On 04/10/2012 10:27 PM, Douglas Motto wrote: > I guess its a switch from the docs here... > > http://sourceforge.net/apps/mediawiki/grailrtls/index.php?title=Developer_Setup_Guide > > > No matter what's used...java-like's "build.sh" or C's "make"...I suggest > that both WM and aggregator build similarly. > > > It appears more than not, "build.sh" appears to follow the similar > targets/modules as "make" does, so if you wanted to follow others, you'd > specify the component as the first argument and keep the monolith. > Anything non-supported wouldn't build for "all". So for example, say > "solver-fridge" is including in the repo for distribution, but it isn't > guaranteed to be supported (as it's a end user "contrib"ed). In which > case "build.sh all" wouldn't build "solver-fridge" but "build.sh > solver-fridge" obviously would. > > > Instead of writing one from scratch, here's a good "build.sh" script to > "borrow" off of as a template... > > http://cgit.freedesktop.org/xorg/util/modular/tree/build.sh > > > Doug > > On 4/10/12 9:23 PM, Robert Moore wrote: >> I was just curious if people, especially Ben, cared whether we used a >> monolithic script or a bunch of small scripts. Init scripts can be >> handled separately, but these are just conveniences for invoking maven >> and running from the generated .jar files. >> >> --Rob >> >> On 04/10/2012 07:30 PM, Douglas Motto wrote: >>> Have you considered "make" (or "cmake") for the build? (one step >>> further would be to use configure to setup/test the build environment >>> for dependencies) >>> >>> >>> For the run scripts, if you stick to *nix, why not use SysVinit... >>> >>> /etc/init.d/{servicename} [start|stop|status] >>> >>> >>> Doug >>> >>> >>> On 4/10/12 7:09 PM, Robert Moore wrote: >>>> Hi Ben, >>>> >>>> I'm writing up some build/run scripts for the Java components, but not >>>> sure which approach is better: >>>> >>>> $> ./build.sh >>>> Usage: build.sh [COMPONENT] >>>> Where COMPONENT is one of: >>>> aggregator >>>> simulation >>>> solver-passive-motion >>>> solver-notification >>>> solver-fridge >>>> tutorials >>>> $> ./build.sh aggregator >>>> $> ./run.sh aggregator >>>> >>>> OR >>>> >>>> $> ./build-aggregator.sh >>>> $> ./run-aggregator.sh >>>> >>>> $> ./build-simulation.sh >>>> >>>> $> ./run-tutorials.sh >>>> >>>> Basically, 2 big scripts with lotsa options, or many smaller scripts >>>> (that would actually reference some infrastructure scripts)? Thoughts? >>>> >>>> --Rob >>>> >>>> ------------------------------------------------------------------------------ >>>> Better than sec? Nothing is better than sec when it comes to >>>> monitoring Big Data applications. Try Boundary one-second >>>> resolution app monitoring today. Free. >>>> http://p.sf.net/sfu/Boundary-dev2dev >>>> _______________________________________________ >>>> Grailrtls-developers mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Grailrtls-developers mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > > > |
|
From: Douglas M. <dm...@cs...> - 2012-04-11 02:27:26
|
I guess its a switch from the docs here... http://sourceforge.net/apps/mediawiki/grailrtls/index.php?title=Developer_Setup_Guide No matter what's used...java-like's "build.sh" or C's "make"...I suggest that both WM and aggregator build similarly. It appears more than not, "build.sh" appears to follow the similar targets/modules as "make" does, so if you wanted to follow others, you'd specify the component as the first argument and keep the monolith. Anything non-supported wouldn't build for "all". So for example, say "solver-fridge" is including in the repo for distribution, but it isn't guaranteed to be supported (as it's a end user "contrib"ed). In which case "build.sh all" wouldn't build "solver-fridge" but "build.sh solver-fridge" obviously would. Instead of writing one from scratch, here's a good "build.sh" script to "borrow" off of as a template... http://cgit.freedesktop.org/xorg/util/modular/tree/build.sh Doug On 4/10/12 9:23 PM, Robert Moore wrote: > I was just curious if people, especially Ben, cared whether we used a > monolithic script or a bunch of small scripts. Init scripts can be > handled separately, but these are just conveniences for invoking maven > and running from the generated .jar files. > > --Rob > > On 04/10/2012 07:30 PM, Douglas Motto wrote: >> Have you considered "make" (or "cmake") for the build? (one step >> further would be to use configure to setup/test the build environment >> for dependencies) >> >> >> For the run scripts, if you stick to *nix, why not use SysVinit... >> >> /etc/init.d/{servicename} [start|stop|status] >> >> >> Doug >> >> >> On 4/10/12 7:09 PM, Robert Moore wrote: >>> Hi Ben, >>> >>> I'm writing up some build/run scripts for the Java components, but not >>> sure which approach is better: >>> >>> $> ./build.sh >>> Usage: build.sh [COMPONENT] >>> Where COMPONENT is one of: >>> aggregator >>> simulation >>> solver-passive-motion >>> solver-notification >>> solver-fridge >>> tutorials >>> $> ./build.sh aggregator >>> $> ./run.sh aggregator >>> >>> OR >>> >>> $> ./build-aggregator.sh >>> $> ./run-aggregator.sh >>> >>> $> ./build-simulation.sh >>> >>> $> ./run-tutorials.sh >>> >>> Basically, 2 big scripts with lotsa options, or many smaller scripts >>> (that would actually reference some infrastructure scripts)? Thoughts? >>> >>> --Rob >>> >>> ------------------------------------------------------------------------------ >>> Better than sec? Nothing is better than sec when it comes to >>> monitoring Big Data applications. Try Boundary one-second >>> resolution app monitoring today. Free. >>> http://p.sf.net/sfu/Boundary-dev2dev >>> _______________________________________________ >>> Grailrtls-developers mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >> >> >> > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers -- -------------------------------------------------------- Douglas Motto dm...@cs... Systems Administrator/Programmer -- LCSR/DCS Rutgers, The State University of New Jersey -------------------------------------------------------- |
|
From: Robert M. <ro...@cs...> - 2012-04-11 01:23:59
|
I was just curious if people, especially Ben, cared whether we used a
monolithic script or a bunch of small scripts. Init scripts can be
handled separately, but these are just conveniences for invoking maven
and running from the generated .jar files.
--Rob
On 04/10/2012 07:30 PM, Douglas Motto wrote:
> Have you considered "make" (or "cmake") for the build? (one step
> further would be to use configure to setup/test the build environment
> for dependencies)
>
>
> For the run scripts, if you stick to *nix, why not use SysVinit...
>
> /etc/init.d/{servicename} [start|stop|status]
>
>
> Doug
>
>
> On 4/10/12 7:09 PM, Robert Moore wrote:
>> Hi Ben,
>>
>> I'm writing up some build/run scripts for the Java components, but not
>> sure which approach is better:
>>
>> $> ./build.sh
>> Usage: build.sh [COMPONENT]
>> Where COMPONENT is one of:
>> aggregator
>> simulation
>> solver-passive-motion
>> solver-notification
>> solver-fridge
>> tutorials
>> $> ./build.sh aggregator
>> $> ./run.sh aggregator
>>
>> OR
>>
>> $> ./build-aggregator.sh
>> $> ./run-aggregator.sh
>>
>> $> ./build-simulation.sh
>>
>> $> ./run-tutorials.sh
>>
>> Basically, 2 big scripts with lotsa options, or many smaller scripts
>> (that would actually reference some infrastructure scripts)? Thoughts?
>>
>> --Rob
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Grailrtls-developers mailing list
>> Gra...@li...
>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers
>
>
>
|
|
From: Douglas M. <dm...@cs...> - 2012-04-10 23:30:03
|
Have you considered "make" (or "cmake") for the build? (one step
further would be to use configure to setup/test the build environment
for dependencies)
For the run scripts, if you stick to *nix, why not use SysVinit...
/etc/init.d/{servicename} [start|stop|status]
Doug
On 4/10/12 7:09 PM, Robert Moore wrote:
> Hi Ben,
>
> I'm writing up some build/run scripts for the Java components, but not
> sure which approach is better:
>
> $> ./build.sh
> Usage: build.sh [COMPONENT]
> Where COMPONENT is one of:
> aggregator
> simulation
> solver-passive-motion
> solver-notification
> solver-fridge
> tutorials
> $> ./build.sh aggregator
> $> ./run.sh aggregator
>
> OR
>
> $> ./build-aggregator.sh
> $> ./run-aggregator.sh
>
> $> ./build-simulation.sh
>
> $> ./run-tutorials.sh
>
> Basically, 2 big scripts with lotsa options, or many smaller scripts
> (that would actually reference some infrastructure scripts)? Thoughts?
>
> --Rob
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Grailrtls-developers mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers
--
--------------------------------------------------------
Douglas Motto
dm...@cs...
Systems Administrator/Programmer -- LCSR/DCS
Rutgers, The State University of New Jersey
--------------------------------------------------------
|
|
From: Robert M. <ro...@cs...> - 2012-04-10 23:09:51
|
Hi Ben,
I'm writing up some build/run scripts for the Java components, but not
sure which approach is better:
$> ./build.sh
Usage: build.sh [COMPONENT]
Where COMPONENT is one of:
aggregator
simulation
solver-passive-motion
solver-notification
solver-fridge
tutorials
$> ./build.sh aggregator
$> ./run.sh aggregator
OR
$> ./build-aggregator.sh
$> ./run-aggregator.sh
$> ./build-simulation.sh
$> ./run-tutorials.sh
Basically, 2 big scripts with lotsa options, or many smaller scripts
(that would actually reference some infrastructure scripts)? Thoughts?
--Rob
|
|
From: Douglas M. <dm...@cs...> - 2012-04-04 18:42:02
|
I also think, in the short term, ignoring "begin" (or setting to null/"0") and document is way to go. In the long term, a discussion on what classes of data exist in the world model may help define the performable operations and what they mean. I've been hinting at the words like events and states (impluse, temporary, permanent). I've also been hinting at operations. Currently I still look at world model as a simple database, but the uniqueness that I see it is that it is a specialized dataset which conforms in a way that could in the future allow/perfom a higher level of operational tasks (either internal to the world model or in apps/solvers via libraries). I also think some of these discussions may be more mathematical defined. Maybe that would help. Doug On 4/4/12 1:41 PM, bf...@ed... wrote: > I think that's the way to go. Probably when historic queries become easier > to use we will have a better understanding of their use-cases. I think > that we originally wanted an inclusive window, but I remember a long > discussion at a GRAIL meeting about the logical AND of attributes if some > of the attributes were created before the window and whether a URI created > outside of that window was counted if those attributes were updated inside > of the window. In the end we decided an inclusive window was too ambiguous > and that we would leave those kinds of queries to the range request. > > The wiki really isn't clear on this point so an update is in order. > > -Ben > >> I think in the Wiki it's not clear what the two timestamps are for in a >> Snapshot Request. There also isn't a difference between an "historic" >> snapshot and a "current" snapshot, just special values for begin/end >> (0/0). At least not according to the Wiki (which is gospel as I >> understand it). >> >> I thought we were still going with the idea that the two timestamps >> create an inclusive time window. Any attribute that was updated (or >> created) within that time window was included in the snapshot, and >> others were excluded. This means that attributes updated BEFORE begin, >> and NOT within [begin,end] would not be returned. >> >> From what Ben says, it sounds like we should eventually have a single >> "at this time" timestamp value for snapshots. The only downside is that >> a single value makes it hard to have the special "current" value. In >> the interim, should we document that the "begin" value is ignored? >> >> --Rob >> >> On 04/04/2012 11:44 AM, bf...@ed... wrote: >>> This is for the historic snapshot request -- I think this has become >>> confusing because originally we thought we wanted this kind of request >>> to >>> return values that only originated in some time range, but later on we >>> realized that this was better left to the range request. The request >>> really doesn't need a start and end time. >>> >>> t6 Would capture both attributes, but at t8 only a1 is returned. Any >>> time >>> after that both a1 and a0 are expired. >>> >>> In my mind created just implies the first update, ie qeuries for that >>> URI >>> or attribute before that time would find nothing. >>> >>> -Ben >>> >>>> We're talking about a snapshot request or a range request? I thought >>>> snapshot requests were for a specific single time, but Rob mentions >>>> "begin" and "end" "below"....so for a snapshot, isn't the "begin" time >>>> irrelevant? >>>> >>>> Going on that, Ben I think two last examples would solidify your >>>> meaning >>>> (which I believe I understand)... >>>> >>>> t6? >>>> >>>> t8? >>>> >>>> >>>> >>>> >>>> Also, the words "created" and "updated" are mentioned below...but this >>>> is an event/state system. Is there any real significance to your >>>> terminology and the difference between the two terms? >>>> >>>> >>>> Doug >>>> >>>> >>>> On 4/4/12 12:48 AM, bf...@ed... wrote: >>>>> An expiration time always means that something is not valid AFTER that >>>>> point in time and items are valid at the time of their creation. >>>>> >>>>> An easy way to remember this is to imagine an item that has the same >>>>> creation and expiration dates -- it is valid for the single instant. >>>>> If >>>>> we >>>>> handled things any other way then the item would never be valid but >>>>> that >>>>> is still in the world model which, I think at least, would be >>>>> confusing. >>>>> >>>>> So, with your example: >>>>>> Let's consider this timeline: >>>>>> >>>>>> t0 - Attribute a0 is created with 1 >>>>>> >>>>>> t2 - Attribute a1 is created with 11. >>>>>> >>>>>> t4 - Attribute a1 is updated with 12. >>>>>> >>>>>> t6 - Attribute a0 is expired. >>>>>> >>>>>> t8 - Attribute a1 is expired. >>>>>> >>>>>> What is the snapshot for begin=t1, end=t2? >>>>> a0 and a1 are valid in this range, with values 1 and 11. >>>>>> What is the snapshot for begin=t3, end=t4? >>>>> The same as the previous, but a1's value is now 12. >>>>>> What is the snapshot for begin=t7, end=t9? >>>>> Both attributes are expired, nothing is returned. >>>>>> What is the snapshot for begin=t5, end=t9? >>>>> Both attributes are expired, nothing is returned. >>>>>> I think this will clear-up some confusion. >>>>> Hopefully! >>>>> -Ben >>>>>> >>>>>> --Rob >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Grailrtls-developers mailing list >>>>>> Gra...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Better than sec? Nothing is better than sec when it comes to >>>>> monitoring Big Data applications. Try Boundary one-second >>>>> resolution app monitoring today. Free. >>>>> http://p.sf.net/sfu/Boundary-dev2dev >>>>> _______________________________________________ >>>>> Grailrtls-developers mailing list >>>>> Gra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>>> >>>> >>>> >>>> -- >>>> -------------------------------------------------------- >>>> Douglas Motto >>>> dm...@cs... >>>> >>>> Systems Administrator/Programmer -- LCSR/DCS >>>> Rutgers, The State University of New Jersey >>>> -------------------------------------------------------- >>>> >>>> ------------------------------------------------------------------------------ >>>> Better than sec? Nothing is better than sec when it comes to >>>> monitoring Big Data applications. Try Boundary one-second >>>> resolution app monitoring today. Free. >>>> http://p.sf.net/sfu/Boundary-dev2dev >>>> _______________________________________________ >>>> Grailrtls-developers mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Better than sec? Nothing is better than sec when it comes to >>> monitoring Big Data applications. Try Boundary one-second >>> resolution app monitoring today. Free. >>> http://p.sf.net/sfu/Boundary-dev2dev >>> _______________________________________________ >>> Grailrtls-developers mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Grailrtls-developers mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >> > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers -- -------------------------------------------------------- Douglas Motto dm...@cs... Systems Administrator/Programmer -- LCSR/DCS Rutgers, The State University of New Jersey -------------------------------------------------------- |
|
From: <bf...@ed...> - 2012-04-04 17:42:20
|
I think that's the way to go. Probably when historic queries become easier to use we will have a better understanding of their use-cases. I think that we originally wanted an inclusive window, but I remember a long discussion at a GRAIL meeting about the logical AND of attributes if some of the attributes were created before the window and whether a URI created outside of that window was counted if those attributes were updated inside of the window. In the end we decided an inclusive window was too ambiguous and that we would leave those kinds of queries to the range request. The wiki really isn't clear on this point so an update is in order. -Ben > I think in the Wiki it's not clear what the two timestamps are for in a > Snapshot Request. There also isn't a difference between an "historic" > snapshot and a "current" snapshot, just special values for begin/end > (0/0). At least not according to the Wiki (which is gospel as I > understand it). > > I thought we were still going with the idea that the two timestamps > create an inclusive time window. Any attribute that was updated (or > created) within that time window was included in the snapshot, and > others were excluded. This means that attributes updated BEFORE begin, > and NOT within [begin,end] would not be returned. > > From what Ben says, it sounds like we should eventually have a single > "at this time" timestamp value for snapshots. The only downside is that > a single value makes it hard to have the special "current" value. In > the interim, should we document that the "begin" value is ignored? > > --Rob > > On 04/04/2012 11:44 AM, bf...@ed... wrote: >> This is for the historic snapshot request -- I think this has become >> confusing because originally we thought we wanted this kind of request >> to >> return values that only originated in some time range, but later on we >> realized that this was better left to the range request. The request >> really doesn't need a start and end time. >> >> t6 Would capture both attributes, but at t8 only a1 is returned. Any >> time >> after that both a1 and a0 are expired. >> >> In my mind created just implies the first update, ie qeuries for that >> URI >> or attribute before that time would find nothing. >> >> -Ben >> >>> We're talking about a snapshot request or a range request? I thought >>> snapshot requests were for a specific single time, but Rob mentions >>> "begin" and "end" "below"....so for a snapshot, isn't the "begin" time >>> irrelevant? >>> >>> Going on that, Ben I think two last examples would solidify your >>> meaning >>> (which I believe I understand)... >>> >>> t6? >>> >>> t8? >>> >>> >>> >>> >>> Also, the words "created" and "updated" are mentioned below...but this >>> is an event/state system. Is there any real significance to your >>> terminology and the difference between the two terms? >>> >>> >>> Doug >>> >>> >>> On 4/4/12 12:48 AM, bf...@ed... wrote: >>>> An expiration time always means that something is not valid AFTER that >>>> point in time and items are valid at the time of their creation. >>>> >>>> An easy way to remember this is to imagine an item that has the same >>>> creation and expiration dates -- it is valid for the single instant. >>>> If >>>> we >>>> handled things any other way then the item would never be valid but >>>> that >>>> is still in the world model which, I think at least, would be >>>> confusing. >>>> >>>> So, with your example: >>>>> Let's consider this timeline: >>>>> >>>>> t0 - Attribute a0 is created with 1 >>>>> >>>>> t2 - Attribute a1 is created with 11. >>>>> >>>>> t4 - Attribute a1 is updated with 12. >>>>> >>>>> t6 - Attribute a0 is expired. >>>>> >>>>> t8 - Attribute a1 is expired. >>>>> >>>>> What is the snapshot for begin=t1, end=t2? >>>> a0 and a1 are valid in this range, with values 1 and 11. >>>>> What is the snapshot for begin=t3, end=t4? >>>> The same as the previous, but a1's value is now 12. >>>>> What is the snapshot for begin=t7, end=t9? >>>> Both attributes are expired, nothing is returned. >>>>> What is the snapshot for begin=t5, end=t9? >>>> Both attributes are expired, nothing is returned. >>>>> I think this will clear-up some confusion. >>>> Hopefully! >>>> -Ben >>>>> >>>>> --Rob >>>>> >>>>> >>>>> _______________________________________________ >>>>> Grailrtls-developers mailing list >>>>> Gra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Better than sec? Nothing is better than sec when it comes to >>>> monitoring Big Data applications. Try Boundary one-second >>>> resolution app monitoring today. Free. >>>> http://p.sf.net/sfu/Boundary-dev2dev >>>> _______________________________________________ >>>> Grailrtls-developers mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>> >>> >>> >>> -- >>> -------------------------------------------------------- >>> Douglas Motto >>> dm...@cs... >>> >>> Systems Administrator/Programmer -- LCSR/DCS >>> Rutgers, The State University of New Jersey >>> -------------------------------------------------------- >>> >>> ------------------------------------------------------------------------------ >>> Better than sec? Nothing is better than sec when it comes to >>> monitoring Big Data applications. Try Boundary one-second >>> resolution app monitoring today. Free. >>> http://p.sf.net/sfu/Boundary-dev2dev >>> _______________________________________________ >>> Grailrtls-developers mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>> >> >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Grailrtls-developers mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > |
|
From: Robert M. <ro...@cs...> - 2012-04-04 17:24:15
|
I think in the Wiki it's not clear what the two timestamps are for in a Snapshot Request. There also isn't a difference between an "historic" snapshot and a "current" snapshot, just special values for begin/end (0/0). At least not according to the Wiki (which is gospel as I understand it). I thought we were still going with the idea that the two timestamps create an inclusive time window. Any attribute that was updated (or created) within that time window was included in the snapshot, and others were excluded. This means that attributes updated BEFORE begin, and NOT within [begin,end] would not be returned. From what Ben says, it sounds like we should eventually have a single "at this time" timestamp value for snapshots. The only downside is that a single value makes it hard to have the special "current" value. In the interim, should we document that the "begin" value is ignored? --Rob On 04/04/2012 11:44 AM, bf...@ed... wrote: > This is for the historic snapshot request -- I think this has become > confusing because originally we thought we wanted this kind of request to > return values that only originated in some time range, but later on we > realized that this was better left to the range request. The request > really doesn't need a start and end time. > > t6 Would capture both attributes, but at t8 only a1 is returned. Any time > after that both a1 and a0 are expired. > > In my mind created just implies the first update, ie qeuries for that URI > or attribute before that time would find nothing. > > -Ben > >> We're talking about a snapshot request or a range request? I thought >> snapshot requests were for a specific single time, but Rob mentions >> "begin" and "end" "below"....so for a snapshot, isn't the "begin" time >> irrelevant? >> >> Going on that, Ben I think two last examples would solidify your meaning >> (which I believe I understand)... >> >> t6? >> >> t8? >> >> >> >> >> Also, the words "created" and "updated" are mentioned below...but this >> is an event/state system. Is there any real significance to your >> terminology and the difference between the two terms? >> >> >> Doug >> >> >> On 4/4/12 12:48 AM, bf...@ed... wrote: >>> An expiration time always means that something is not valid AFTER that >>> point in time and items are valid at the time of their creation. >>> >>> An easy way to remember this is to imagine an item that has the same >>> creation and expiration dates -- it is valid for the single instant. If >>> we >>> handled things any other way then the item would never be valid but that >>> is still in the world model which, I think at least, would be confusing. >>> >>> So, with your example: >>>> Let's consider this timeline: >>>> >>>> t0 - Attribute a0 is created with 1 >>>> >>>> t2 - Attribute a1 is created with 11. >>>> >>>> t4 - Attribute a1 is updated with 12. >>>> >>>> t6 - Attribute a0 is expired. >>>> >>>> t8 - Attribute a1 is expired. >>>> >>>> What is the snapshot for begin=t1, end=t2? >>> a0 and a1 are valid in this range, with values 1 and 11. >>>> What is the snapshot for begin=t3, end=t4? >>> The same as the previous, but a1's value is now 12. >>>> What is the snapshot for begin=t7, end=t9? >>> Both attributes are expired, nothing is returned. >>>> What is the snapshot for begin=t5, end=t9? >>> Both attributes are expired, nothing is returned. >>>> I think this will clear-up some confusion. >>> Hopefully! >>> -Ben >>>> >>>> --Rob >>>> >>>> >>>> _______________________________________________ >>>> Grailrtls-developers mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Better than sec? Nothing is better than sec when it comes to >>> monitoring Big Data applications. Try Boundary one-second >>> resolution app monitoring today. Free. >>> http://p.sf.net/sfu/Boundary-dev2dev >>> _______________________________________________ >>> Grailrtls-developers mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >> >> >> >> -- >> -------------------------------------------------------- >> Douglas Motto >> dm...@cs... >> >> Systems Administrator/Programmer -- LCSR/DCS >> Rutgers, The State University of New Jersey >> -------------------------------------------------------- >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Grailrtls-developers mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >> > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers |
|
From: <bf...@ed...> - 2012-04-04 15:44:53
|
This is for the historic snapshot request -- I think this has become confusing because originally we thought we wanted this kind of request to return values that only originated in some time range, but later on we realized that this was better left to the range request. The request really doesn't need a start and end time. t6 Would capture both attributes, but at t8 only a1 is returned. Any time after that both a1 and a0 are expired. In my mind created just implies the first update, ie qeuries for that URI or attribute before that time would find nothing. -Ben > We're talking about a snapshot request or a range request? I thought > snapshot requests were for a specific single time, but Rob mentions > "begin" and "end" "below"....so for a snapshot, isn't the "begin" time > irrelevant? > > Going on that, Ben I think two last examples would solidify your meaning > (which I believe I understand)... > > t6? > > t8? > > > > > Also, the words "created" and "updated" are mentioned below...but this > is an event/state system. Is there any real significance to your > terminology and the difference between the two terms? > > > Doug > > > On 4/4/12 12:48 AM, bf...@ed... wrote: >> An expiration time always means that something is not valid AFTER that >> point in time and items are valid at the time of their creation. >> >> An easy way to remember this is to imagine an item that has the same >> creation and expiration dates -- it is valid for the single instant. If >> we >> handled things any other way then the item would never be valid but that >> is still in the world model which, I think at least, would be confusing. >> >> So, with your example: >>> Let's consider this timeline: >>> >>> t0 - Attribute a0 is created with 1 >>> >>> t2 - Attribute a1 is created with 11. >>> >>> t4 - Attribute a1 is updated with 12. >>> >>> t6 - Attribute a0 is expired. >>> >>> t8 - Attribute a1 is expired. >>> >>> What is the snapshot for begin=t1, end=t2? >> a0 and a1 are valid in this range, with values 1 and 11. >>> What is the snapshot for begin=t3, end=t4? >> The same as the previous, but a1's value is now 12. >>> What is the snapshot for begin=t7, end=t9? >> Both attributes are expired, nothing is returned. >>> What is the snapshot for begin=t5, end=t9? >> Both attributes are expired, nothing is returned. >>> I think this will clear-up some confusion. >> Hopefully! >> -Ben >>> >>> --Rob >>> >>> >>> _______________________________________________ >>> Grailrtls-developers mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >>> >> >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Grailrtls-developers mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > > > > -- > -------------------------------------------------------- > Douglas Motto > dm...@cs... > > Systems Administrator/Programmer -- LCSR/DCS > Rutgers, The State University of New Jersey > -------------------------------------------------------- > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > |
|
From: Douglas M. <dm...@cs...> - 2012-04-04 11:50:58
|
We're talking about a snapshot request or a range request? I thought snapshot requests were for a specific single time, but Rob mentions "begin" and "end" "below"....so for a snapshot, isn't the "begin" time irrelevant? Going on that, Ben I think two last examples would solidify your meaning (which I believe I understand)... t6? t8? Also, the words "created" and "updated" are mentioned below...but this is an event/state system. Is there any real significance to your terminology and the difference between the two terms? Doug On 4/4/12 12:48 AM, bf...@ed... wrote: > An expiration time always means that something is not valid AFTER that > point in time and items are valid at the time of their creation. > > An easy way to remember this is to imagine an item that has the same > creation and expiration dates -- it is valid for the single instant. If we > handled things any other way then the item would never be valid but that > is still in the world model which, I think at least, would be confusing. > > So, with your example: >> Let's consider this timeline: >> >> t0 - Attribute a0 is created with 1 >> >> t2 - Attribute a1 is created with 11. >> >> t4 - Attribute a1 is updated with 12. >> >> t6 - Attribute a0 is expired. >> >> t8 - Attribute a1 is expired. >> >> What is the snapshot for begin=t1, end=t2? > a0 and a1 are valid in this range, with values 1 and 11. >> What is the snapshot for begin=t3, end=t4? > The same as the previous, but a1's value is now 12. >> What is the snapshot for begin=t7, end=t9? > Both attributes are expired, nothing is returned. >> What is the snapshot for begin=t5, end=t9? > Both attributes are expired, nothing is returned. >> I think this will clear-up some confusion. > Hopefully! > -Ben >> >> --Rob >> >> >> _______________________________________________ >> Grailrtls-developers mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/grailrtls-developers >> > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers -- -------------------------------------------------------- Douglas Motto dm...@cs... Systems Administrator/Programmer -- LCSR/DCS Rutgers, The State University of New Jersey -------------------------------------------------------- |
|
From: <bf...@ed...> - 2012-04-04 05:33:02
|
An expiration time always means that something is not valid AFTER that point in time and items are valid at the time of their creation. An easy way to remember this is to imagine an item that has the same creation and expiration dates -- it is valid for the single instant. If we handled things any other way then the item would never be valid but that is still in the world model which, I think at least, would be confusing. So, with your example: > Let's consider this timeline: > > t0 - Attribute a0 is created with 1 > > t2 - Attribute a1 is created with 11. > > t4 - Attribute a1 is updated with 12. > > t6 - Attribute a0 is expired. > > t8 - Attribute a1 is expired. > > What is the snapshot for begin=t1, end=t2? a0 and a1 are valid in this range, with values 1 and 11. > What is the snapshot for begin=t3, end=t4? The same as the previous, but a1's value is now 12. > What is the snapshot for begin=t7, end=t9? Both attributes are expired, nothing is returned. > What is the snapshot for begin=t5, end=t9? Both attributes are expired, nothing is returned. > I think this will clear-up some confusion. Hopefully! -Ben > > --Rob > > > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > |
|
From: Robert M. <ro...@cs...> - 2012-04-03 20:25:57
|
John has been working on the Mongo-based WM implementation for a while, and there are some questions about the two timestamps in the Snapshot Request message. From the Wiki: Snapshot: + Begin Time: An 8 byte signed integer specifying the time of the earliest URIs and attributes to capture in this snapshot. + End Time: An 8 byte signed integer specifying the time of the latest URIs and attributes to capture in this snapshot. Let's consider this timeline: t0 - Attribute a0 is created with 1 t2 - Attribute a1 is created with 11. t4 - Attribute a1 is updated with 12. t6 - Attribute a0 is expired. t8 - Attribute a1 is expired. What is the snapshot for begin=t1, end=t2? What is the snapshot for begin=t3, end=t4? What is the snapshot for begin=t7, end=t9? What is the snapshot for begin=t5, end=t9? I think this will clear-up some confusion. --Rob |
|
From: Robert M. <ro...@cs...> - 2012-03-06 15:45:52
|
Hi all, Now that we're gearing-up for the Octopus release, it might be a good time to nail down exactly what's going out and what's going into a future release (or at least planned for the future). Here's what I understand is going to be provided in the upcoming version 3 (Octopus) release of GRAIL. Please correct the list if I made a mistake. --Rob Octopus - GRAIL version 3 + New Features - Aggregator/World Model abstractions - Network API - Java/C++/Ruby libraries - Simple service discovery model - Transient data Sugar Maple - GRAIL version next (3.1?) + Proposed Changes/Features - Aggregator subscriptions with cancellation - RSSI moved to data segment of samples - Support for relay chains in sample format - Actuation via the World Model - Access Control/Privacy - Distributed World Model |
|
From: Robert M. <ro...@cs...> - 2012-03-02 16:01:55
|
Hi everyone, Ben and I have been working on standardizing the 3 API libraries for the world model (C++, Ruby, and Java) based on developer feedback in the Users Group meetings at Rutgers. Over the next few weeks, we hope to have (finally!) a stable release of grail and some new APIs to simplify interaction with the components. Here's Ben's email from the Users Group mailing list: --Rob -------- Original Message -------- Subject: Documenting the standardized API Date: Thu, 1 Mar 2012 From: bf...@ed... I've started documenting the standardized API here: https://sourceforge.net/apps/mediawiki/grailrtls/index.php?title=Writing_an_Application I just plan to have short examples on this page. Since it's linked from the main page I just want it to have very quick examples so that someone can see that using the system isn't scary. More detailed documentation will go into a tutorials section. -Ben |
|
From: <bf...@ed...> - 2012-02-08 02:32:53
|
Hello everyone,
If you're developing a world model with some other database type I've made
an abstract class to inherit from in
grail-solvers/include/world_model.hpp.
The previous world model version (the one that uses sqlite) is now in
sqlite3_world_model.{cpp,hpp}. If you write another world model
implementation you should inherit from the base world model defined in
world_model.hpp and add code into grail-solvers/src/test_world_model.cpp
to allow everyone to select your world model implementation. Please use
that program to test your world model as well.
Basically the test program has these variables:
std::function<WorldModel* (std::string)> makeWM;
//Define different factories for world models here
std::function<WorldModel* (std::string)> make_sql_wm = [](std::string
dbname) {
return new SQLite3WorldModel(dbname);
};
The first is the function that's going to be used to make the world model
during testing. The second function creates a SQLite3WorldModel. Once
there are more world models we can add a command line option for the user
to select which one they want and we can assign the appropriate creation
function to the makeWM variable:
//Set the selected world model factory to the sqlite world model
makeWM = make_sql_wm;
This allows us to test the different databases and compare performance.
Speaking of performance, the sqlite world model should start quickly now.
It's slow during operation mainly because of a thread contention problem -
basically sqlite likes to block for very long amounts of time when doing
some queries and inserts. I'm going to implement the world model functions
as non-blocking calls that defer execution of insertions to another
thread. Everyone else should think about this performance issue as well.
-Ben
|
|
From: Robert M. <ro...@cs...> - 2012-02-03 22:48:20
|
Hi guys, Seems I didn't push the tag to SF.net earlier, so I remarked RC2 in the source repo (you may have seen the enormous commit log). I'm uploading the files to SF.net now. They're staged for 3 days so we can get things organized a bit before they're public. --Rob |
|
From: <bf...@ed...> - 2012-01-31 21:32:12
|
I think it's a thread related issue. I tried to make sure that a thread couldn't block the world model server but I probably messed up it's memory management. I think that the solution is for me to rewrite the ThreadConnection class more seriously rather than trying for a quick fix like I did. -Ben > Looks like the latest version of the world model might have a > memory-related issue. This was taken from the log on one of the crash > boxes: > > Inserting solution open for URI window.0. > Message id is 4 > Received a solver data message. > Inserting solution open for URI window.0. > *** glibc detected *** ./bin/world_model_server: double free or > corruption (fasttop): 0xacb4b800 *** > ======= Backtrace: ========= > /lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0x2c6bc2] > /lib/i386-linux-gnu/libc.so.6(+0x6f862)[0x2c7862] > /lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0x2ca94d] > /usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x1f)[0xeb780f] > ./bin/world_model_server[0x804afcb] > ./bin/world_model_server[0x8055c0b] > ./bin/world_model_server[0x8063007] > ./bin/world_model_server[0x806a606] > ./bin/world_model_server[0x805ad3d] > ./bin/world_model_server[0x805b0bc] > ./bin/world_model_server[0x805a86b] > /usr/lib/i386-linux-gnu/libstdc++.so.6(__once_proxy+0x1d)[0xe678dd] > /lib/i386-linux-gnu/libpthread.so.0(__pthread_once+0x90)[0x962f50] > ./bin/world_model_server[0x805b2b1] > /usr/lib/i386-linux-gnu/libstdc++.so.6(+0x5db67)[0xe67b67] > /lib/i386-linux-gnu/libpthread.so.0(+0x6d31)[0x95dd31] > /lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0x32a0ce] > ======= Memory map: ======== > 001b6000-00254000 r-xp 00000000 08:01 16130 > /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 > 00254000-00255000 ---p 0009e000 08:01 16130 > /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 > 00255000-00256000 r--p 0009e000 08:01 16130 > /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 > 00256000-00257000 rw-p 0009f000 08:01 16130 > /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 > 00257000-00258000 rw-p 00000000 00:00 0 > 00258000-003ce000 r-xp 00000000 08:01 143328 > /lib/i386-linux-gnu/libc-2.13.so > 003ce000-003d0000 r--p 00176000 08:01 143328 > /lib/i386-linux-gnu/libc-2.13.so > 003d0000-003d1000 rw-p 00178000 08:01 143328 > /lib/i386-linux-gnu/libc-2.13.so > 003d1000-003d4000 rw-p 00000000 00:00 0 > 005b5000-005b6000 r-xp 00000000 00:00 0 [vdso] > 005ff000-0061d000 r-xp 00000000 08:01 130380 > /lib/i386-linux-gnu/ld-2.13.so > 0061d000-0061e000 r--p 0001d000 08:01 130380 > /lib/i386-linux-gnu/ld-2.13.so > 0061e000-0061f000 rw-p 0001e000 08:01 130380 > /lib/i386-linux-gnu/ld-2.13.so > 00737000-0075f000 r-xp 00000000 08:01 143333 > /lib/i386-linux-gnu/libm-2.13.so > 0075f000-00760000 r--p 00028000 08:01 143333 > /lib/i386-linux-gnu/libm-2.13.so > 00760000-00761000 rw-p 00029000 08:01 143333 > /lib/i386-linux-gnu/libm-2.13.so > 00957000-0096e000 r-xp 00000000 08:01 143343 > /lib/i386-linux-gnu/libpthread-2.13.so > 0096e000-0096f000 r--p 00016000 08:01 143343 > /lib/i386-linux-gnu/libpthread-2.13.so > 0096f000-00970000 rw-p 00017000 08:01 143343 > /lib/i386-linux-gnu/libpthread-2.13.so > 00970000-00972000 rw-p 00000000 00:00 0 > 00991000-00994000 r-xp 00000000 08:01 143331 > /lib/i386-linux-gnu/libdl-2.13.so > 00994000-00995000 r--p 00002000 08:01 143331 > /lib/i386-linux-gnu/libdl-2.13.so > 00995000-00996000 rw-p 00003000 08:01 143331 > /lib/i386-linux-gnu/libdl-2.13.so > 00af5000-00b11000 r-xp 00000000 08:01 130693 > /lib/i386-linux-gnu/libgcc_s.so.1 > 00b11000-00b12000 r--p 0001b000 08:01 130693 > /lib/i386-linux-gnu/libgcc_s.so.1 > 00b12000-00b13000 rw-p 0001c000 08:01 130693 > /lib/i386-linux-gnu/libgcc_s.so.1 > 00e0a000-00ee8000 r-xp 00000000 08:01 13 > /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16 > 00ee8000-00ee9000 ---p 000de000 08:01 13 > /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16 > 00ee9000-00eed000 r--p 000de000 08:01 13 > /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16 > 00eed000-00eee000 rw-p 000e2000 08:01 13 > /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16 > 00eee000-00ef5000 rw-p 00000000 00:00 0 > 08048000-08083000 r-xp 00000000 08:06 1966862 > /home/grail/grailrtls/grail-solvers/bin/world_model_server > 08083000-08084000 r--p 0003a000 08:06 1966862 > /home/grail/grailrtls/grail-solvers/bin/world_model_server > 08084000-08085000 rw-p 0003b000 08:06 1966862 > /home/grail/grailrtls/grail-solvers/bin/world_model_server > 09dbb000-0a178000 rw-p 00000000 00:00 0 [heap] > a4af0000-a4af1000 ---p 00000000 00:00 0 > a4af1000-a52f1000 rw-p 00000000 00:00 0 > acb00000-acb88000 rw-p 00000000 00:00 0 > acb88000-acc00000 ---p 00000000 00:00 0 > b1cfc000-b1cfd000 ---p 00000000 00:00 0 > b1cfd000-b24fd000 rw-p 00000000 00:00 0 > b24fd000-b24fe000 ---p 00000000 00:00 0 > b24fe000-b2cfe000 rw-p 00000000 00:00 0 > b3900000-b3927000 rw-p 00000000 00:00 0 > b3927000-b3a00000 ---p 00000000 00:00 0 > b3a00000-b3a27000 rw-p 00000000 00:00 0 > b3a27000-b3b00000 ---p 00000000 00:00 0 > b3b00000-b3b25000 rw-p 00000000 00:00 0 > b3b25000-b3c00000 ---p 00000000 00:00 0 > b3c00000-b3cf4000 rw-p 00000000 00:00 0 > b3cf4000-b3d00000 ---p 00000000 00:00 0 > b3d00000-b3e00000 rw-p 00000000 00:00 0 > b3efe000-b3eff000 ---p 00000000 00:00 0 > b3eff000-b46ff000 rw-p 00000000 00:00 0 > b46ff000-b4700000 ---p 00000000 00:00 0 > b4700000-b4f00000 rw-p 00000000 00:00 0 > b4f00000-b4fff000 rw-p 00000000 00:00 0 > b4fff000-b5000000 ---p 00000000 00:00 0 > b5000000-b507e000 rw-p 00000000 00:00 0 > b507e000-b5100000 ---p 00000000 00:00 0 > b5100000-b5200000 rw-p 00000000 00:00 0 > b5200000-b5400000 rw-p 00000000 00:00 0 > b5400000-b5500000 rw-p 00000000 00:00 0 > b5600000-b5700000 rw-p 00000000 00:00 0 > b5711000-b5712000 ---p 00000000 00:00 0 > b5712000-b5f12000 rw-p 00000000 00:00 0 > b5f12000-b5f13000 ---p 00000000 00:00 0 > b5f13000-b6713000 rw-p 00000000 00:00 0 > b6713000-b6714000 ---p 00000000 00:00 0 > b6714000-b6f14000 rw-p 00000000 00:00 0 > b6f14000-b6f15000 ---p 00000000 00:00 0 > b6f15000-b7719000 rw-p 00000000 00:00 0 > b7719000-b7721000 rw-s 00000000 08:06 1966872 > /home/grail/grailrtls/grail-solvers/world_model.db-shm > b7721000-b7724000 rw-p 00000000 00:00 0 > bfb17000-bfb38000 rw-p 00000000 00:00 0 [stack] > > --Rob > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Grailrtls-developers mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/grailrtls-developers > |
|
From: Robert M. <ro...@cs...> - 2012-01-31 20:15:37
|
Looks like the latest version of the world model might have a memory-related issue. This was taken from the log on one of the crash boxes: Inserting solution open for URI window.0. Message id is 4 Received a solver data message. Inserting solution open for URI window.0. *** glibc detected *** ./bin/world_model_server: double free or corruption (fasttop): 0xacb4b800 *** ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0x2c6bc2] /lib/i386-linux-gnu/libc.so.6(+0x6f862)[0x2c7862] /lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0x2ca94d] /usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x1f)[0xeb780f] ./bin/world_model_server[0x804afcb] ./bin/world_model_server[0x8055c0b] ./bin/world_model_server[0x8063007] ./bin/world_model_server[0x806a606] ./bin/world_model_server[0x805ad3d] ./bin/world_model_server[0x805b0bc] ./bin/world_model_server[0x805a86b] /usr/lib/i386-linux-gnu/libstdc++.so.6(__once_proxy+0x1d)[0xe678dd] /lib/i386-linux-gnu/libpthread.so.0(__pthread_once+0x90)[0x962f50] ./bin/world_model_server[0x805b2b1] /usr/lib/i386-linux-gnu/libstdc++.so.6(+0x5db67)[0xe67b67] /lib/i386-linux-gnu/libpthread.so.0(+0x6d31)[0x95dd31] /lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0x32a0ce] ======= Memory map: ======== 001b6000-00254000 r-xp 00000000 08:01 16130 /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 00254000-00255000 ---p 0009e000 08:01 16130 /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 00255000-00256000 r--p 0009e000 08:01 16130 /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 00256000-00257000 rw-p 0009f000 08:01 16130 /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 00257000-00258000 rw-p 00000000 00:00 0 00258000-003ce000 r-xp 00000000 08:01 143328 /lib/i386-linux-gnu/libc-2.13.so 003ce000-003d0000 r--p 00176000 08:01 143328 /lib/i386-linux-gnu/libc-2.13.so 003d0000-003d1000 rw-p 00178000 08:01 143328 /lib/i386-linux-gnu/libc-2.13.so 003d1000-003d4000 rw-p 00000000 00:00 0 005b5000-005b6000 r-xp 00000000 00:00 0 [vdso] 005ff000-0061d000 r-xp 00000000 08:01 130380 /lib/i386-linux-gnu/ld-2.13.so 0061d000-0061e000 r--p 0001d000 08:01 130380 /lib/i386-linux-gnu/ld-2.13.so 0061e000-0061f000 rw-p 0001e000 08:01 130380 /lib/i386-linux-gnu/ld-2.13.so 00737000-0075f000 r-xp 00000000 08:01 143333 /lib/i386-linux-gnu/libm-2.13.so 0075f000-00760000 r--p 00028000 08:01 143333 /lib/i386-linux-gnu/libm-2.13.so 00760000-00761000 rw-p 00029000 08:01 143333 /lib/i386-linux-gnu/libm-2.13.so 00957000-0096e000 r-xp 00000000 08:01 143343 /lib/i386-linux-gnu/libpthread-2.13.so 0096e000-0096f000 r--p 00016000 08:01 143343 /lib/i386-linux-gnu/libpthread-2.13.so 0096f000-00970000 rw-p 00017000 08:01 143343 /lib/i386-linux-gnu/libpthread-2.13.so 00970000-00972000 rw-p 00000000 00:00 0 00991000-00994000 r-xp 00000000 08:01 143331 /lib/i386-linux-gnu/libdl-2.13.so 00994000-00995000 r--p 00002000 08:01 143331 /lib/i386-linux-gnu/libdl-2.13.so 00995000-00996000 rw-p 00003000 08:01 143331 /lib/i386-linux-gnu/libdl-2.13.so 00af5000-00b11000 r-xp 00000000 08:01 130693 /lib/i386-linux-gnu/libgcc_s.so.1 00b11000-00b12000 r--p 0001b000 08:01 130693 /lib/i386-linux-gnu/libgcc_s.so.1 00b12000-00b13000 rw-p 0001c000 08:01 130693 /lib/i386-linux-gnu/libgcc_s.so.1 00e0a000-00ee8000 r-xp 00000000 08:01 13 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16 00ee8000-00ee9000 ---p 000de000 08:01 13 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16 00ee9000-00eed000 r--p 000de000 08:01 13 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16 00eed000-00eee000 rw-p 000e2000 08:01 13 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16 00eee000-00ef5000 rw-p 00000000 00:00 0 08048000-08083000 r-xp 00000000 08:06 1966862 /home/grail/grailrtls/grail-solvers/bin/world_model_server 08083000-08084000 r--p 0003a000 08:06 1966862 /home/grail/grailrtls/grail-solvers/bin/world_model_server 08084000-08085000 rw-p 0003b000 08:06 1966862 /home/grail/grailrtls/grail-solvers/bin/world_model_server 09dbb000-0a178000 rw-p 00000000 00:00 0 [heap] a4af0000-a4af1000 ---p 00000000 00:00 0 a4af1000-a52f1000 rw-p 00000000 00:00 0 acb00000-acb88000 rw-p 00000000 00:00 0 acb88000-acc00000 ---p 00000000 00:00 0 b1cfc000-b1cfd000 ---p 00000000 00:00 0 b1cfd000-b24fd000 rw-p 00000000 00:00 0 b24fd000-b24fe000 ---p 00000000 00:00 0 b24fe000-b2cfe000 rw-p 00000000 00:00 0 b3900000-b3927000 rw-p 00000000 00:00 0 b3927000-b3a00000 ---p 00000000 00:00 0 b3a00000-b3a27000 rw-p 00000000 00:00 0 b3a27000-b3b00000 ---p 00000000 00:00 0 b3b00000-b3b25000 rw-p 00000000 00:00 0 b3b25000-b3c00000 ---p 00000000 00:00 0 b3c00000-b3cf4000 rw-p 00000000 00:00 0 b3cf4000-b3d00000 ---p 00000000 00:00 0 b3d00000-b3e00000 rw-p 00000000 00:00 0 b3efe000-b3eff000 ---p 00000000 00:00 0 b3eff000-b46ff000 rw-p 00000000 00:00 0 b46ff000-b4700000 ---p 00000000 00:00 0 b4700000-b4f00000 rw-p 00000000 00:00 0 b4f00000-b4fff000 rw-p 00000000 00:00 0 b4fff000-b5000000 ---p 00000000 00:00 0 b5000000-b507e000 rw-p 00000000 00:00 0 b507e000-b5100000 ---p 00000000 00:00 0 b5100000-b5200000 rw-p 00000000 00:00 0 b5200000-b5400000 rw-p 00000000 00:00 0 b5400000-b5500000 rw-p 00000000 00:00 0 b5600000-b5700000 rw-p 00000000 00:00 0 b5711000-b5712000 ---p 00000000 00:00 0 b5712000-b5f12000 rw-p 00000000 00:00 0 b5f12000-b5f13000 ---p 00000000 00:00 0 b5f13000-b6713000 rw-p 00000000 00:00 0 b6713000-b6714000 ---p 00000000 00:00 0 b6714000-b6f14000 rw-p 00000000 00:00 0 b6f14000-b6f15000 ---p 00000000 00:00 0 b6f15000-b7719000 rw-p 00000000 00:00 0 b7719000-b7721000 rw-s 00000000 08:06 1966872 /home/grail/grailrtls/grail-solvers/world_model.db-shm b7721000-b7724000 rw-p 00000000 00:00 0 bfb17000-bfb38000 rw-p 00000000 00:00 0 [stack] --Rob |
![http://eden.rutgers.edu/~romoore/core2.jpg"](http://eden.rutgers.edu/~romoore/core2.jpg"){kind=link}