I'm using the Unity Entity Component System. When I try to write the following code:
Entities.WithAll<SomeComponentData, SomeComponentData2, SomeBufferElementData>()
.ForEach((Entity entity, ref SomeComponentData componentData, ref SomeComponentData2 componentData2, DynamicBuffer<SomeBufferElementData> buffer) => {
});
I get the following error error CS0315: The type 'Unity.Entities.Entity' cannot be used as type parameter 'T0' in the generic type or method 'EntityQueryBuilder.ForEach<T0>(EntityQueryBuilder.F_D<T0>)'. There is no boxing conversion from 'Unity.Entities.Entity' to 'Unity.Entities.IComponentData'.
It compiled fine when I was just using one ComponentData and one BufferElementData i.e. the following worked:
Entities.WithAll<SomeComponentData, SomeBufferElementData>()
.ForEach((Entity entity, ref SomeComponentData componentData, DynamicBuffer<SomeBufferElementData> buffer) => {
});
I had a look at the ForEach code, which is generated code with lots of permutations of components and dynamicbuffers, but I couldn't find this one. (see answer - I just wasn't looking hard enough!) What happens in this situation where the permutation of ComponentData and BufferElementData is not supported?
Turns out this permutation was supported but I had to put the DynamicBuffer first. That is:
Entities.WithAll<SomeBufferElementData, SomeComponentData, SomeComponentData2>()
.ForEach((Entity entity, DynamicBuffer<SomeBufferElementData> buffer, ref SomeComponentData componentData, ref SomeComponentData2 componentData2) => {
});
I found this out by looking at the IJobForEachWithEntity_XXX interfaces. I found that there was an IJobForEachWithEntity_EBCC interface, which tipped me off to the fact that the buffer had to go before the components.
Hope this will save someone a few hours of their time!
Related
From the docs:
Note: HHVM allows syntax such as $x = Vector<int>{5,10};, but Hack
disallows the syntax in this situation, instead opting to infer
it.
Is there a specific reason for this? Isn't this a violation of the fail-fast rule?
There are some situations in which this would cause error to be deffered, which in turn leads to harder backtracing.
For example:
<?hh // strict
function main() : void {
$myVector = new Vector([]); // no generic syntax
$myVector->addAll(require 'some_external_source.php');
}
The above code causes no errors until it is used in a context where the statically-typed collection is actually in place:
class Foo
{
public ?Vector<int> $v;
}
$f = new Foo();
$f->v = $myVector;
Now there is an error if the vector contains something else then int. But one must trace back the error to the point where the flawed data was actually imported. This would not be necessary if one could instantiate the vector using generic syntax in the first place:
$myVector = new Vector<int>([]);
$myVector->addAll(require 'some_external_source.php'); // fail immediately
I work on the Hack type system and typechecker at Facebook. This question has been asked a few times internally at FB, and it's good to have a nice, externally-visible place to have an answer to it written down.
So first of all, your question is premised on the following code:
<?hh // strict
function main() : void {
$myVector = new Vector([]); // no generic syntax
$myVector->addAll(require 'some_external_source.php');
}
However, that code does not pass the typechecker due to the usage of require outside toplevel, and so any result of actually executing it on HHVM is undefined behavior, rendering this whole discussion moot for that code.
But it's still a legitimate question for other potential pieces of code that do actually typecheck, so let me go ahead and actually answer it. :)
The reason that it's unsupported is because the typechecker is actually able to infer the generic correctly, unlike many other languages, and so we made the judgement call that the syntax would get in the way, and decided to disallow it. It turns out that if you just don't worry about, we'll infer it right, and still give useful type errors. You can certainly come up with contrived code that doesn't "fail fast" in the way you want, but it's, well, contrived. Take for example this fixup of your example:
<?hh // strict
function main(): void {
$myVector = Vector {}; // I intend this to be a Vector<int>
$myVector[] = 0;
$myVector[] = 'oops'; // Oops! Now it's inferred to be a Vector<mixed>
}
You might argue that this is bad, because you intended to have a Vector<int> but actually have a Vector<mixed> with no type error; you would have liked to be able to express this when creating it, so that adding 'oops' into it would cause such an error.. But there is no type error only because you never actually tried to use $myVector! If you tried to pull out any of its values, or return it from the function, you'd get some sort of type compatibility error. For example:
<?hh // strict
function main(): Vector<int> {
$myVector = Vector {}; // I intend this to be a Vector<int>
$myVector[] = 0;
$myVector[] = 'oops'; // Oops! Now it's inferred to be a Vector<mixed>
return $myVector; // Type error!
}
The return statement will cause a type error, saying that the 'oops' is a string, incompatible with the int return type annotation -- exactly what you wanted. So the inference is good, it works, and you don't ever actually need to explicitly annotate the type of locals.
But why shouldn't you be able to if you really want? Because annotating only generics when instantiating new objects isn't really the right feature here. The core of what you're getting at with "but occasionally I really want to annotate Vector<int> {}" is actually "but occasionally I really want to annotate locals". So the right language feature is not to let you write $x = Vector<int> {}; but let you explicitly declare variables and write Vector<int> $x = Vector {}; -- which also allows things like int $x = 42;. Adding explicit variable declarations to the language is a much more general, reasonable addition than just annotating generics at object instantiation. (It's however not a feature being actively worked on, nor can I see it being such in the near to medium term future, so don't get your hopes up now. But leaving the option open is why we made this decision.)
Furthermore, allowing either of these syntaxes would be actively misleading at this point in time. Generics are only enforced by the static typechecker and are erased by the runtime. This means that if you get untyped values from PHP or Hack partial mode code, the runtime cannot possibly check the real type of the generic. Noting that untyped values are "trust the programmer" and so you can do anything with them in the static typechecker too, consider the following code, which includes the hypothetical syntax you propose:
<?hh // partial
function get_foo() /* unannotated */ {
return 'not an int';
}
<?hh // strict
function f(): void {
$v = Vector<int> {};
$v[] = 1; // OK
// $v[] = 'whoops'; // Error since explicitly annotated as Vector<int>
// No error from static typechecker since get_foo is unannotated
// No error from runtime since generics are erased
$v[] = get_foo();
}
Of course, you can't have unannotated values in 100% strict mode code, but we have to think about how it interacts with all potential usages, including untyped code in partial mode or even PHP.
I would like to use Player.IO from Yahoo Games Network in my Unity javascript code. PlayerIO provides example project for unity written only in C# so I am having problems with getting the callbacks work.
PlayerIO.Connect description from Player.IO documentation for Unity (available here):
public void Connect (string gameId, string connectionId, string userId, string auth,
string partnerId, String[] playerInsightSegments,
Callback<Client> successCallback, Callback<PlayerIOError> errorCallback)
So how to make these callbacks work?
The following part of the question shows the ways I have already tried, but didn't work.
Firstly I've tried this way (as I know from javascript):
function success(client : Client) {
//function content
}
PlayerIOClient.PlayerIO.Connect(pioGameId, pioConnectionId, pioUserId, pioAuth, pioPartnerId, success, failed);
.
That was not right and I've learned that I should use delegates.
From Unity3D official tutorials (available here), the right use of delegates in JS would be like this (using the Function type):
var successDelegate : Function;
function success(client : Client) {
//function content
}
function Start () {
successDelegate = success;
PlayerIOClient.PlayerIO.Connect(pioGameId, pioConnectionId, pioUserId, pioAuth, pioPartnerId, success, failed);
}
This is causing the following error:
InvalidCastException: Cannot cast from source type to destination type.
Main+$Start$2+$.MoveNext ()
.
After that I've found a topic on Player.IO forum (available here) called Utilizing Player.IO in Unity Javascript. Suggested approach of creating delegates in JS by the author of that topic: go straight to the .Net type and declare them as System.Delegate.
var pioConnectSuccessCallback : System.Delegate;
function success(client : Client) {
//function content
}
function Start () {
pioConnectSuccessCallback = System.Delegate.CreateDelegate(typeof(PlayerIOClient.Callback.<PlayerIOClient.Client>), this, "success");
PlayerIOClient.PlayerIO.Connect(pioGameId, pioConnectionId, pioUserId, pioAuth, pioPartnerId, pioConnectSuccessCallback, pioConnectErrorCallback);
}
This is unfortunately also not working for me, although the guys on the forum present it as a working solution (but it may be outdated).
The error I'm getting:
Assets/Main.js(51,35): BCE0023: No appropriate version of
'PlayerIOClient.PlayerIO.Connect' for the argument list '(String,
String, String, String, String, System.Delegate, System.Delegate)' was
found.
So it seems like Connect method doesn't like System.Delegate as a parameter or those were not initialized well.
The 3rd way is working, the function is expecting 8 parameters and that was why it didn't work for me.
To select all Schedulings which are active, I have the following code:
var allSchedulesOnALine = CurrentUser.Lines.SelectMany(o => o.Scheduling).Where(o => o.Active);
var allSchedulesUnscheduled = Entities.SchedulingSet
.Where(o => o.Line == null && o.Site.Id == CurrentUser.Site.Id &&
o.Factory == CurrentUser.Factory && o.Active);
IEnumerable<Scheduling> allSchedules = allSchedulesUnscheduled.Union(allSchedulesOnALine);
foreach(Scheduling schedule in allSchedules.OrderBy(o => o.Ordering))
{
//Do Stuff
}
(Factory is an int)
When I run this code, I get this cryptic error on the foreach line:
Unable to create a constant value of type 'System.Collections.Generic.IEnumerable`1'. Only primitive types ('such as Int32, String, and Guid') are supported in this context.
Strangely enough, I can enumerate both allSchedulesOnALine and allSchedulesUnscheduled separately. Even stranger, if I reorder the union:
IEnumerable<Scheduling> allSchedules = allSchedulesOnALine.Union(allSchedulesUnscheduled);
It works fine!
Does anyone have any idea why this would happen? Am I missing something crucial, or is this a bug?
I should mention I am using Entity Framework 3.5. EF4 is not an option for us currently - it is beyond my control :\
You're calling two different methods with your "reordering".
You don't show the types of allSchedulesOnALine or allSchedulesUnscheduled, but I'm betting allSchedulesOnALine is of type IEnumerable<Schedule> and allSchedulesUnscheduled is of type IQueryable<Schedule>.
So when you call Queryable.Union, you're asking the EF to translate the expression into SQL. But the argument you pass is of type IEnumerable<Schedule>, and it can't translate that into a query.
On the other hand, when you call Enumerable.Union, you're asking LINQ to Objects to do the whole thing in memory, which works fine, albeit perhaps slower.
So the reason the behavior is different is that you're calling two completely different methods, which do different things, but happen to have the same name. No, it's not a bug.
I've just started using Lambda expressions, and really like the shortcut. I also like the fact that I have scope within the lambda of the encompassing method. One thing I am having trouble with is nesting lambdas. Here is what I am trying to do:
public void DoSomeWork()
{
MyContext context = new MyDomainContext();
context.GetDocumentTypeCount(ci.CustomerId, io =>
{
if (io.HasError)
{
// Handle error
}
// Do some work here
// ...
// make DB call to get data
EntityQuery<AppliedGlobalFilter> query =
from a in context.GetAppliedGlobalFiltersQuery()
where a.CustomerId == ci.CustomerId && a.FilterId == 1
select a;
context.Load<AppliedGlobalFilter>(query, lo =>
{
if (lo.HasError)
{
}
**// Do more work in this nested lambda.
// Get compile time error here**
}
}, null);
}, null);
}
The second lambda is where I get the following compile time error:
Cannot convert Lambda expression to type 'System.ServiceModel.DomainService.Client.LoadBehavior' because it is not a delegate type
The compiler is choosing the wrong overload for the Load method even though I am using the same override I did in the previous Lambda.
Is this because I am trying to nest? Or do I have something else wrong?
Thanks,
-Scott
Found the problem as described in my comment above. I'll head back to work now - red face and all....
I realize this is not the answer you want, but I suggest caution about lengthy and/or nested lambdas. They work, but they often make code harder to read / maintain by other developers. I try to limit my lambdas in length to three statements, with no nesting.
I'm writing some special purpose data structures in Java, intended for use in the browser, (compiled to JavaScript with GWT).
I'm trying to match the performance of some of the built-in JDK classes I'm noticing things run reasonably fast, but when I compare my code trace to some of the emulated JDK code, mine has lots of calls to dynamicCast and canCastUnsafe, while the JDK emulated classes do not. And it just about accounts for the difference in performance too...
Any GWT gurus out there know how to avoid this? It's amounting to a 20% overhead :-(
Details:
Here's the profile output (captured in Firebug) for 10,000 insertions of random integers, between 0 and 100,000 into two different data structures:
Google's TreeMap implementation for java.util.TreeMap (a red-black tree):
Profile (4058.602ms, 687545 calls)
Function Calls Percent Own Time
$insert_1 129809 41.87% 1699.367ms
$compare_0 120290 16% 649.209ms
$isRed 231166 13.33% 540.838ms
compareTo_0 120290 8.96% 363.531ms
$put_2 10000 6.02% 244.493ms
wrapArray 10000 3.46% 140.478ms
createFromSeed 10000 2.91% 118.038ms
$TreeMap$Node 10000 2.38% 96.706ms
initDim 10000 1.92% 77.735ms
initValues 10000 1.49% 60.319ms
$rotateSingle 5990 0.73% 29.55ms
TreeMap$Node 10000 0.47% 18.92ms
My Code (An AVL tree):
Profile (5397.686ms, 898603 calls)
Function Calls Percent Own Time
$insert 120899 25.06% 1352.827ms
$compare 120899 17.94% 968.17ms
dynamicCast 120899 14.12% 762.307ms <--------
$balanceTree 120418 13.64% 736.096ms
$setHeight 126764 8.93% 482.018ms
compareTo_0 120899 7.76% 418.716ms
canCastUnsafe 120899 6.99% 377.518ms <--------
$put 10000 2.59% 139.936ms
$AVLTreeMap$Node 9519 1.04% 56.403ms
$moveLeft 2367 0.36% 19.602ms
AVLTreeMap$State 9999 0.36% 19.429ms
$moveRight 2378 0.34% 18.295ms
AVLTreeMap$Node 9519 0.34% 18.252ms
$swingRight 1605 0.26% 14.261ms
$swingLeft 1539 0.26% 13.856ms
Additional observations:
Same problem for another data structure I made (SkipList).
dynamicCast is being applied in the compare function:
cmp = dynamicCast(right.key, 4).compareTo$(key);
dynamicCast goes away if the class does not implement Map (ie: just removing " implements Map" from the class. Doesn't matter if it's accessed through the interface or directly. This results in the same line compiling to:
cmp = right.key.compareTo$(key);
This is the relevant section of Java source from SkipList:
private int compare(Node a, Object o) {
if (comparator != null)
return comparator.compare((K) a.key, (K) o);
return ((Comparable<K>) a.key).compareTo((K) o);
}
public V get(Object k) {
K key = (K) k;
Node<K, V> current = head;
for (int i = head.height - 1; i >= 0; i--) {
Node<K, V> right;
while ((right = current.right[i]) != null) {
int cmp = compare(right, key);
...
}
}
}
Unfortunately I'm still not exactly clear on the cause, but from my experience, it seems from explicit casts, like:
((Comparable) obj).compareTo(other)
The Javascript generated looks like:
dynamicCast(obj, 1).compareTo(other);
Where 1 is a generated typeId representing the target of the cast. dynamicCast in turn calls canCastUnsafe and if false, it throws a ClassCastException. The value of this has been debated, since this would already be caught in hosted mode.
It can be sidestepped with JSNI:
public static native int compare(Object a, Object b) /*-{
return a.#java.lang.Comparable::compareTo(Ljava/lang/Object;)(b);
}-*/;
Dunno if you've seen this thread in the GWT Contributor's forum...
Basically, it starts with the same problem you've identified, proposes some new compiler flags, and goes on to show how to use some JSNI to get around the casts.
Edit In the GWT trunk there's a new compiler flag. See the wiki...
An updated answer for GWT version 2.1 and later:
Since GWT 2.1 (at least that's the first mention), the GWT compiler has a new compiler argument called -XdisableCastChecking that disables all runtime checking of casts.
Note, this option is marked as experimental (probably because this would make class cast exceptions very hard to debug).
In my app dynamicCast was called thousands of times in a short profile run, and were the the 3rd most time consuming method in the Firebug profiler. Using this compiler argument significantly reduced the number of "Long Duration Events" messages in the Chrome Speed Tracer.
See GWT Compiler Options for this and other Compiler arguments.
It's definitely a compiler problem: I have the problem on the following line:
final DefaultIconedSuggestBox<SuggestValueProxy, IconedValueHolderItem<SuggestValueProxy>> fieldValueWidget = getCategoryWidget().getFieldValueWidget();
I don't really know how I can workaround it: this line happens in a moment I'm changing from a module to another (it is maybe related to the code splitter issue: even though I'm not using code split: I'm just loading another page with another module)
Does the use of java 1.5 generics and wildcards could avoid this ?