I'm trying to add an enum type to an Array and am getting an error. I am able to add a String and other types, but this enum is failing. Does anyone know what might be going wrong here?
enum Domain {
case Default
}
let domains: Array<Domain> = [.Default]
Thread 1:EXC_BAD_INSTRUCTION(code=EXC_i386_INVOP, subcode=0x0)
This is definitely an Apple bug - log it! https://bugreport.apple.com
Add a second case to your Enumeration (e.g. case Other) and see that the error no longer occurs. Something crazy is going on in Swift when an Enumeration has only one case.
It looks like, at least in my playing with a playground, if the enum definition contains the word 'Domain' at all anywhere in the name the enum fails to compile/work.
I think it's just a compiler bug on Apple's part... If I have the following code, and only this code, everything runs fine:
var points = TestEnum[]()
points += TestEnum.TestValue
enum TestEnum {
case TestValue
case SecondTestValue
}
However, I have code above that code (a simple RPN implementation, but it doesn't matter). The RPN code runs fine by itself. But with the TestEnum code in there, the RPN code crashes. The crash is an EXC_BAD_ACCESS and crashes on a random line and different address based on what lines of code are in the program (I'm guessing because the offsets in the executable change). For instance, I added a println after the points += call, and it crashed at a different part of my RPN code.
Both the RPN code and the TestEnum code run fine by themselves. This is almost definitely an Apple bug.
Related
With an enum typedef'd in a global header file used throughout my project, I am unable to refer to the individual enum values by name while using lldb in Xcode.
For example, if I am stopped at a breakpoint anywhere the enum type is available, and I try to evaluate something at the lldb prompt in Xcode (e.g. (lldb) p (int)EnumConstant), lldb complains:
error: use of undeclared identifier 'EnumConstant'
Furthermore, if I try to set a conditional breakpoint using an enum constant in the condition (e.g. right-click breakpoint in Xcode > Edit Breakpoint... > Condition: EnumConstant == someLocalVar), then Xcode complains every time it tries to evaluate that condition at that breakpoint:
Stopped due to an error evaluating condition of breakpoint 1.1: "EnumConstant == someLocalVar"
Couldn't parse conditional expression:
error: use of undeclared identifier 'EnumConstant'
Xcode's code completion popover even resolves a suggestion for the enum constant when I begin typing the name in the "Edit Breakpoint..." window, so Xcode itself doesn't have a problem resolving it.
Is there an option I can set in lldb or Xcode so that lldb maintains the enum identifiers after compilation? I'm assuming the enum constants get translated to their ordinal value during compilation, causing the executable to discard the identifiers, but thats just my naive speculation.
When I use the equivalent code in a simple GNU C program in Linux or Cygwin (minus the class definitions obviously), but using gcc/gdb instead of Xcode/lldb, I don't have these problems. It is able to resolve the enum values no problem.
I've created a tiny Xcode iPhone project to demonstrate what I mean. Using any of the enum_t constants below within the ViewController.m context (the for-loop is a good place to demo) will produce the same results.
ViewController.h:
#import <UIKit/UIKit.h>
#interface ViewController : UIViewController
typedef enum
{
eZero, eOne, eTwo, eCOUNT
}
enum_t;
extern NSString const * const ENUM_STR[];
#end
ViewController.m:
#import "ViewController.h"
#implementation ViewController
NSString const * const ENUM_STR[eCOUNT] = { #"eZero", #"eOne", #"eTwo" };
- (void)viewDidLoad
{
[super viewDidLoad];
for (enum_t value = eZero; value < eCOUNT; ++value)
{
NSLog(#"%-8# = %d", ENUM_STR[value], value);
}
}
#end
This is a bug (fairly longstanding) in how the name->Debug Information lookup-accelerator tables for enums are built. While enum types are listed, enum values are not. That was surely done to save output debug info size - debug information gets quite big pretty quickly, and so there's a constant tension between the cost of adding more info and the utility of that more info. So far this one hasn't risen to the level of inclusion.
Anyway, doing a search through "all debug information for anything with a name that matches 'eZero'" is prohibitively slow even for decent sized projects, and gets really bad for large ones. So lldb always uses these name->Debug Info tables for its first level access.
Because the accelerator tables do contain the enum type by name (and more important for you typedefs by name as well), the workaround is to do:
(lldb) expr enum_t::eZero
(int) $0 = 0
Of course, if you have truly anonymous enums, then you are pretty much out of luck till this info gets added to the accelerator tables.
BTW, the Xcode symbol completion in the Debugger Console window is done using the Xcode SourceKit indexer, not lldb. So the completions offered from Xcode are not a reflection of lldb's knowledge of the program.
BBTW, gdb doesn't use compiler-made accelerator tables (these were an Apple extension up till the new DWARF 5 standard) but manually builds an index by scanning the debug info. That allows them to index whatever seems best to the debugger. OTOH, it makes debugger startup quite a bit slower for big projects.
I must be a moron or something but I'm scratching my head for a third day in a row and can't figure out what's going wrong with my intention to encode some JSON data in my Swift program...
Here's the situation:
I've got two classes as follows:
class Node: Codable {
// Nothing in here
}
and
class Shape: Node {
// No code here too
}
Then, I have an attempt to encode the subclass as follows:
do {
let encodedData = try JSONEncoder().encode(Shape())
} catch {
print(error)
}
This is all I have added to an empty Single View App project. When I run it, I get "Thread 1: EXC_BAD_ACCESS (code=1, address=0x350)" crash.
Of course, initially my classes used to have a lot of properties which were Codable too. I thought it was any of them, so I stripped them off but it appears it's not the properties that are causing the crash...
I'm running Xcode 9.3 on a High Sierra MacBook Pro. Is there anyone willing to reproduce this or anyone already bumped his head into such an odd behavior?
This is a known bug and you can work around it by turning on Whole Module Compilation mode for the Debug configuration, or by upgrading to Xcode 10 beta.
everyone, I am a new one to iOS app development using swift.
I am studying a ibeacon app sample code which downloaded from the https://github.com/SelimSalihovic/CityOS-iBeacon-Swift-Tutorial.
while I was running the code, there are errors in the code as shown the following page, could you help me how to solve it, please! Thanks in advance!
The first one is easily solveable by unwrapping the value (the exclamation mark)
NSUUID(UUIDString: "B9407F30-F5F8-466E-AFF9-25556B57FE6D")!
Second and third error are due to the beacons array not declaring the content's type (AnyObject means it can't be any class, which is not guaranteed to have the properties the code is looking for) so just go to line 16 and make the following change
var beacons : [CLBeacon] = []
However this will still not compile because the LocationServices framework hasn't been imported in the project, to do so just add
import CoreLocation
There will be some more errors now, specifically at line 26 and 55 in BeaconTableViewController
Fix-It has the right suggestion for these, basically you need to cast note.object by adding as! [CLBeacon] and remove the unwrapping on switch proximity because the value isn't optional
The code now compiles properly for me, I'm not sure it will work because I can't test right now, but it should be a step in the right direction
Good luck with your journey in iBeacons, they're a pretty fun technology to work with
I'm new to programming and I've started taking the stanford course on iTunes U for making an iPhone 8 app. They're using Xcode 6 and Swift 1 while I'm in El Capitan using Xcode 7 and Swift 2. I've found a few differences in code that Xcode has been able to pick up on and help me correct ("println" is now "print" for example), but I'm getting tripped up on one particular part of the code:
var displayValue: Double {
get {
return NSNumberFormatter().numberFromString(display.text!)!.doubleValue
}
set {
display.text = "\(newValue)"
userIsInTheMiddleOfTypingANumber = false
}
}
I've double checked several times to make sure this is exactly how the teacher wrote it. His built correctly and functioned correctly, while mine builds correctly, but shows this fatal error when I try to operate it, "unexpectedly found nil while unwrapping an Optional value" (see screenshot for all the details).
Screenshot of the error
I've been looking around the internet and found a few similar examples, including one on this site (Stanford Calculator app keeps crashing), but after trying everything that was suggested I concluded that something must be unique in my system or I'm operating in a new Xcode/Swift environment than the others that had this problem. None of the solutions have resolved the problem, and all of them added errors of their own.
In responding to someone else's question someone suggested that we use this code to ensure that if "nil" is returned by "display" that it will provide "0" instead:
return (NSNumberFormatter().numberFromString(display.text) as? Double) ?? 0
I tried this, but it only gave me more errors, some seem to be related to Swift 2 (it required a comma after double, wanted me to unwrap display.text, and complained that there was an expected expression missing—maybe the suggested code was good in Swift 1??).
I've double checked several times to make sure this is exactly how the teacher wrote it. His built correctly and functioned correctly, while mine builds correctly, but shows this fatal error when I try to operate it, "unexpectedly found nil while unwrapping an Optional value"
I suspect that display is an IBOutlet property that needs to be connected to something in the user interface, probably a text field. If it's not connected, then even though your code is exactly the same, you'll get nil when you try to use its text property, and unwrapping that will cause the error you're seeing.
Whether or not the advice above actually solves your problem, what you really need to do is to set a breakpoint a line or two before the spot where the crash occurs and step through the code. Look at the variables involved and figure out where that nil value is coming from. You can work backward from there and figure out why the thing that you expect not to be nil is, in fact, nil. Learning to work that way will help you work out these kinds of problems when they occur (and they will occur again).
Not sure if you've found the answer or not by now, but I ran into a similar problem this morning and thought I'd share what I found.
While debugging, I entered two console logs to a simplified version of my operate like so:
case "x": if operandStack.count >= 2 {
print(" display before popping is: \(display.text!) ")
displayValue = operandStack.removeLast() * operandStack.removeLast()
print(" display after popping is: \(display.text!) ")
enter()
}
Display after popping came up as "newValue". I couldn't figure out what that meant at first, but realized that my issue is the setter. newValue is an optional that should be unwrapped i.e. "(newValue)!"
P.S. I opted to return:
return (display.text! as NSString).doubleValue
in my get.
Also, since newValue is unwrapped, keep in mind it will crash if display is set to nil.
I'm trying to use CoreBluetooth's retrievePeripheral :
- (void)retrievePeripherals:(NSArray *)peripheralUUIDs;
The documentation says peripheralUUIDs should be a NSArray of CFUUIDRef. In the Apple sample project temperatureSensor, it is called as :
[centralManager retrievePeripherals:[NSArray arrayWithObject:(id)uuid]];
(uuid being a CFUUIDRef)
When I use the exact same code in XCode 4.5.1, IOS6, I'm getting a error :
Cast of C pointer type 'CFUUIDRef' (aka 'const struct __CFUUID *') to Objective-C pointer type 'id' requires a bridged cast
I would say (though I'm far from sure) that the reason it works in TemperatureSensor and not in my project is because TemperatureSensor seems not to use ARC whereas my project does.
Xcode suggests 2 ways of solving the problem : adding a __bridge or using CFBridgingRelease(). I tried them both and I'm under the impression that the function does not work [Edit] because the delegate methode didRetrievePeripheral: never gets called [/Edit] (my understanding is that these operation would change the C-style structs into objective-C-objects thus creating a NSUUID, and the method can't use it, but, again I'm really not sure)
So what should I do ? I've been searching on google for examples of retrievePeripherals using ARC, but without success.
In the temperature sensor change this line and run
LeDiscovery.m
-(void) startScanningForUUIDString:(NSString *)uuidString
{
[centralManager scanForPeripheralsWithServices:nil options:0];
}
change the word nil and assume 0.
If you want more check this link.
I hope its useful for you.
Turns out the problem was much simpler than that. I copied/pasted some code from TemperatureSensor, specifically the DidRetrievePeripheral. But it turns out, there's an error in this code (it's DidRetrievePeripheralS), so the delegate method never gets called. I think the bug is already reported.
Thanks/sorry