I'm trying to detect a shaking motion in an up and down direction like this:
/ \
|
________________________________
| |
| |
| |
|o |
| |
| |
|______________________________|
|
\ /
-(void) bounce:(UIAcceleration *)acceleration {
NSLog(#"%f",acceleration.x);
}
I was thinking it's the x axis but that responds if you turn it to be parallel to the floor. How do I detect this?
I don't have a direct answer for you, but a great experiment is to make a quick app which spews the numbers out onto the screen or into a file (or both). Then shake it the way to you want to detect, and see which set has the greatest change.
Related
I use idea 2021.2 and corresponding markdown plugin. But the simple table cannot display in previous mode:
Why? I found somebody has related the problem to the JavaFx, however, I think it is occured in old version idea. I cannot find javafx render option in my version.
How to solve it?
You are using the wrong Markdown syntax.
The following code works fine (minimum three - for table header)
| Column 1 | Column 2 |
| :--- | :--- |
| AAA | BBB |
I am struggling to load most of the Drug Ontology OWL files and most of the ChEBI OWL files into GraphDB free v8.3 repository with Optimized OWL Horst reasoning on.
is this possible? Should I do something other than "be patient?"
Details:
I'm using the loadrdf offline bulk loader to populate an AWS r4.16xlarge instance with 488.0 GiB and 64 vCPUs
Over the weekend, I played around with different pool buffer sizes and found that most of these files individually load fastest with a pool buffer of 2,000 or 20,000 statements instead of the suggested 200,000. I also added -Xmx470g to the loadrdf script. Most of the OWL files would load individually in less than one hour.
Around 10 pm EDT last night, I started to load all of the files listed below simultaneously. Now it's 11 hours later, and there are still millions of statements to go. The load rate is around 70/second now. It appears that only 30% of my RAM is being used, but the CPU load is consistently around 60.
are there websites that document other people doing something of this scale?
should I be using a different reasoning configuration? I chose this configuration as it was the fastest loading OWL configuration, based on my experiments over the weekend. I think I will need to look for relationships that go beyond rdfs:subClassOf.
Files I'm trying to load:
+-------------+------------+---------------------+
| bytes | statements | file |
+-------------+------------+---------------------+
| 471,265,716 | 4,268,532 | chebi.owl |
| 61,529 | 451 | chebi-disjoints.owl |
| 82,449 | 1,076 | chebi-proteins.owl |
| 10,237,338 | 135,369 | dron-chebi.owl |
| 2,374 | 16 | dron-full.owl |
| 170,896 | 2,257 | dron-hand.owl |
| 140,434,070 | 1,986,609 | dron-ingredient.owl |
| 2,391 | 16 | dron-lite.owl |
| 234,853,064 | 2,495,144 | dron-ndc.owl |
| 4,970 | 28 | dron-pro.owl |
| 37,198,480 | 301,031 | dron-rxnorm.owl |
| 137,507 | 1,228 | dron-upper.owl |
+-------------+------------+---------------------+
#MarkMiller you can take a look at the Preload tool, which is part of GraphDB 8.4.0 release. It's specially designed to handle large amount of data with constant speed. Note that it works without inference, so you'll need to load your data and then change the ruleset and reinfer the statements.
http://graphdb.ontotext.com/documentation/free/loading-data-using-preload.html
Just typing out #Konstantin Petrov's correct suggestion with tidier formatting. All of these queries should be run in the repository of interest... at some point in working this out, I misled myself into thinking that I should be connected to the SYSTEM repo when running these queries.
All of these queries also require the following prefix definition
prefix sys: <http://www.ontotext.com/owlim/system#>
This doesn't directly address the timing/performance of loading large datasets into an OWL reasoning repository, but it does show how to switch to a higher level of reasoning after loading lots of triples into a no-inference ("empty" ruleset) repository.
Could start by querying for the current reasoning level/rule set, and then run this same select statement after each insert.
SELECT ?state ?ruleset {
?state sys:listRulesets ?ruleset
}
Add a predefined ruleset
INSERT DATA {
_:b sys:addRuleset "rdfsplus-optimized"
}
Make the new ruleset the default
INSERT DATA {
_:b sys:defaultRuleset "rdfsplus-optimized"
}
Re-infer... could take a long time!
INSERT DATA {
[] <http://www.ontotext.com/owlim/system#reinfer> []
}
ALL,
Is it possible to get the version of the RichEdit control the program uses?
| Version | Class name | Library | Shipped with | New features
|------------|---------------|--------------|-----------------|
| 1.0 | "RICHEDIT" | Riched32.dll | Windows 95 |
| 2.0 | "RichEdit20W" | Riched20.dll | Windows 98 | ITextDocument
| 3.0 | "RichEdit20W" | Riched20.dll | Windows 2000 | ITextDocument2
| 3.1 | "RichEdit20W" | Riched20.dll | Server 2003 |
| 4.1 | "RICHEDIT50" | Msftedit.dll | Windows XP SP1 | tomApplyTmp
| 7.5 | "RICHEDIT50" | Msftedit.dll | Windows 8 | ITextDocument2 (new), ITextDocument2Old, Spell checking, Ink support, Office Math
| 8.5 | "RICHEDIT50" | Msftedit.dll | Windows 10 | LocaleName, more image formats
I know I can just have some variable and assign it appropriately if Msftedit.dll library is loaded or not. However if I do load RichEd20.dll, I can get either RichEdit 2 or RichEdit 3 implementation. And they are quite different. A lot of stuff were added in the latter.
If i did load Msftedit.dll, there are features that 7.5 that would not be available in earlier versions (e.g. automatic spell checking).
It's even possible that the same process can have all three DLLs loaded, and even using all three versions of RichEdit in the same process:
"RICHEDIT" → 1.0
"RichEdit20W" → 2.0, 3.0
"RICHEDIT50" → 4.1, 7.5, 8.5
Given a RichEdit control (e.g. WinForms RichTextBox, WPF RichTextBox, WinRT RichEditBox, VCL TRichEdit) is there a way to determine the version of a RichEdit control?
Or maybe I can somehow differentiate them by Windows version where it is available?
If using c++ you may find the following snippet useful to read out the class name :
TCHAR className[MAX_PATH];
GetClassName(GetRichEditCtrl().GetSafeHwnd(), className, _countof(className));
GetRichEditCtrl() is function on another control, you may need to substitute with whatever gives you a hwnd to the control.
Another method is using a tool like spy++ to inspect the class name.
Any best practices of creating acceptance and functional tests for multilingual sites? I would like to test content and functionality on multiple languages but not duplicate the tests.
If we take Behat, how to arrange a test environment from the very beginning?
You could use Scenario Outlines: http://behat.readthedocs.org/en/v2.5/guides/1.gherkin.html#scenario-outlines
language | label1 | label2 |
es | Hola | Adios |
en | Hello | Bye |
I have a project that has both an iOS and an OS X target. Is there a preprocessor macro that is true when I'm compiling for OS X? I tried this:
#if TARGET_OS_MAC
#interface BFNode : NSObject <NSPasteboardReading, NSPasteboardWriting> {
#else
#interface BFNode : NSObject {
#endif
But TARGET_OS_MAC doesn't seem to work. When I try to run the app on iOS I get a compiler error, because it tries to compile the first line and there is no NSPasteboardReading protocol defined on iOS.
I know there is TARGET_OS_IPHONE too. If I use that and swap the #interface declarations it works.
But there are a lot of places where I have code, that has no iOS version, so I need a macro for OS X too.
SOLUTION:
I ended up defining a new macro in the .pch file:
#define TARGET_OSX TARGET_OS_IPHONE == 0
The documentation in TargetConditionals.h has this diagram (it seems, as of 2022; any platform):
+---------------------------------------------------------------------+
| TARGET_OS_MAC |
| +---+ +-----------------------------------------------+ +---------+ |
| | | | TARGET_OS_IPHONE | | | |
| | | | +---------------+ +----+ +-------+ +--------+ | | | |
| | | | | IOS | | | | | | | | | | |
| |OSX| | |+-------------+| | TV | | WATCH | | BRIDGE | | |DRIVERKIT| |
| | | | || MACCATALYST || | | | | | | | | | |
| | | | |+-------------+| | | | | | | | | | |
| | | | +---------------+ +----+ +-------+ +--------+ | | | |
| +---+ +-----------------------------------------------+ +---------+ |
+---------------------------------------------------------------------+
This tells us:
TARGET_OS_MAC will be 1 for (probably) any Cocoa application running on an Apple platform.
TARGET_OS_OSX will only be 1 for macOS targets
TARGET_OS_IPHONE will be 1 for any non-Mac Apple products
TARGET_OS_IOS is just for iOS
TARGET_OS_MACCATALYST is just for Project Catalyst. It seems TARGET_OS_UIKITFORMAC will also work.
TARGET_OS_TV is just for tvOS
TARGET_OS_WATCH is just for watchOS
TARGET_OS_BRIDGE is just for bridgeOS (which currently doesn't even support 3rd-party apps so you'll likely always see that be 0)
TARGET_OS_DRIVERKIT will be 1 when building for DriverKit
⚠️ But wait! ⚠️
I got that from the iOS 14 (macOS 11, watchOS 7) SDK. If I look back into the iOS 13 (macOS 10.15, watchOS 6) SDK, I see this:
+----------------------------------------------------------------+
| TARGET_OS_MAC |
| +---+ +-----------------------------------------------------+ |
| | | | TARGET_OS_IPHONE | |
| |OSX| | +-----+ +----+ +-------+ +--------+ +-------------+ | |
| | | | | IOS | | TV | | WATCH | | BRIDGE | | MACCATALYST | | |
| | | | +-----+ +----+ +-------+ +--------+ +-------------+ | |
| +---+ +-----------------------------------------------------+ |
+----------------------------------------------------------------+
Notably, TARGET_OS_DRIVERKIT is new in 14, and TARGET_OS_MACCATALYST is inside IOS now. This tells us that compiling against the iOS 14 / macOS 11 SDK can break some C code written for iOS 13 / macOS 10.15, if it assumes that TARGET_OS_MACCATALYST and TARGET_OS_IOS are completely separate.
There's More!
Additionally, these are defined:
TARGET_OS_SIMULATOR is just for iOS, tvOS, and watchOS simulators. You can further refine this using the above #defines
TARGET_OS_WIN32 is in case you wanna use Apple's SDKs to make Windows apps. I don't personally know of any other than Apple's own (like iTunes, Safari, and QuickTime). This might become useful now that Swift has Windows support, if you want to take existing Objective-C code with you.
TARGET_OS_UNIX is for non-Apple UNIX systems
And these are deprecated, and should not be used anymore. That said, you might find them in code you have to maintain, so here's what they meant:
TARGET_IPHONE_SIMULATOR used to mean the iPhoneOS simulator. Use TARGET_OS_SIMULATOR instead (along with TARGET_OS_IOS to target only iOS simulators)
TARGET_OS_EMBEDDED used to mean iOS, tvOS, and watchOS non-simulated devices. Use the standard OS targets instead.
TARGET_OS_NANO probably used to mean iPod Nano (I can't find any historical usage online). Apple advises to use TARGET_OS_WATCH instead.
Something else to note is that the TargetConditionals.h which is used in swift-corelibs-foundation is significantly different, and includes #defines for Android, Cygwin, and other not-explicitly-supported-but-they-technically-work platforms.
I'm not entirely sure what to make of this. I would guess it's for compiling the Swift Foundation framework, and not for consuming it, since Swift doesn't consume #defines.
If you're using Swift, there's a great language feature for this. If you're using Objective-C, it's often useful to do something like this:
#include <TargetConditionals.h>
#if TARGET_OS_IPHONE
#import UIKit;
#else
#import AppKit;
#endif
Understanding the TARGET_OS_* defines will make this make a lot more sense. Most notably, TARGET_OS_MAC is any Apple platform which is pretty unexpected. !TARGET_OS_IPHONE is macOS and TARGET_OS_IPHONE is anything besides that. There are more specific defines for iOS, tvOS, and watchOS.
From TargetConditions.h:
TARGET_OS_*
These conditionals specify in which Operating System the generated code will
run. Indention is used to show which conditionals are evolutionary subclasses.
The MAC/WIN32/UNIX conditionals are mutually exclusive.
The IOS/TV/WATCH conditionals are mutually exclusive.
TARGET_OS_WIN32 - Generated code will run under 32-bit Windows
TARGET_OS_UNIX - Generated code will run under some Unix (not OSX)
TARGET_OS_MAC - Generated code will run under Mac OS X variant
TARGET_OS_IPHONE - Generated code for firmware, devices, or simulator
TARGET_OS_IOS - Generated code will run under iOS
TARGET_OS_TV - Generated code will run under Apple TV OS
TARGET_OS_WATCH - Generated code will run under Apple Watch OS
TARGET_OS_SIMULATOR - Generated code will run under a simulator
TARGET_OS_EMBEDDED - Generated code for firmware
TARGET_IPHONE_SIMULATOR - DEPRECATED: Same as TARGET_OS_SIMULATOR
TARGET_OS_NANO - DEPRECATED: Same as TARGET_OS_WATCH
That is because TARGET_OS_MAC is defined when building for iOS as well.
See http://sealiesoftware.com/blog/archive/2010/8/16/TargetConditionalsh.html on that.
I would try and build my own target specific define via build-settings on the target.
As of Xcode 8 GM, this is the relevant section of TargetConditionals.h in iOS 10.0:
#define TARGET_OS_MAC 1
#define TARGET_OS_WIN32 0
#define TARGET_OS_UNIX 0
#define TARGET_OS_OSX 0
#define TARGET_OS_IPHONE 1
#define TARGET_OS_IOS 1
#define TARGET_OS_WATCH 0
#define TARGET_OS_BRIDGE 0
#define TARGET_OS_TV 0
#define TARGET_OS_SIMULATOR 0
#define TARGET_OS_EMBEDDED 1
#define TARGET_IPHONE_SIMULATOR TARGET_OS_SIMULATOR /* deprecated */
#define TARGET_OS_NANO TARGET_OS_WATCH /* deprecated */
(In the 'breadcrumb' above the text editor in Xcode, iOS 10.0 > usr/include > TargetConditionals.h)
...And this is the same file, for macOS:
#define TARGET_OS_MAC 1
#define TARGET_OS_WIN32 0
#define TARGET_OS_UNIX 0
#define TARGET_OS_OSX 1
#define TARGET_OS_IPHONE 0
#define TARGET_OS_IOS 0
#define TARGET_OS_WATCH 0
#define TARGET_OS_BRIDGE 0
#define TARGET_OS_TV 0
#define TARGET_OS_SIMULATOR 0
#define TARGET_OS_EMBEDDED 0
#define TARGET_IPHONE_SIMULATOR TARGET_OS_SIMULATOR /* deprecated */
#define TARGET_OS_NANO TARGET_OS_WATCH /* deprecated */
(In the 'breadcrumb' above the text editor in Xcode, macOS 10.12 > usr/include > TargetConditionals.h)
TARGET_OS_MAC is defined as 1 on both platforms, but TARGET_OS_OSX is 1 only on macOS.
In the file's comments, they are described as follows:
TARGET_OS_MAC: Generated code will run under Mac OS X variant.
TARGET_OS_OSX: Generated code will run under OS X devices.
I guess at some point back then (perhaps around when the iPhone was announced?) somebody decided that iOS (né "iPhone OS") fits the definitions of "Mac OS X variant".
Look in TargetConditionals.h for an entire list, including:
#define TARGET_OS_MAC 1
#define TARGET_OS_IPHONE 1
#define TARGET_IPHONE_SIMULATOR 1
I ran into this same situation, but needed it for Swift.
This answer here on the Apple developer forums was very helpful in dealing with the NSPasteboard protocols in your situation, but for Swift.
https://forums.developer.apple.com/thread/16757
I ended up doing:
#if os(iOS) || os(watchOS)
public protocol TFPasteboardReading { }
public protocol TFPasteboardWriting { }
#elseif os(macOS)
public typealias TFPasteboardReading=NSPasteboardReading
public typealias TFPasteboardWriting=NSPasteboardWriting
#endif
#objc(TFCategory)
public class TFCategory: TFBaseModel, TFPasteboardReading, TFPasteboardWriting {
...
}
That way TFPasteboardReading and TFPasteboardWriting is defined for macOS meaning NSPasteboardReading and NSPasteboardWriting respectively and in iOS it has no meaning, but can still be referenced in iOS. So the code compiles properly for both.
I would recommend using this:
#define TARGET_OS_OSX (!(TARGET_OS_IOS || TARGET_OS_TV || TARGET_OS_WATCH))