Updating to the latest version of AudioKit left me changing several AKCallbackInstrument instances over to the new AKMIDICallbackInstrument class which now incorporates the former as legacy behavior. When doing so however, I ran into this weird error. Maybe a Swift nuance I am missing?
let callback = AKMIDICallbackInstrument() { status, note, velocity in
if status == .noteOn { //errors out
// do something
}
}
Comparing status to .noteOn errors out with:
"Expression type 'Bool' is ambiguous without more context.". Makes sense, because AKMIDICallbackInstrument is not returning an AKMIDIStatus in status anymore, but a straight MIDIByte (UInt8). Using direct MIDI command numerics works.
let callback = AKMIDICallbackInstrument() { status, note, velocity in
if status == 0x90 {
// do something
}
}
So we have a problem and a potential solution. I'm just not sure that this is the way to go and AKMIDICallbackInstrument didn't hit the docs yet.
For the time being, you can convert the MIDIByte to AKMIDIStatus like this:
let status = AKMIDIStatus(rawValue: Int(statusByte >> 4))
On the develop branch, there is a new initializer for AKMIDIStatus that directly takes MIDIByte as a parameter to make this a little easier.
Related
I'm still trying to create a calendar app and ran into another problem I wasn't able to find a solution for online.
Xcode throws the error "Missing argument for parameter #1 in call" in line 2 of my code sample. I used similar code at other places before, but I can't find the difference in this one.
Also this code worked before and started throwing this error after I moved some code to the new View DayViewEvent after getting the error "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions", which I hoped to fix it and would be clean code anyway.
For reference: events is an optional array of EKEvents (hence the first if) and selectedDate is (obviously) a Date.
Any help is greatly appreciated!
if let events = events {
ForEach(events, id: \.self) { event in
if !event.isAllDay {
DayViewEvent(selectedDate: selectedDate, event: event)
}
}
}
The body func is called on every state change so needs to be as fast as possible thus the data needed should already be processed. So need to filter your events in a func or block, e.g. in onAppear:
struct EventsView: View {
#State var events = [Events]()
var body: some View {
ForEach(events, id: \.eventIdentifier) { event in
DayViewEvent(event: event)
}
.onAppear {
events = EventsDB.shared.events(isAllDay: false)
}
}
}
And by the way, since you are using id: \.self because event is a reference type you need to ensure when retrieving the events that the same event always returns the same instance and not a new instance. If unique instances are returned then you need to instead use an id that is a unique property, e.g. id: \.eventIdentifier.
Also you should know that the SwiftUI declarative syntax inside body is not like normal programming, the ifs and for loops all generate some very complex code, e.g. _ConditionalContent when an if is used, read up on it here: https://swiftwithmajid.com/2021/12/09/structural-identity-in-swiftui/ or watch Apple's WWDC video Demystify SwiftUI.
Is there a construct that communicates to the type checker a function's post-condition?
For example, in typescript it is possible to say
function assertIsNumber(value: any): asserts value is number {
if (typeof value !== 'number') {
throw new TypeError();
}
}
I would like to be able to do something like the following in dart:
class SomeClass {
int? value;
_checkPreconditions() {
if(value == null) {
throw MyPreconditionError()
}
// ...
}
somefunc() {
_checkPreconditions();
// here we know `value` is a non-null int.
final sum = value + 5;
}
}
I understand I could coerce the value to non-null sum = value! + 5, but I would prefer to allow the function to inform the type checker if possible.
It looks like the type system of Dart is not so powerful. The only thing that looks (from first glance) possible is to create a custom code analyzer package (or search for one that already exists).
Dart annotations don't actually do anything. They provide hints to tools such as the Dart analyzer (usually so that it can generate additional warnings), but they cannot change program behavior. Even if you could convince the analyzer to treat some variables as different types, you still wouldn't be able to compile and run your code.
Annotations can be used by code generation tools, so one possibility might be to generate a statement such as final value = this.value!; automatically. However, that would be a lot of trouble to go through (and would mean that code then would need to use this.value = 42; for assignments and would prevent your code from being analyzed directly).
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.
For some reason LLDB is not showing me the contents of variables while I am stepping through my Swift code. The actual execution works fine, but no matter what I try I can't see the contents of my strings!
Here's what I see in the variable list:
At this point type contains "name" and value contains "Logan". But you wouldn't be able to tell that looking here. If I use the "quick look" button, it says the value is "(None)".
And I get this kind of gibberish when I try to po a String from the console:
(lldb) po space
error: <REPL>:1:1: error: non-nominal type '$__lldb_context' cannot be extended
extension $__lldb_context {
^
<REPL>:11:5: error: 'Space.Type' does not have a member named '$__lldb_wrapped_expr_0'
$__lldb_injected_self.$__lldb_wrapped_expr_0(
^
However this varies. Sometimes I'll get something like:
class name = __NSAtom
or
Printing description of [0]:
(String) [0] = {
core = {
_baseAddress = Builtin.RawPointer = 0x00000001004016f0
_countAndFlags = -4611686018427387894
_owner = Some {
Some = (instance_type = Builtin.RawPointer = 0x0000000100401820 -> 0x00007fff7b3d5390 (void *)0x00007fff7b3d5340: __NSCFString)
}
}
}
or
Printing description of declaration:
(String) declaration = <DW_OP_piece for offset 8: top of stack is not a piece>
...but never the actual contents of the string!
Update:
I've noticed the problem only seems to start occurring once a call to componentsSeparatedByString() is made in the function. (This happens right at the top so as I was stepping I didn't notice that the debugger actually does show the value until this point.) So something weird is going on with that function. I've updated the question title to reflect this new information.
Interestingly, it seems once the string has been "corrupted" by this call, you can't view it anywhere else, even when passed to a different function. And any regular string variables are not viewable either. Definitely a bug, but I wonder if there's a workaround. It's getting really hard to debug my program!
When I've been encountering this, I've used either NSLog("\(myThing)") in the compiled code I want to debug, or have been calling expression NSLog("\(myThing)") while in the debugger's REPL
(note that you do not want to do NSLog("(someVariable)") as the expanded string could contain % format sequences - use NSLog("%#", "(someVariable)") or NSLog("%#", someVariable) instead)
I'd like to add an update: this problem still occurs in the latest versions of Xcode, both 6.2 release and 6.3 beta.
The problem is part of componentsSeparatedByString, and if you replace that with split everything works fine. I had four instances of this, and as soon as I changed them my app stopped crashing with a Zombie release of NSString, and all my variable names started working. I changed things like this...
let bits = value!.componentsSeparatedByString(" ")
with...
let bits = split(value!, { $0 == " "}, maxSplit: Int.max, allowEmptySlices: false)
I don't think split is nearly as readable, but at least it works!
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.