Xcode - Revision history

Skalogryz: /* simctl */

2016-01-01T19:15:33Z

‎simctl

2016-01-01T19:13:57Z

‎simutils

2016-01-01T19:12:52Z

‎xcodebuild

2015-12-26T07:44:48Z

‎Main Break

2015-12-26T07:44:07Z

‎Pseudo Terminals

2015-12-26T07:43:12Z

‎Main Break

2015-12-26T07:42:54Z

‎Pseudo Terminals

2015-12-26T07:41:48Z

‎Capturing Console Output

2015-12-25T06:00:54Z

‎Capturing Console Output

2015-12-25T06:00:27Z

‎Capturing Console Output

@@ Line 31: / Line 31: @@
 Installing a bundle to the device.  The bundle could be either generated manually or prepared via Xcode (xcodebuild)
-  xcrun simctl install booted %bundle path%
+  xcrun simctl install booted ~/project1/bundle.app
 Running an application on a booted device.
-  xcrun simctrl launch booted %bundle.id%
+  xcrun simctrl launch booted bundle.mycompany.id
 "booted" can be replaced with an actual device id.
 Running an application with waiting for a debugger (lldb).
-  xcrun simctl launch -w booted %bundle.id%
+  xcrun simctl launch -w booted bundle.mycompany.id
 The booted application will launch and pid for the application will return. For example:
   bundle.id 1200

@@ Line 22: / Line 22: @@
 *%template% - if template is specified, then instruments doesn't return. If template is not specified (causes a warning on running) the instruments exists, leaving the device running.
-===simutils===
+===simctl===
 An utility fo additional control over the simulator. Must be ran via "xcrun"
@@ Line 29: / Line 29: @@
 Running without "devices" would list all devices. "-j" requests JSON format
 Running an application on a booted device.
@@ Line 36: / Line 39: @@
 Running an application with waiting for a debugger (lldb).
-  xcrun simctrl launch -w booted %bundle.id%
+  xcrun simctl launch -w booted %bundle.id%
 The booted application will launch and pid for the application will return. For example:
   bundle.id 1200
 ===lldb===
 lldb has replaced gdb as a Apple main debugger utility. Unlike one might expect, it's NOT specific for LLVM or any llvm written program. It can as a "normal" debugger and debug non-LLVM based programs.

@@ Line 9: / Line 9: @@
   xcodebuild -showsdks
 Build a project by it's (project directory) name and a specified sdk
   xcodebuild -sdk iphonesimulator9.1 -project testProjGen.xcodeproj
 ===instruments===

@@ Line 66: / Line 66: @@
 The handlers could be overwritten.
-<nowiki>Insert non-formatted text here</nowiki>===Pseudo Terminals===
+===Pseudo Terminals===
 One of the problems of using files or even named pipes (fifo) for the reading std-out and std-err, is the fact Pascal RTL is using buffered output for files by default.  It might looked like a delayed (or even missing) output.
@@ Line 73: / Line 73: @@
 Pascal RTL does much less buffering for console output (i.e. each WriteLn call is flushed).
-So instead of using files, it's better to use Pseudo Terminals (ptys), which are created via [url=https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/openpty.3.html]openpty[/url] function.
+So instead of using files, it's better to use Pseudo Terminals (ptys), which are created via [https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/openpty.3.html openpty] function.
   uses
    .. Unix, termios ...

@@ Line 66: / Line 66: @@
 The handlers could be overwritten.
-===Pseudo Terminals===
+<nowiki>Insert non-formatted text here</nowiki>===Pseudo Terminals===
 One of the problems of using files or even named pipes (fifo) for the reading std-out and std-err, is the fact Pascal RTL is using buffered output for files by default.  It might looked like a delayed (or even missing) output.
@@ Line 76: / Line 76: @@
   uses
    .. Unix, termios ...
-−
   type
     Ptermios = ^termios; // declared at termios
     Pwinsize = ^winsize;
-−
   function openpty(amaster:pcint; aslave:pcint;
     name:Pchar; termp:Ptermios; winp:Pwinsize):longint;cdecl;

@@ Line 58: / Line 58: @@
 For any non system unix function LLDB HAS to have the debug info available. DWARF format is preferred.
-===Main Break===
+====Main Break====
 Keep in mind, that the standard output/error must be overwritten as soon as possible. The best place for that is at the beginning of main(). (Note that main() is not the same as pascal main program body at begin..end. Pascal RTL and units does initialization  at the main() prior to passing the code to the main program body).
@@ Line 64: / Line 64: @@
   b main
 Once the breakpoint is reached (which should eventually, even if LLDB complains about missing symbolic references to main)
 The handlers could be overwritten.
 ===Pseudo Terminals===

@@ Line 57: / Line 57: @@
   p dup2 ( open("/Users/dmitry/err.txt",2), 2)
 For any non system unix function LLDB HAS to have the debug info available. DWARF format is preferred.
 ==Run Script==

@@ Line 51: / Line 51: @@
 LLDB allows to run commands within the debugged process by a number of commands (call, p, po). Here's an example of reassigning stderr to a file:
   p (int) dup2 ( (int) open("/Users/dmitry/err.txt",2), 2)
-explanations:
+Notes:
- open("/Users/dmitry/err.txt",2) - opens the specified file with O_RDWR read/write flag
+:open("/Users/dmitry/err.txt",2) - opens the specified file with O_RDWR read/write flag
- dup2( xx, 2) - copied the file descriptor "xx" (that has been open()-ed) to description "2", which is stderr. "1" is stdout)
+:dup2( xx, 2) - copied the file descriptor "xx" (that has been open()-ed) to description "2", which is stderr. "1" is stdout)
+:each function has an explicit type-case before its usage (int). This is required for debugger without enough debug information provided. If debug info were present the call could look like this:
   p dup2 ( open("/Users/dmitry/err.txt",2), 2)
 For any non system unix function LLDB HAS to have the debug info available. DWARF format is preferred.