RRDTool - Get time range - forecasting

I am using RRDTool to graph Data and a predicted Trend (LSL) in one Graph.
Therefore I am adjusting the corresponding template.
At the moment I set my end time like this:
--end start+7d
When looking at the resulting graphs via the website I can select different time ranges on the right side:
Custom time Range, Overview, 4 Hours, 25 Hours, One Week, One Month and One Year
What I want:
If I select a time range of 4 Hours, 7 days of forecasting makes no sense. I want to calculate the end time dependent on the time range selected. For example I want the time period displayed in the future being exact of the same size as the time range selected.
Basically I want to define my ending time like this:
--end start+(end-start)
This is not possible, because the end time can not be defined by itself.
Is there a way to extract the selected time-range before defining the end by hand? I could calculate start+(end-start) in my PHP Template and insert it when defining the ending time.
Every help appreciated.
EDIT: I forgot to mention, that I am using RRDTool via PNP4Nagios. When speaking of a website I meant the PNP4Nagios Standard Web Appearance. This is shipped by default when installing PNP4Nagios via Packages.

With PNP4Nagios, your custom template can be used to define all the graph definition -- with the exception of the time window, which is added to the parameter lists in $opt[] and $def[]. So, you cannot easily override the time window 'end' as it is already defined as 'now' by PNP4Nagios (and the 'start' is already defined relative to the end, based on the time range you selected in the web interface). In fact, RRDTool is fairly robust, so if it sees a start/end being redefined the last such definition usually takes precedence... but this doesn't solve your issue.
I think what you're trying to do is have the 1day graph (which normally starts at 'end-1day' and ends at 'now') to go from 'now-1day' to 'now+1day' so that your prediction line could fill the second part. This would need to be done by editing the PNP4Nagios code, which is a bit out of scope of this answer.
PNP4Nagios allows definition of the standard timeranges in the config.php; you can also define new timeranges when you call the graph. This means you can achieve the required time window like this:
pnp4nagios/graph?host=<hostname>&srv=<servicedesc>&start=-1day&end=+1day
... although this is just a one-off and does not override the defaults.
The current view config in PNP4Nagios does not allow the default views to specify an end offset, only a start offset.

Related

Efficient retrieval of lat-lon points that are within a square boundary

I have a react-native application that populates pins on a map that have been submitted by users. The front end gets the corners of the window and then the back end goes through each pin to check if it falls within the boundary, and returns the ones that do.
This is taking too long on the backend and I want to ask the community for ideas, because I doubt I have the best one.
My idea is to store tables of pins grouped by quadrants, effectively a cache, and then I can in almost constant time return the pins from the quadrants involved.
Is there a simpler way to do this?
Maybe using NoSQL?
🙏🏻
A month later it seems geohashing is probably the best way, plus AWS has a library for automatically handling this with dynamodb. Apparently it takes the corners of the screen, lat/lon, and automatically returns the items from the DB in the view, in, I assume, constant time, since that's the whole point of geohashing, getting performance that works at scale..
https://www.npmjs.com/package/dynamodb-geo
https://aws.amazon.com/blogs/compute/implementing-geohashing-at-scale-in-serverless-web-applications/
Otherwise, using a geohashing library that is built for serving mobile apps likely exists.

Anylogic stopwatch/timer

I'm wondering if there is something in anylogic that's the opposite to an event, this is, an object that counts the lapse of time instead of the time remaining.
Example:
I have a factory simulation where I want to visualize the amount of time that a specific worker (agent that is a resource) has been working since his shift started --> I could query for a function created in worker which is what I currently do but it would be neater to have a timer with the time worked
On the other hand I want to account for the busy time of a machine in a way that it's computed life (there's also the option of querying it)
For those two examples an object like an Event that has a counter and functionality around it would be useful if it could be used with increasing time instead of decreasing
I haven't found anything of the sort...
The Time Measure Start and Time Measure End blocks in the DES palette did the trick

More on ui-grid row filtering

Long version of the question
I have a complex filtering operation that I'm trying to implement for a ui-grid application. Essentially, I have a big grid with lots of columns, each having the typical filter fields at the top of the columns. That works great.
Then I have an extra analysis step that the user can turn on (which involves looking for sets of rows that meet a certain criterion, and then marking rows visible or not based on the results) that MUST be applied logically after all the other filters (i.e. it does share 'commutative property' as all the column-top filters do). This extra analysis/filter step intends to take the row set that is produced by the column-top filters and then apply this one final, mother-of-all-complex-filtration steps.
I am able to get that filtration logic to produce initially correct results - when the user first clicks into the special mode, I perform the analysis and save the necessary info in a hidden column of the grid; and then a RowsProcessor sets the row.visible attribute accordingly. (perhaps I didn't need the RowsProcessor, and maybe I could have just set the visibility in the analysis subroutine.) But whatever - the point is that the rows are marked visible or not. The problem occurs when the user subsequently adds/removes/changes a filter to one of the column top filters. That extra analysis step by necessity needs to be based upon the rows that are visible according to the column-top-filters. And the first time into the special filtering routine, a call to gridApi.core.getVisibleRows() returns exactly that rowset. But after that, the visible rowset is now reduced by the prior execution of the special filtering. But I need to get back to the rowset (i.e. complete recalculation of the row.visible attributes) of just the column-top-filters, without any special final filtration. Is there a way to do that - to effectively undo the filtration effects of the RowsProcessor?
Short version of the question
Is there some way to force recalculation of the visible row set based on the column top filters? and to do so in a way to get control back so additional filtration steps can be executed?
I've looked at various things in the APIs but cannot tell which, if any, might help me. For example:
In the ui.grid (Grid) portion of the API, I see many different flavors of refresh methods that may help, but there's no distinction given that I understand. I hope the one that I need is not refreshRows( ) that says "not functional at present"
Also, the GridRow 'class' seems to have various methods that speak of
visibility "overrides" - that sounds possibly like what I might need
(my final visibility result possibly being an override to those calculated by the column-top filters). But I tried using those methods instead of directly setting row.visible and I did not see any difference.
Can anyone suggest a direction for me to try?
and even better, is there any written description that provides a high-level overview of ui-grid functionality? I love the package, but using it for the first time, I'm just having a hard time with what are probably basic concepts, and possibly I'm thinking about this problem all wrong.
Once again, thanks for any assistance.
Whenever the rowsProcessors run they start by setting all rows to visible, then each rowsProcessor runs in turn with the results from the previous rowsProcessor being passed to the next one. RowsProcessors have a priority, so you can set your processor to run at the appropriate place in the sequence.
It sounds like your problem is that you're using getVisibleRows to calculate what to do, rather than looking at the rows that are passed in to your rows processor, and evaluating based on which rows are visible in that input.
My guess is that you would be better to set your rowsProcessor to have a high (late) priority, and then process all your calculations within that processor rather than attempting to cache them on the data set itself. If you need to extract the visible rows from the set of renderableRows that are passed to your processor, you could do it with:
var visibleRows = renderableRows.filter( function(row) { return row.visible; });

How to do grid paging by offset?

I want to implement a paging grid of people, similar to Gmail contacts, where the grid loads a maximum of N people's names, the paging bar says something like 'Allen - Baxter', and you can page through the alphabetical list. The main differences with the stock ExtJS pager is:
(a) This custom pager doesn't use a page number from beginning, but rather it uses an offset to begin the query (e.g. Baxter). On the server side, it actually queries names > Baxter.
(b)The pager won't know total count of people or pages, because the server doesn't check this. It just queries users > Baxter up to N people.
I guess you can sort of call it "infinite paging".
Is there a simpler approach to this problem other than writing a totally custom pager class (and possibly making changes to grid, store, and/or proxy classes)?
I came up with a working solution by creating my own toolbar class which is basically a copy-paste of Ext.toolbar.Paging that changes almost every method. The two client parameters I used to specify the type of request is: (1) direction, and (2) cursor. Those two parameters together can identify every type of paging request: (a) first, (b) next, (c) previous, (d) last. Other than the limit parameter, the class ignores the existing paging behavior built into ExtJs; it's an entirely different paradigm. And the server also includes a response parameter called hasMore, tells the client whether there are more items in the direction it is paging. So the server then always queries one more item than the limit to determine whether there is more.

time to create a bot for second life using linden scripting language?

how much time does it take to create a simple dance performing bot in second life using Linden Scripting Language ?? , i have no prior knowledge of lsl , but i know various object oriented and event driven programming languages .
Well, it's pretty simple to animate avatar: you'll need a dance animation (those are pretty easy to find, or you could create your own), put it in a prim (which is basic building object in SL), and then create a simple script which first requests permission to animate desired avatar:
llRequestPermissions(agent_key, PERMISSION_TRIGGER_ANIMATION);
You receive response in run_time_permissions event and trigger your animation by name:
run_time_permissions(integer param)
{
llStartAnimation("my animation");
}
Those are the essentials; you'll probably want to request permissions when an avatar touches your object, and stop animation on second touch... or you could request for permissions for each avatar which is in certain range.
As for the "bot" part, Second Life viewer code is open source; if you don't want to build it yourself, there are several customizable bots available. Or you could simply run an official SL viewer and leave it on; there is a way to run several instances of SL viewer at the same time. It all depends on what exactly you need it for.
Official LSL portal can be found here, though I prefer slightly outdated LSL wiki.
Slight language mismatch: To make an object perform a dance is currently known as "puppetry" in a SecondLife context. The term "bot" currently means control of an avatar by an external script api.
Anyway in one instance, it took me about two hours to write, when I did one for a teddy bear a few weeks back, but that was after learning alot from taking apart some old ones, and i never did finish making the dance, it just waggles the legs or hugs with the arms, but the script is capable for however many steps and parts you can cram in memory.
Puppetry of objects has not improved much in the past decade. It is highly restricted by movement update rates and script limitations. Movement is often delayed under server load and the client doesn't always get updates, which produces pauses and skips in varying measure. Scripts have a maximum size of 64k which should be plenty but in actuality runs out fast with the convolutions necessary in lsl. Moving each linked prim in an object seperately used to need a script in each prim, until new fuctions were introduced to apply attributes by linknumber, still many objects use old scripts which may never be updated. Laggy puppets make for a pitiful show, but most users would not know how to identify a good puppetry script.
The popular way to start making a puppet script is to find an older open source puppet script online, and update it to work from one script. Some archane versions are given as 'master' and 'slave' scripts which need to be merged placing the slave actions as a function into the master, changing llMessageLinked( ) for the function name. Others use an identical script for each prim. I said popular, not the simplest or easiest, and it will never be the best.
Scripting from scratch, the active flow needs to go in a timer event with nothing else in it. Use a different state for animating if a timer is needed when waiting because it's a heavy activity and you don't need any more ifs or buts.
The most crucial task is create a loop to build parameters from a list of linknumbers, positions, and rotations into a parameter list before the llSetLinkPrimitiveParamsFast( ). Yes, that's what they called it because it's a heavy list based function, you may just call it SLPPF inworld but not in the script. Because SLPPF requires the call to have certain constants for each parameter, the parameter list for each step will need to include PRIM_LINK_TARGET, linknumber, PRIM_POS, position, PRIM_ROT, rotation for each linked part in the animation step.
Here's an example of putting a list of a single puppetry step into SLPPF.
list parameters;
integer index;
while ( index < total ) { // total number of elements in each list
parameters += [
PRIM_LINK_TARGET, llList2Integer( currentstep, index ),
PRIM_POS, llList2Vector( currentstep, index+1 ),
PRIM_ROT, llList2Rotation( currentstep, index+2 )
];
index += 3;
}
llSetLinkPrimitiveParamsFast( 0, parameters );
How you create your currentstep list is another matter but the smoothest movement over many linked parts will only be possible if the script isn't moving lists around. So if running the timer at 0.2 seconds isn't any improvement over 0.3, it's because you've told lsl to shovel too many lists. This loop with three list calls may handle about 20 links at 0.1 seconds if the weather's good.
That's actually the worst of it over, just be careful of memory if cramming too many step lists into memory at once. Oh and if your object just vanishes completely, it's going to be hanging around near <0,0,0> because a 1 landed in the PRIM_LINK_TARGET hole.

Resources