I'd like to do something like this:
enum COLORS = {"green", "red", "blue"};
output [show(type(COLORS)];
And I would expect this to output enum. I can't seem to find out from the docs how to do this.
MiniZinc currently does not include any reflection operations that will allow you to get the name of the type.
Your example might actually not be a great one, because the enum keyword semantically creates a new type, in this case COLORS. So my intuition for what a type function would return would be COLORS, not enum.
If you feel this could be a useful feature (and you maybe have a more extensive example where this is used), then you can submit an issue to the MiniZinc issue tracker: https://github.com/MiniZinc/libminizinc/issues
Related
Let's say I'm using gdscript static typing and for one function parameter I don't know in advance what I'm going to get. That's what typing.Any is for in python. How do I do it with gdscript?
It seems that Variant is not a valid type and I'm not sure about using Object for that purpose (since it could be a built-in)
edit
Leaving the type blank obviously works, but the docs has a specific section called typed-or-dynamic-stick-to-one-style, and since we're already kinda short on good practices using gdscript I'd rather find another way
Any idea?
As of Godot 3.2, GDScript does not feature a Variant or any type hint yet. However, you can still use the Object type hint if you expect a variable to hold any object (or null, as Object is nullable by design). Object may not hold primitive types like int or bool though.
Therefore, you should just leave out the type hint for now.
I have a bunch of classes which carry out functionality, but with type hinting I wanted to now have it show an instance of that class, Or a list of instances of that class.
class Foo:
pass
class Bar:
pass
class Win:
pass
I then started seeing Typings, and was doing things like:
get_all_foos() -> list:
return []
which makes sense, but i wanted it to be more verbose. Something akin to:
get_all_foos() -> list<Foo>:
return []
I was looking online and it seems that I might need to use the LIST typing, instead of base list.
from typing import List
get_all_foo() -> List[Foo]:
pass
While I dont think i was getting any errors, I wanted to make sure this was the correct way to do things per Python standard or if it suitable to just do:
get_all_foo() -> list[Foo]:
pass
The answer, based on research on the python docs, is as follows.
A list is something which can be implemented. It is a datastructure.
A List is a typing, which is used for type hinting. It is not a datastructure.
For people familiar with other typed languages, my mistake was that I was mistaking a List also as an alternate Datastructure with a similar implementation of list.
So that means, that you can have a function:
get_all() -> List[Foo]: pass
BUT the return type can't be a List, for reasons stated above.
It would still be a list as that is the actual datastructure. it is purely for decorator purposes. I was having issues conceptually with the fact that I was trying to enforce typing by making things be a List as the samples were showing, but since it wasnt instantiable, it all made sense.
Therefore you would easily have
def get_all() -> List[Foo]: return []
which returns a list. I was thinking both the hint and return should be the same type.
I am trying to extend the geo.StreetSuffix enum to include some more possible values. It currently doesn't have a value for Greene which is a valid street suffix. This is what my concept looks like:
enum (StreetSuffix) {
description (Street Suffix)
extends(geo.StreetSuffix)
symbol (Greene)
}
This is a training sample:
[g:Evaluate:prompt] (19)[v:geo.StreetNumber] (Fake Hills)[v:geo.StreetName] (Lane)[v:StreetSuffix:Lane]
When I do this though the training files give me the following error:
Confusion Points: Match(es) on : "Lane". and the language recognition no longer works for that value. Am I doing something wrong here, is there a bug, or is this not how Enum inheritance is supposed to work?
I am happy to write my own enum which would be a copy of geo.StreetSuffix but it seems like a waste if I could just extend it and add some of my own values.
Unfortunately, you'd have to copy everything from the old vocab file (which you don't have access to).
Note
If you extend a type into another capsule, a new vocabulary file must still be created. Vocabulary is never inherited, even if you use extends or add role-of to a model.
https://bixbydevelopers.com/dev/docs/dev-guide/developers/training.vocabulary#adding-vocabulary
That being said, you can file a ticket with support to add Greene and any other missing values you might come across...
In Swift, sometimes, keywords are plain keywords, and some others start with an #.
For instance, weak, unowned, inout, class are plain. But #final, #lazy start with #.
Sometimes, we even have both! prefix and #prefix, infix and #infix for instance.
It is not entirely an Objective-C inheritance since we have #class and not class in Objective-C. I could understand why we have class and not #class in Swift, but since we have #final or #lazy , I would have thought that it should be #weak and not weak.
Why this choice? Is there a kind of intuitive way that should tell: "hey, it is logical that this keyword starts with #?
Even if I think with a preprocessor perspective in mind, it is not obvious that # would call a kind of specific preprocessor before compilation (e.g. #final is not really a kind of preprocessor directive).
#-prefixed items in Swift are not keywords, these are attributes.
Apple's book on Swift says that
Attributes provide more information about a declaration or type. There are two kinds of attributes in Swift, those that apply to declarations and those that apply to types.
Some attributes (such as #objc(isEnabled)) accept parameters.
The main difference between attributes and keywords is that keywords tell the compiler what you are defining (a class, a method, a property, a variable, and so on), while attributes tell the compiler in what contexts you intend to use that definition. For example, you would use a func keyword to tell the compiler that you are defining a function, and decorate that function with an #infix attribute to tell the compiler that you plan to use that function as an infix operator.
I want to make a color map on vtkstructuredgrid and I need the colors to be interpolated between cells. The other option is using point data but when ever I use
structuredgrid->PointData()->SetScalars(Floatarray);
it says I cant have a pointer to a incomplete class type.
Any help would be greatly appreciated.
Your approach should work...
However, PointData is not a method, for the vtkStructuredGrid class: you should avoid (), and that's the reason for the error (Pointer to incomplete class type is not allowed).
Moreover, PointData is protected, in the "standard" definition of vtkStructuredGrid, and you should derive the entire class to access it from your code.
Before trying that, by the way, can you try with
structuredgrid->GetPointData()->SetScalars(Floatarray);
?
It should work too (not sure about the parameter type passed to SetScalar(), BTW).