I wonder, what is a usage of commanddata1 and commanddata2 in FMOD channelcontrol callback when callbacktype == FMOD_CHANNELCONTROL_CALLBACK_SYNCPOINT?
I was looking on the internet for any answers on this question, but I can't find any.
The information you are looking for can be found here, but to summarize quickly:
commanddata1: (cast to int) The index of the sync point. Use Sound::getSyncPointInfo to retrieve the sync point's attributes.
commanddata2: Always 0.
Related
I'm working on some Java code to interact with OrientDB graphs. Currently I'm looking at the interface for OCommandRequest. The method execute() can return something different based on the query that we run... but I'm not sure what is possible from it.
I have looked at the code, but I'm somehwhat new to Java. So far I see that OCommandRequest is an interface but that's about as far as I've gone pulling the thread in the code.
I haven't found a lot in the OrientDB Documentation that has helped me to know what return types are possible and what the values mean when they get returned.
I played with some examples on my end based on some of the examples I found at massapi. Sometimes it returns an Integer, other times a Boolean, and yet other times I've gotten back an Iterable.
My question is: Is there some documentation available that characterizes what OCommandRequest.execute() returns and why? Ideally some formatted docs are nice, but pointers into the code to find where the interface is being implemented would also be helpful and allow me to pull the thread a little bit more.
For now, I'm emulating one of the examples from the massapi site I linked earlier (but I'm not sure if this is really considered the blessed way to handle responses from queries):
OCommandRequest command = graph.command(new OCommandSQL(query));
Object result = command.execute();
if( result instanceof Integer ) {
// do stuff if an integer was returned
} else if( result instanceof Boolean ) {
// do stuff if a boolean was returned
} else if( result instanceof Iterable<OrientVertex> ) {
// do stuff if an iterable list of vertices was returned
} else {
// any other types?
}
Any pointers that someone can give are definitely useful.
Thanks!
There is no documentation about that, it depends on SQL command you execute.
To know the return type you have to refer directly to their own class. For eg. DROP CLASS returns Boolean, and so on.
Anyway you can use this code to see the return type:
OCommandRequest command = g.command(new OCommandSQL(q));
Object result = command.execute();
System.out.println(q+"\n"+result.getClass().toString()+"\n");
I'm trying to check the input of a Matlab function to see whether the user has forgotten about it or not (which is easy to do in this case).
If the user has not supplied number_obs then I want to pause the program and wait for the user to input this information.
Some other StackOverflow posts seem to suggest using ~exist however this doesn't seem to work. Can anybody suggest what I'm doing wrong here?
function output=test(number_obs)
if ~exist('number_obs'),
number_obs=input('How many observations do you have in your experiments?')
end
The Python equivalent would be something like:
def test(number_obs):
if nummber_obs != None:
output=raw_input('How many observations do you have in your experiments? :')
return output
You can do this with nargin
function output=test(number_obs)
if nargin<1
number_obs=input('How many observations do you have in your experiments?')
end
(Edited to correct the truth) It may not matter here, but to be on the safe side, you should always specify the type of object you're checking. In your case, its a 'var', so
if ~exist('number_obs','var'),
Thanks to dasdingonesin for pointing this out.
Using scala I have added about 100000 nodes to a linked list. When I use the function length, for example mylist.length. I get a 'java.lang.StackOverflowError' error, is my list to big to process? The list is only string objects.
It appears the library implementation is not tail-recursive override def length: Int = if (isEmpty) 0 else next.length + 1. It seems like this is something that could be discussed on the mailing list to check if an enhancement ticket should be opened.
You can compute the length like this:
def length[T](l:LinkedList[T], acc:Int=0): Int =
if (l.isEmpty) acc else length(l.tail, acc + 1)
In Scala, computing the length of a List is an order n operation, therefore you should try to avoid it. You might consider switching to an Array, as that is a constant time operation.
You could try increasing the stack/heap size available to the JVM.
scala JAVA_OPTS="-Xmx512M -Xms16M -Xss16M" MyClass.scala
Where
-Xss<size> maximum native stack size for any thread
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
This question has some more information.
See also this This Scala document.
Can you confirm that you truly need to use the length method? It sounds like you might not be using the correct collection type for your use-case (hard to tell without any extra information). Lists are optimised to be mapped over using folds or a tail-recursive function.
Despite saying that, this is absolutely an oversight that can easily be fixed in the standard library with a tail-recursive function. Hopefully we can get it in time for 2.9.0.
I love Google Guava and use it a lot, but there is one method I always find me writing..
public static <T> T tryFind(Iterable<T> iterable, Predicate<T> predicate){
for(T t : iterable){
if(predicate.apply(t)){
return t;
}
}
return null;
}
To me this seems to be a very useful addition to Iterables (also to Iterators for that matter), so I'm wondering why it's missing. Also, while I can see the point of having a method that throws NoSuchElementException, perhaps to distinguish between finding a null and not finding the element, that situation only comes up if the predicate you are using is
public boolean apply(T t){
return t==null;
}
which doesn't seem to be a common case.
So why did guava designers chose to have this behavior, instead of just returning null if it can't find it?
Here is the javadoc for [Iterables.find()][1]
[1]: http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterables.html#find(java.lang.Iterable, com.google.common.base.Predicate)
We're adding another overload of find() which accepts a default value.
Likely because null is a valid return value. Generally speaking, unless there is a good reason to not support null then it should be supported. If it is supported then you have to handle the case where it exists.
Instead of tryFind() you can use filter and check if it returns an empty collection.
I found that always working with collections is cleaner than directly asking objects.
In my opinion, the NoSuchElementException is better than a late and very difficult to debug NPE...
In most cases, when you are searching an object in a "collection", you know that you would probably find it.
If the object you're looking for is not in the "collection", you're facing an exceptional case... According to me, the NoSuchElementException feedback is more explicit than the meaningless "null".
The default value which will be introduced in a future guava release would be an efficient shortcut to treat the exceptionnal case.
Find would make sense if it could not to find rather finding default value.
Optional<T> Iterables.find(Iterable<T>, Predicate<? super T>)
I'm new to Scala and Lift, coming from a slightly odd background in PLT Scheme. I've done a quick search on this topic and found lots of questions but no answers. I'm probably looking in the wrong place.
I've been working my way through tutorials on using Mapper to create database-backed objects, and I've hit a stumbling block: what types should be used to stored optional attribute values.
For example, a simple ToDo object might comprise a title and an optional deadline (e.g. http://rememberthemilk.com). The former would be a MappedString, but the latter could not be a MappedDateTime since the type constraints on the field require, say, defaultValue to return a Date (rather than a Date or null/false/???).
Is an underlying NULL handled by the MappedField subclasses? Or are there optional equivalents to things like MappedInt, MappedString, MappedDateTime that allow the value to be NULL in the database? Or am I approaching this in the wrong way?
The best place to have Lift questions answered is the Lift group. They aren't into Stack Overflow, but if you do go to their mailing list, they are very receptive and helpful.
David Pollak replied with:
Mapper handles nulls for non-JVM
primitives (e.g., String, Date, but
not Int, Long, Boolean). You'll get a
"null" from the MappedDateTime.is
method.
... which is spot on.