How can one create a dictionary of objects with weak references -- that is, the dictionary does not retain its keys and values -- on OS X 10.7 with ARC enabled? NSMapTable looks promising but unfortunately it doesn't use weak references when ARC is enabled.
NSMapTable is indeed what you want.
10.8+:
specifically in your case it sounds like you want to use this:
+ (id)weakToWeakObjectsMapTable
Return Value
A new map table object which has weak references to the keys and values.
from the docs:
The major option is to have keys and/or values held “weakly” in a manner that entries are removed when one of the objects is reclaimed.
you can use either the shortcut class methods + (id)weakToWeakObjectsMapTable or + (id)weakToStrongObjectsMapTable depending on your needs.
also see NSMapTableOptions to see how to specify behavior to the other initializers.
NSMapTableWeakMemory
Uses weak read and write barriers appropriate for ARC or GC. Using NSPointerFunctionsWeakMemory object references will turn to NULL on last release. Equal to NSMapTableZeroingWeakMemory.
10.7+:
use – initWithKeyOptions:valueOptions:capacity: and pass NSMapTableZeroingWeakMemory in the options (assuming your objects are "weak-reference-safe")
alternatively you can use – initWithKeyPointerFunctions:valuePointerFunctions:capacity: and specify custom functions if none of the built in ones work for you / arent available on you version. (maybe one of the "opaque" personalities would work for you)
Related
I was wondering if someone can compare & contrast the differences between redux reselect lib vs lodash memoize...?
Lodash's memoize is a classic memoizing utility: It memoizes a function using (by default) its first argument as cache key. Lodash's memoize keeps track/caches all the results obtained with different cache keys.
Reselect instead, checks each provided argument, and (by default) recomputes the result ONLY IF one of the arguments changes. Reselect's selectors have by default a cache size of 1, and are mainly designed to stabilize state-derived data avoiding undesired recomputations.
There are 2 major differences:
are all parameters checked for changes before recomputing, or just the first one?
are all results cached, or only the most recent result?
lodash _.memoize:
only checks the first parameter for changes and returns the most recent result for that first parameter, regardless of whether other parameters have changed (by default).
keeps an infinitely large record of all result values keyed by that first parameter.
Example of a problematic case with lodash _.memoize:
const memoizedFunc = _.memoize(
(param1, param2) => param1 + param2
);
console.log(memoizedFunc(1, 2)); // 3
console.log(memoizedFunc(1, 3)); // 3 (but it should be 4!)
Note that you can write a custom resolver function and pass it in as the second argument to _.memoize to change this behavior and thus take all or some parameters into account. This is extra logic to test and maintain and may or may not be worth it to you. (The resolver function determines the key to be used in the Map of cached results that the memoized function maintains. By default the key is just set to equal the first parameter.)
reselect:
checks all parameters for equality against the most recent execution only.
only caches a single result (the most recent).
Note that reselect is primarily used for redux applications, creating memoized selectors with createSelector. In createSelector, each parameter is expected to have a getter (selector) function, because of the expectation of usage with a redux store. If you are not trying to memoize data from a redux store, you still could use this and send in an identity function like _.identity for each parameter, but that would be silly.
Fortunately, if you only want to memoize functions, and you want all parameters checked for changes, you can use reselect's defaultMemoize and get the desired behavior.
Summary / other libraries (memoize-one)
If you want all parameters checked for changes, and are not using redux or otherwise need to use createSelector, you may want to just use a very lightweight and fast library intended for specifically for this like memoize-one.
If you do want createSelector, you can just use reselect for all your needs most likely.
If you want all results to be cached, not just the most recent ones, you can use lodash _.memoize alone, and you can also customize reselect to use that feature of lodash _.memoize.
How can I tell the Closure Compiler not to rename an inner function? E.g., given this code:
function aMeaninglessName() {
function someMeaningfulName() {
}
return someMeaningfulName;
}
...I'm fine with Closure renaming the outer function (I actively want it to, to save space), but I want the function name someMeaningfulName left alone (so that the name shown in call stacks for it is "someMeaningfulName", not "a" or whatever). This despite the fact that the code calling it will be doing so via the reference returned by the factory function, not by the name in the code. E.g., this is purely for debugging support.
Note that I want the function to have that actual name, not be anonymous and assigned to some property using that name, so for instance this is not a duplicate of this other question.
This somewhat obscure use case doesn't seem to be covered by either the externs or exports functionality. (I was kind of hoping there'd be some annotation I could throw at it.) But I'm no Closure Compiler guru, I'm hoping some of you are. Naturally, if there's just no way to do that, that's an acceptable answer.
(The use case is a library that creates functions in response to calls into it. I want to provide a version of the library that's been pre-compressed by Closure with SIMPLE_OPTIMIZATIONS, but if someone is using that copy of the library with their own uncompressed code and single-stepping into the function in a debugger [or other similar operations], I want them to see the meaningful name. I could get around it with eval, or manually edit the compressed result [in fact, the context is sufficiently unique I could throw a sed script at it], but that's awkward and frankly takes us into "not worth bothering" territory, hence looking for a simple, low-maintenance way.)
There is no simple way to do this. You would have to create a custom subclass of the CodingConvention class to indicate that your methods are "local" externs (support for this was added to handle the Prototype library). It is possible that InlineVariables, InlineFunctions, or RemoveUsedVariables will still try to remove the name and would also need to be fixed up.
Another approach is to use the source maps to remap the stack traces to the original source.
read the following section
https://developers.google.com/closure/compiler/docs/api-tutorial3#export
Two options basically, use object['functionName'] = obj.functionName or the better way
use exportSymbol and exportProperty both on the goog object, here is the docs link for that
http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.html
-- edit
ah, i see now, my first answer is not so great for you. The compiler has some interesting flags, the one which might interest you is DEBUG, which you can pass variables into the compiler which will allow you to drop some debugging annotations in via logging or just a string which does nothing since you are using simple mode.
so if you are using closure you can debug against a development version which is just a page built with dependiencies resolved. we also the drop the following in our code
if(DEBUG){
logger.info('pack.age.info.prototype.func');
}
As the Sqlite docs specify, unbound parameters in prepared statements are interpreted as NULL - my question is this then:
Is there a way to have Sqlite ensure that all parameters have been bound at least once, thereby ensuring none were missed by accident?
It is better to get an error and require calls to sqlite3_bind_null(statement_, col); then to get a subtle error because I forgot to call sqlite3_bind_* on the where clause of an update statement!
It is not possible to differentiate unbound parameters from parameters set to NULL using the current SQLite libraries.
If you have a look at the C source code for sqlite3_bind_null(), you will find that it simply calls the internal SQLite function that unbinds a parameter. Therefore there is no way to tell the two cases apart.
The only solution for this would be to wrap the SQLite C API functions with your own functions that will do a bit of book-keeping. You can bundle a bitmap with each sqlite3_stmt structure, with each bit set to true if and only if the corresponding parameter is bound. You would have to create wrappers for at least the sqlite3_bind_*() functions and sqlite3_clear_bindings().
I want to get the system icon of a specified folder, but maybe the only way to retrieve the icon is to use SHGetFileInfo() method. The first parameter of SHGetFileInfo() method is a pointer of LPITEMIDLIST.
If I only have the absolute path of the folder, how can I get the pointer according to the path?
SHParseDisplayName().
Welcome to the wonderful world of PIDLs.
You can read more at Introduction to the Shell Namespace, but basically a PIDL is a Pointer to an item ID List. You can think of it as a linked list in contiguous memory, but instead of each node having a pointer to the next node, you instead have the cb member which is the Count of Bytes that are contained the item, so you can add that to the base address to get the next item. IDLists are terminated with an item with { cb = 0, abID = NULL }.
So, what's in these magic lits? Basically you don't care and can't know. Any IShellFolder implementation can create a new type of ID to represent its type of item in the shell namespace. The basic file system view that the Shell implements just stores the parts of the path in these lists, so you have something like "c:\" in the first one "Users\" in the next one, etc. In reality they are serialized structs (or classes) that may contain more data. But they can also represent printers, network shares, database searches (for search folders, stacks, etc).
All you really need to know is you can ask IShellFolders to give you a PIDL that represents the items they contain, and later on you can give that PIDL back to them, and other various Shell functions and interfaces, and they know how to deal with them. What SHParseDisplayName() basically does (I think) is go through the registry looking for all registered IShellFolder implementations and asks them if they know what to do with the string you pass in, and the first one to handle it makes the PIDL and gives it back.
Support for generics (currently only Vector.<*>, and called 'postfix type parameters' by Adobe) was added in Flash Player 10, but the only AVM2 documentation does not describe how these objects are accessed.
Specifically, I noticed a new opcode (0x53) and a new multiname kind (0x1D) that seem relevant, but their usage is not documented.
NB: This question was created with the answer already known as it is more easily found here than on my blog or the Adobe Bug DB.
The reverse engineering work I did on this did not include declaring your own generic types, though it's very likely possible.
References to the declaring (parameterless) generic type (Vector) are made through a regular qualified name (though any multiname should do).
References to a typed generic type (Vector.<int> as opposed to Vector.<>) are made by a new multiname kind (0x1D), which I call GenericName. GenericName has a format like so:
[Kind] [TypeDefinition] [ParamCount] [Param1] [Param2] [ParamN]
Where:
[TypeDefinition] is a U30 into the multiname table
[ParamCount] is a U8 (U30?) of how many type parameters there are
[ParamX] is a U30 into the multiname table.
Obviously generics are not generally supported yet, so ParamCount will always be 1 (for Vector.<*>).
The other interesting thing is how instances of the class are created. A new opcode was added in Flash 10 (0x53), which I will call MakeGenericType. MakeGenericType is declared with the following stack:
TypeDefinition, ParameterType1, ParameterTypeN -> GenericType
It also has one parameter, a U8 (U30?) specifying how many parameters are on the stack. You will generally see MakeGenericType being used like this:
GetLex [TypeDefinitionMultiname]
GetLex [ParameterTypeMultiname]
MakeGeneric [ParamCount]
Coerce [GenericNameMultiname]
Construct [ConstructorParamCount]
So if you had the following...
GetLex __AS3__.vec::Vector
GetLex int
MakeGeneric 1
Coerce __AS3__.vec::Vector.<int>
Construct 0
You would now have an instance of Vector.<int>