GraphUser.getLocation() returns GraphLocation object. However, all its getter functions like getState(), getCity(), etc. returns null. The debugger shows that it does have data on state, which I am able to retrieve using getProperty("name").
Is this a bug or expected behaviour?
Thank you for pointing this out, this is definitely a bug. GraphUser.getLocation() should return a GraphPlace and not a GraphLocation.
Please file a bug at https://developers.facebook.com/bugs
In the mean time, you can re-cast it as a GraphPlace (since they're all proxied anyways), something like:
GraphLocation location = user.getLocation();
GraphPlace place = (GraphPlace) location.cast(GraphPlace.class);
Related
i use the newer version of the v8 library. When i run demo from this page(process.cc),
my program crash when GetInternalField is called in UnwrapMap function. Does anyone have a similar problem, or does they know how to solve it?
Here example:
map<string, string>* JsHttpRequestProcessor::UnwrapMap(Local<Object> obj) {
Local<External> field = Local<External>::Cast(obj->GetInternalField(0)); // here segmentation fault
void* ptr = field->Value();
return static_cast<map<string, string>*>(ptr);
}
EDIT:
I solved my problem. I had to insert macro V8_COMPRESS_POINTERS = 1. Thank you
The provided sample works fine here; did you modify it in any way? How exactly are you running it?
You can only call obj->GetInternalField(0) if you know that obj is an object with internal fields. You can use obj->InternalFieldCount() to check. Objects only have internal fields if you, the embedder, gave them any. If you are trying to convert a regular JavaScript object to a C++ map, you'll have to iterate over its properties, not its internal fields.
New to Go and building a simple LRU cache in Go to get used to syntax and Go development.
Having an issue with the MoveToFront list method, it fails on the following check in the MoveToFront body
if e.list != l || l.root.next == e
I want to move the element (e) to the front of the list when I retrieve it from cache , like this
if elem, ok := lc.entries[k]; ok {
lc.list.MoveToFront(elem) // needs fixing
return elem
}
return nil
The Code can be seen here on line 32 the issue occurs
https://github.com/hajjboy95/golrucache/blob/master/lru_cache/lrucache.go#L32
There seem to be two problems, to me. First, this isn't how the List data type is meant to be used: lc.list.PushFront() will create a List.Element and return a pointer to it. That's not fatal, but at the least, it is kind of annoying—the caller has to dig through the returned List.Element when using Get, instead of just getting the value.
Meanwhile, presumably the failure you see is because you remove elements in Put when the LRU-list runs out of space, but you don't remove them from the corresponding map. Hence a later Put of the just-removed key will try to re-use the element in place, even though the element was removed from the list. To fix this, you'll need to hold both key and value. (In my simple experiment I did not see any failures here, but the problem became clear enough.)
I restructured the code somewhat and turned it into a working example on the Go Playground. I make no promises as to suitability, etc.
I have an error that seems to be associated with <cfscript> db operation
// traffic tracking
myQry = new Query();
myQry.setSQL("INSERT INTO dbo.Traffic (Circuit, Fuseaction, IP_hash) VALUES (:circuit, :fuseaction, :ip_hash)");
myQry.addParam(name="circuit", value="#listfirst(rc.fuseaction, '.')#", cfsqltype="CF_SQL_VARCHAR");
myQry.addParam(name="fuseaction", value="#listlast(rc.fuseaction, '.')#", cfsqltype="CF_SQL_VARCHAR");
myQry.addParam(name="ip_hash", value="#cgi.remote_addr#", cfsqltype="CF_SQL_VARCHAR");
myQry.execute();
The really strange thing is, it looks like the operation completed. What kind of a error is this?
Short answer: It's probably a scoping issue. Try:
var myQry = new Query();
Long-winded waffley answer:
I'd call it an Adobe-developers-being-useless kind of error.
If you look at line 460 of that file, you'll see the error is due to a failure of StructFind to find the query name in the variables scope, and the reason it's appearing in debug input is because there's a try/catch with type any surrounding it. The same functionality could be achieved without causing/catching an error by replacing the try/catch with <cfif StructKeyExists(variables,tagAttributes['name']) > which is basic CFML knowledge, and certainly something a developer of the CF product should know!
The same code still exists in the CF10 version of base.cfc, so you may or not feel like submitting it as a bug in Adobe's CF bugbase - though it's unlikely they'll fix it for CF9 (and uncertain whether they'll feel CF10 is worth the effort either).
However, that would only be side-stepping the issue of the variable not existing, not addressing the real issue of why it doesn't actually exist. Given that the debug info shows the query is successfully executing, and the query code is basically right above that line (starts at line 442), it shouldn't be a repeated/common error, but it may be due to your myQry variable not being scoped, and thus it could be colliding with another variable also called myQry (or even the same var from a separate call to the function) which is happening between the execution of the new Query() and .execute() lines, and thus causing the original query to not be there when the StructFind looks for it.
The solution is to put the keyword var before the first use of myQry which will place it in the local scope for that function - something that should be done for all variables that are only for use within an instance of a function, (otherwise they are placed in the variables scope of the component/request that the function exists within).
I'm getting the error Element XMLZONE is undefined in REQUEST a few dozen times a day.
PageDisplay.cfm calls request.xmlzone which is set via the page ZoneManager.cfm, using the following (cut down) code
<cfscript>
variables.aZoneInfo = XmlSearch(application.xmlZones, "//zone[position() = 1]");
try {
request.xmlZone = ToString(variables.aZoneInfo[1]);
}
catch(any expt)
{
variables.objZoneDAO = CreateObject("component", "#application.sComponentDir#ZoneDAO").init(application.sDSN);
variables.objZoneDAO.Read(variables.objZone, 1); }
</cfscript>
Now, the XML will never ever change so is it worth adding the XML file/node to PageDisplay.cfm as a variable? I'd also like to know why it fails - any reason why?
Thanks,
JJ
Well, if the call to ToString(variables.aZoneInfo[1]); fails, then request.xmlZone won't get set. It's doubtful toString() itself will fail, but if variables.aZoneInfo isn't an array with at least one element, then that'll cause you grief. You should be checking this, rather than assuming it.
If it's essential that request.xmlZone is set, then you need to do more in your catch block than what you're currently doing. At the very least you should be logging the exception that was caught, so that when you go "I wonder why that happened?" you have a log to refer to.
I suspect your application is timing out, and when you're doing your xmlSearch(), application.xmlZones doesn't contain what you think it contains. But that's a guess.
I am trying to use the Google geocoder to do a reverse-geocoder lookup. I am running the exact same command on 8 values, and I am only having an error on two of them, which has me confused as one of the failing values is identical to one of the working values. (The 'working' values aren't really working- they still return a value of undefined from the 'formatted_address' field, but they aren't throwing errors). The command that I am running is as follows:
geocoder.geocode({latLng: new google.maps.LatLng(machineList[i].y, machineList[i].x)}, function(results, status) { address = results[0]; });
I am receiving a type error from Javascript, claiming that results is null. I'm not sure why this is happening. Any ideas?
Well, it turns out this was a timing issue. The geocode() command was taking longer to complete for certain locations than for others, which caused the value to show up as null. I ended up eliminating the problem by moving all the subsequent code into the callback function (I hadn't done this earlier because the whole thing is running inside of a loop, and I was having some difficulty getting it to pass in the iterator as a parameter). Now everything seems to be working well and the locations are showing up as they should.