I'm running rrdtool 1.5.4 (currently in Debian Sid repos and the latest version to be found) on my Sid desktop and my Stable server. I would like to use some of the features the manpages - which mention the same version - and the in-application help advertise, but they simply don't appear to work.
Specifically, I'm talking about the --source option to rrdtool create and the --step option to rrdtool tune; furthermore, I would like to modify RRAs with rrdtool tune.
The options, however, simply throw ERROR: unknown option, despite appearing no different from others on the author's github, to be found here: https://github.com/oetiker/rrdtool-1.x under src/rrd_create and rrd_tune, respectively.
If I issue one of the RRA operations with rrdtool tune, say rrdtool tune t.rrd RRA:MAX:0.5:10:10 on an empty RRD, I get exactly the same output as when just running rrdtool tune t.rrd.
Background: I have several hundred RRD files from when I was still learning the concept that are badly configured, and I'd like to either modify them with tune or migrate them to a new RRD with --source. I'm aware of rrdjig, by the way, but have so far been unsuccessful in its use, and the --source option appears to be its intended, more stable replacement.
Found the answer. Apparently, it needs on librrd4 in the same version as the binary to provide all functions, and since it's a Stable system and I don't think rrdtool explicitly specifies the library version it wants, apt-get thought the 1.4.8 from Stable was enough.
Related
First time manage document using dls:document-insert-and-manage
Update the same document using xdmp:document-insert
Document get lost from the dls latest version collection cts:search(/scopedIntervention/id , dls:documents-query())
First time manage document
<scopedIntervention>
<id>someId12345</id>
<scopedInterventionName>
First Name
</scopedInterventionName>
<forTestOnly>
true
</forTestOnly>
<inactive>
true
</inactive>
</scopedIntervention>)```
**Document inserted with versioning**
Verify document is present in latest documents collection
cts:search(/scopedIntervention/id , dls:documents-query())
Document present in managed latest collection
Update the same document
<scopedIntervention>
<id>someId12345</id>
<scopedInterventionName>
Updated Name
</scopedInterventionName>
<forTestOnly>
true
</forTestOnly>
<inactive>
true
</inactive>
</scopedIntervention>)```
**Update document to same URI using xdmp:document-insert**
Again verify document is present or NOT in latest documents collection
cts:search(/scopedIntervention/id , dls:documents-query())
Document NOT present in managed latest collection (lost from collection)
After applying DLS package using following upgrade step, the same document shows in the list
```xquery version "1.0-ml";
import module namespace dls = "http://marklogic.com/xdmp/dls"
at "/MarkLogic/dls.xqy";
dls:set-upgrade-status(fn:false()),
dls:start-upgrade(),
fn:doc("http://marklogic.com/dls/upgrade-task-status.xml"),
dls:latest-validation-results(),
dls:set-upgrade-status(fn:true())```
Update the same document using xdmp:document-insert
You are most likely removing the DLS Latest collection at this step. Further, version history is not preserved when you do this.
Instead of using xdmp:document-insert you should use dls:document-checkout-update-checkin .
Please read to the end -- if you did NOT do a DLS Upgrade on an upgraded ML version - STOP NOW and follow the upgrade instructions. Not doing so will leave DLS in a unstable state and anything else you do will make things much harder to repair.
+1 Rob. #IAM, reguardless of if it 'worked' or appeared to 'work' in V7, dls was not designed to handle the case you describe. DLS architecture depends on encapsulating all changes to documents within the checkin/checkout semantics. Bypassing that, you might as well bypass DLS entirely because it wont work. The fact that it was 'working' in V7 is a misnomer, it may have not behaved incorrectly in ways that your application cared about, or your code may have coincidentally done sufficiently similar work as the internals. You might get lucky and find a way to do so again, but I encourage you to consider how to work within the define behaviour of the library, or to refactor out those parts of your code that are not 'DLS Friendly' to operate between checkout/checkin windows -- not all updates have to be the checkout-update-checkin -- you can checkout -- do whatever -- then checkin.
As a migration workaround you MIGHT be able to make use of the upgrade functions added to dls on an ongoing basis.
See https://docs.marklogic.com/dls:start-upgrade
In V9 (I believe), significant non-backwards compatible changes were made to DLS internals that require running this code. one time
The assumption was as in-place update from prior DLS to current. However the code may also happen to work on an ongoing basis, depending on the details of exactly what your application code is doing that the DLS code doesn't know about.
The 'new' DLS code adds an internal collection to optimize the common case of searching for 'latest' documents -- if that is dropped then those documents will not show up on DLS searches (for 'latest').
You mention your code is 'migration scripts' --> If these are migrating from V7 to V10 then you could run your code before the V10 update, then run the V10 update then run the dls-upgrade. After that the documents should be in good shape -- as long as you don't do anything else that is not defined behaviour for managed documents.
I want to make sure that the drive I'm currently installing to is a certain format (e.g. NTFS, exFAT, FAT32, etc.). I was thinking there might be a condition I can check or something before installing.
Since I can't check the install format with conditions, is there some other approach I can take in order to get this?
There isn't a standard property that denotes this, in the list here:
https://learn.microsoft.com/en-us/windows/desktop/msi/property-reference
The difficulty is that there might be a variety of drive formats on the system and the check can't be made until the user browses for an install location which might be one type or another. Visual Studio setups don't support running code when that install location has been chosen.
Is there an underlying problem (perhaps with the app) that this is attempting to solve?
Is tf.py_func allowed at online prediction time?
If yes any examples of how to use it?
Does the answer change if I need to install additional pip packages?
My use-case: I work with text, I need to do word stemming (using porter stemmer), I know how to do it using python, tensorflow doesn't have Ops for that. I would like to use the same text processing at training and prediction time - thus I would like to encode it all into a tensorflow graph.
https://www.tensorflow.org/api_docs/python/tf/py_func comes with known limitations and I would like to know if it will work during training and online prediction before I invest more time into it.
Thanks
Unfortunately, no. Py_func can not be restored from a saved model. However, since your use case involves pre-processing, just invoke the py_func explicitly in all three (train, eval, serving) input functions. This won't work if the py_func is in the middle of your graph, but for stemming, it should work just fine.
Im learning RRDtool. I created a graph:
#!/bin/bash
rrdtool graph /home/pi/rrd/test.png \
--end now --start now-6000s --width 500 --height 400 \
DEF:ds0a=/home/pi/rrd/temperature.rrd:temperature:AVERAGE \
AREA:ds0a#0000FF:"Temperature ('C)\l" \
It looks like this:
How can I format scale to add fractional part?
I want 25.2, 25.4, 25.6 etc. instead of 25 few times.
I have tried option from RRDtool documentation online
--left-axis-format
but my RRDtool has no such option.
There is no problem with
--right-axis-format
it works as I want, but... I want correct format on left side, not right.
Im using 1.4.7 on Raspberry Pi. I was asking on unix.stackexchange.com about this, but there are more questions about RRDtool here, so I moved my question here.
Later versions of RRDTool handle the axis labelling a bit better than earlier ones, so an upgrade might be all that is needed to fix it.
The first thing to try is --alt-y-grid option which changes the default way the Y-axis labels are placed. This might solve your issue.
You can override the automatic Y-axis calculations using something like --y-grid 0.2:5 which will put a tick every 0.2 but only label every 5 ticks, IE at 25, 26, 27 and so on. This will give you a sane but sparsely populated Y-axis.
However, maybe you want a label at every line, but including the decimals. In this case, you can specify the formatting of the Y-axis labels to include a decimal place: --left-axis-format "%.1lf" . You say that your version does not support this, so you might like to consider upgrading.
I've installed rrdtool 1.4.8 on Raspbian using the testing branch. Unfortunately, the --left-axis-format option isn't available in 1.4.8 either. I could see in GIT where the code for --left-axis-format was added but my GIT foo isn't strong enough to figure out what version it was merged with.
Update: --left-axis-format wasn't added until 1.4.9 according to the changelog:
RRDtool 1.4.9 - 2014-09-29
New Features
allows rrdrestore to read input from stdin
add documentation for RRDs::xport
RPN operators MINNAN and MAXNAN
--left-axis-format option to rrd_graph
Updated update: I was able to easily compile rrdtool 1.4.9 from source just following the instructions in the included doc/rrdbuild.pod instruction file.
I'm writing a library in order to help everyone using Amazon cloud search.
With cloud search when you update a document you need to specify the id of the document (of course) and the version of the document you want to upgrade to.
If the specify version number is smaller than the current version the update don't append.
So how to make sure I update my record every time I do an update?
The Ruby project aws_cloud_search is using a timestamp in order to keep the version number always higher but:
As the maximum version number is 4294967295 for AWS cloud search. So
it will not work any more after the 07 Feb 2106
If you run two updates within the same second then the last update
(the more important one) will be ignore
Aside from the timestamp approach, which appears to be the standard answer from everybody, including the docs, the only approach that I've found that works is to keep track of the version number elsewhere, and increment it as changes happen.
Of course, this approach only works if the object that you're trying to represent in the cloud search document can be accessed from somewhere else where presumably you have some sort of atomicity.