I am currently creating a workflow in which the user captures a point geometry by clicking on the map (this works), then the map zooms to the point's extent (this also works), and then buffers the point (this does not work).
My BufferTask activity gives me this: "Unhandled exception: 'Required parameter is null or empty. Parameter name: Geometry.SpatialReference in activity '1.3: BufferTask'"
This doesn't make sense to me since I have indeed entered a value for this parameter.
sidenote: Geocortex's documentation is virtually non-existent. My inner-cynic is telling me that this is on purpose so that you keep paying them to do things for you.
My 2 best guesses would be either that the buffer spatial reference is null (the spatial reference used to actually create the buffer itself), or that the selectedLocation spatial reference is null for some reason.
For the first, see if there's a value entered for "Buffer Spatial Reference" which you'll see in the properties panel on the right side of the designer when you've got the Buffer Task selected. Note that using Web Mercator as the Buffer Spatial Reference will likely give you an inaccurate buffer due to distance distortion in that projection.
For the second, you could explicitly assign a SpatialReference to selectedLocation.SpatialReference using an assign activity (making sure that the assigned SpatialReference matches the actual spatial reference of your location).
Check to make sure you specified a correct spatialReference, so the workflow module can assess the "length" of buffer.
In addition isolate the problem.
Create a clean variable of type spatialReference and assign a NEW SpatialRef(wkid). Then use that variable.
Related
We used to use the guava cache and we want to change it to caffeine.
We want to set for each entity its own "expiration time", something like - put(K key, V value, long expiration_time).
I saw the 3 functions above and I wonder what exactly they are doing, if you can explain me the meaning ant the operations of each one of them it will be great.
For example, the return value of expireAfterCreate should be the duration we want for this entity from it's creation untill it's expiration? or something else?
I'm also wondering why we have the parameter "currentTime" in both expireAfterRead and expireAfterUpdate if we don't use it in the function?
When we used the guava cache we used the expireAfterAccess, what is the substitution for it in caffeine?
My last question is how can I set a default value for entities without a unique expiration time.
Thank you,
May
When we used the guava cache we used the expireAfterAccess, what is the substitution for it in caffeine?
We mirror the Guava API, so this is also available on the cache builder.
My last question is how can I set a default value for entities without a unique expiration time.
Use expireAfterAccess, expireAfterWrite, or return a constant duration with expireAfter(Expiry).
I saw the 3 functions above and I wonder what exactly they are doing, if you can explain me the meaning ant the operations of each one of them it will be great.
Expiry is a callback interface where a single timestamp value is updated. The invoked method corresponds to the operation performed on the cache entry (created, updated, read). An update or read that should have no effect can return currentDuration to no-op.
For example, the return value of expireAfterCreate should be the duration we want for this entity from it's creation untill it's expiration? or something else?
Yes. However if the expireAfterUpdate returns a custom value (something other than currentDuration), then that overrides the prior expiration duration.
I'm also wondering why we have the parameter "currentTime" in both expireAfterRead and expireAfterUpdate if we don't use it in the function?
This can most often be ignored, but is provided if somehow useful. It is the current nano timestamp from the Ticker (not wall clock time).
We want to set for each entity its own "expiration time", something like - put(K key, V value, long expiration_time).
The callback Expiry is required and generally recommended, because ideally entries are loaded through the cache to avoid stampedes (e.g. LoadingCache). A stampede is when multiple threads lookup the same entry, miss, load it, and overwrite each other putting it in. That wasted work rather than having only one thread perform the load and others wait for the results.
That said, this method is available under Cache.policy().expiresVariably(). Those configuration-specific methods are stashed in that area to offer more power when deemed necessary.
Thank you,
You're very welcome.
I am using ELKI to cluster data from CSV file
I use
-resulthandler ResultWriter
-out folder/
to save the outputdata
But as an output I have some strange indexes
ID=2138 0.1799 0.2761
ID=2137 0.1797 0.2778
ID=2136 0.1796 0.2787
ID=2109 0.1161 0.2072
ID=2007 0.1139 0.2047
The ID is more than 2000 despite I have less than 100 training samples
DBIDs are internal; the documentation clearly says that you shouldn't make too much assumptions on them because their implementation may change. The only reason they are written to the output at all is because some methods (such as OPTICS) may require cross-referencing objects by this unique ID.
Because they are meant to be unique identifiers, they are usually continuously incremented. The next time you click on "run" in the MiniGUI, you will get the next n IDs... so clearly, you clicked run more than once.
The "Tips & Tricks" in the ELKI DBID documentation probably answer your underlying question - how to use map DBIDs to line numbers of your input file. The best way is to if you want to have object identifiers, assign object identifiers yourself by using an identifier column (and configuring it to be an external identifier).
For further information, see the documentation: https://elki-project.github.io/dev/dbids
https://stackoverflow.com/a/6044657/1165790
I was under the impression that there are two ways one can assign/call things:
1) by value (the actual bit encoding of a type is assigned/sent to a variable/function and 2) by reference (the memory address of the data's location is assigned/sent to a variable/function.
What exactly is passing a 'reference by value'?
What it means is that you pass the reference (essentially a pointer abstraction) the same way you would pass any other primitive: by value.
Passed by Value Passed by reference
--------------- -------------------
Integer Object
Reference Object that the reference points to
Because references are passed by value, you get the same behavior as you would with
anything else that is passed by value; namely, that the function to which you're passing the reference uses a copy of the reference, and not the actual reference.
So if you change the reference within the function, the original reference outside the function does not change.
This is wordplay. A reference is the memory address, or, strictly speaking, an abstraction that has all the attributes of a memory address. So to pass a reference by value is just what you said: the bits of the address are passed to the callee. In the more general way of speaking that most computer language texts use, this is exactly the same as saying the object is passed by reference.
I'm using AS3 and FlashDevelop, and I cannot seem to convince my FlashPlayer/AVM to GC it.
I tried the pretty standard options:
myboolean = null;
delete(myboolean);
But for the null it says "col: 14 Warning: null used where a Boolean value was expected."
And delete I get "col: 11 Error: Attempt to delete the fixed property allDone. Only dynamically defined properties can be deleted."
And this is considering the Boolean is definited within a method as such:
var myBoolean:Boolean = false;
I appreciate that since it's within the method, when such has run it's course it should get garbage collected, but I like to be certain, and why can't I GC the Boolean when I've done the same for int, Array and Point within another method of the same class? Isn't Boolean also an object?
So if anyone knows how to GC the Boolean please let me know.
Basically like Jonatan Hedborg here says you don't directly control what is garbage collected.
My guess is you're from a c/c++ background or the like where you are responsible for maintaining memory more strictly and directly, this isn't exactly the case with AS3 and Java; though memory management is still very important it's handled more at an Object level. Although Boolean extends from Object read here regarding primitive types:
Null data type The Null data type contains only one value, null . This
is the default value for the String data type and all classes that
define complex data types, including the Object class. None of the
other primitive data types, such as Boolean, Number, int and uint,
contain the value null . Flash Player and Adobe AIR will convert the
value null to the appropriate default value if you attempt to assign
null to variables of type Boolean, Number, int, or uint. You cannot
use this data type as a type annotation.
http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f88.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f82
In both cases you do have mechanisms such as nulling references to detach objects from the graph of all of the active objects which means they'll be garbage collected at the next scheduled run of the garbage collector (which can be forced but it isn't really recommended, the configuration for the JVM or AVM in this case will handle it based on the system it's running/executing in).
nulling an object will allow it to be garbage collected but you shouldn't really be concerned about individual primitive properties. There's a good article explaining some details on garbage collection in AS3 here (I would leave a an abstract but the whole page is pretty good, main points I suppose being garbage collection isn't necessarily 100% straight-forward but with some effort can be managed):
http://tomgabob.blogspot.com/2009/11/as3-memory-management.html
Basically the way it works is the FlashPlayer or whatever virtual machine is running your (byte)code has a graph of all the objects that have been created and that there is a current reference to.
It also has a memory limit for what it can use based on the environment (config etc.) so the GC has algorithms setup to figure out when it should attempt to garbage collect. You should primarily be concerned with nulling references to objects you no longer need, and really this isn't too big of a deal if your application isn't fairly complex, or your hardware isn't extremely restrictive with regard to RAM.
So the concern shouldn't be making the GC run too little or too much, but creating references that are never removed (addingListeners and not removing from objects that should be collected, or simply having references to them within collections etc. after they are no longer needed). Again the article above explains this in a bit more depth.
Where are you using the boolean? The only way to make sure primitives are GC'ed is to ensure the class it's used in is collected.
There are 2 errors in your reasoning:
'delete' can only be applied to dynamic objects, not class members or local variables; in these cases, just set the member/variable to null,
value types (boolean, number, string) don't need to be GC'd; in some cases Flash will create temporary 'boxing objects' which will be automatically collected so you don't have to worry about those.
Do you often see in API documentation (as in 'javadoc of public functions' for example) the description of "value limits" as well as the classic documentation ?
Note: I am not talking about comments within the code
By "value limits", I mean:
does a parameter can support a null value (or an empty String, or...) ?
does a 'return value' can be null or is guaranteed to never be null (or can be "empty", or...) ?
Sample:
What I often see (without having access to source code) is:
/**
* Get all readers name for this current Report. <br />
* <b>Warning</b>The Report must have been published first.
* #param aReaderNameRegexp filter in order to return only reader matching the regexp
* #return array of reader names
*/
String[] getReaderNames(final String aReaderNameRegexp);
What I like to see would be:
/**
* Get all readers name for this current Report. <br />
* <b>Warning</b>The Report must have been published first.
* #param aReaderNameRegexp filter in order to return only reader matching the regexp
* (can be null or empty)
* #return array of reader names
* (null if Report has not yet been published,
* empty array if no reader match criteria,
* reader names array matching regexp, or all readers if regexp is null or empty)
*/
String[] getReaderNames(final String aReaderNameRegexp);
My point is:
When I use a library with a getReaderNames() function in it, I often do not even need to read the API documentation to guess what it does. But I need to be sure how to use it.
My only concern when I want to use this function is: what should I expect in term of parameters and return values ? That is all I need to know to safely setup my parameters and safely test the return value, yet I almost never see that kind of information in API documentation...
Edit:
This can influence the usage or not for checked or unchecked exceptions.
What do you think ? value limits and API, do they belong together or not ?
I think they can belong together but don't necessarily have to belong together. In your scenario, it seems like it makes sense that the limits are documented in such a way that they appear in the generated API documentation and intellisense (if the language/IDE support it).
I think it does depend on the language as well. For example, Ada has a native data type that is a "restricted integer", where you define an integer variable and explicitly indicate that it will only (and always) be within a certain numeric range. In that case, the datatype itself indicates the restriction. It should still be visible and discoverable through the API documentation and intellisense, but wouldn't be something that a developer has to specify in the comments.
However, languages like Java and C# don't have this type of restricted integer, so the developer would have to specify it in the comments if it were information that should become part of the public documentation.
I think those kinds of boundary conditions most definitely belong in the API. However, I would (and often do) go a step further and indicate WHAT those null values mean. Either I indicate it will throw an exception, or I explain what the expected results are when the boundary value is passed in.
It's hard to remember to always do this, but it's a good thing for users of your class. It's also difficult to maintain it if the contract the method presents changes (like null values are changed to no be allowed)... you have to be diligent also to update the docs when you change the semantics of the method.
Question 1
Do you often see in API documentation (as in 'javadoc of public functions' for example) the description of "value limits" as well as the classic documentation?
Almost never.
Question 2
My only concern when I want to use this function is: what should I expect in term of parameters and return values ? That is all I need to know to safely setup my parameters and safely test the return value, yet I almost never see that kind of information in API documentation...
If I used a function not properly I would expect a RuntimeException thrown by the method or a RuntimeException in another (sometimes very far) part of the program.
Comments like #param aReaderNameRegexp filter in order to ... (can be null or empty) seems to me a way to implement Design by Contract in a human-being language inside Javadoc.
Using Javadoc to enforce Design by Contract was used by iContract, now resurrected into JcontractS, that let you specify invariants, preconditions, postconditions, in more formalized way compared to the human-being language.
Question 3
This can influence the usage or not for checked or unchecked exceptions.
What do you think ? value limits and API, do they belong together or not ?
Java language doesn't have a Design by Contract feature, so you might be tempted to use Execption but I agree with you about the fact that you have to be aware about When to choose checked and unchecked exceptions. Probably you might use unchecked IllegalArgumentException, IllegalStateException, or you might use unit testing, but the major problem is how to communicate to other programmers that such code is about Design By Contract and should be considered as a contract before changing it too lightly.
I think they do, and have always placed comments in the header files (c++) arcordingly.
In addition to valid input/output/return comments, I also note which exceptions are likly to be thrown by the function (since I often want to use the return value for...well returning a value, I prefer exceptions over error codes)
//File:
// Should be a path to the teexture file to load, if it is not a full path (eg "c:\example.png") it will attempt to find the file usign the paths provided by the DataSearchPath list
//Return: The pointer to a Texture instance is returned, in the event of an error, an exception is thrown. When you are finished with the texture you chould call the Free() method.
//Exceptions:
//except::FileNotFound
//except::InvalidFile
//except::InvalidParams
//except::CreationFailed
Texture *GetTexture(const std::string &File);
#Fire Lancer: Right! I forgot about exception, but I would like to see them mentioned, especially the unchecked 'runtime' exception that this public method could throw
#Mike Stone:
you have to be diligent also to update the docs when you change the semantics of the method.
Mmmm I sure hope that the public API documentation is at the very least updated whenever a change -- that affects the contract of the function -- takes place. If not, those API documentations could be drop altogether.
To add food to yours thoughts (and go with #Scott Dorman), I just stumble upon the future of java7 annotations
What does that means ? That certain 'boundary conditions', rather than being in the documentation, should be better off in the API itself, and automatically used, at compilation time, with appropriate 'assert' generated code.
That way, if a '#CheckForNull' is in the API, the writer of the function might get away with not even documenting it! And if the semantic change, its API will reflect that change (like 'no more #CheckForNull' for instance)
That kind of approach suggests that documentation, for 'boundary conditions', is an extra bonus rather than a mandatory practice.
However, that does not cover the special values of the return object of a function. For that, a complete documentation is still needed.