Installing under sink water filter

 The whole installation requires the following tools:

1. A wrench to loosen the original compression fitting connected to the cold water shutoff valve

2. Water filter cartridge(WaterDrop) and all the cables that comes with it

3. Optional: T adapter to split one 3/8 to two 3/8 outputs. One goes to the regular kitchen faucet, and another one goes to the filtered water faucet. You can also connect the filtered water directly to the kitchen faucet if you don't want a faucet dedicated for filtered water.

4. Optional: 3/8 to 1/4 Compression fitting adapter if you have a faucet with 1/4 fitting.

Water filter should only connect to cold water. The name/model of the water filter used in the picture is called WaterDrop which you can buy on Amazon.

Correction: The above labeling is incorrect. 1/2 fitting supposed to be 3/8 fitting.  The T compression adapter is all 3/8 in size.

You need an compression adapter to connect the 3/8 cable to the 1/4 cable. Correction: The picture lable should say 3/8 to 1/4 male adapter.

You screw the nut into the compression fitting with the compression sleeve in the between. For example, the plastic water cable would go through the nut, the compression sleeve and to the compression fitting.

Notice if you are looking for a water filter to reduce the TDS (Total Dissolved Solids) in your water, you would need to use the RO ( Reverse Osmosis) water filter system. The water filter used here does not reduce the TDS number.

Debugging on Mojave

June 11, 2018

By Jeff Johnson (Developer of StopTheMadness and Underpass)

In March, Xcode 9.3 shipped with a strange new feature. The Xcode Release Notes miscategorized the feature under the "Server" section:

The debugger on macOS now requires the entitlement com.apple.security.get-task-allow to attach to apps built for macOS or for iOS, tvOS or watchOS apps built for Simulator. Xcode automatically injects this entitlement to your builds. The entitlement is stripped from apps distributed using the Organizer window.

At the time, this note caused some confusion and anxiety. In retrospect, it appears that the words were a bit premature — a leak, if you will — and "macOS now requires" referred to macOS 10.14 Mojave, still secret at the time, rather than macOS 10.13 High Sierra. There are indeed some changes to debugging on Mojave, and this blog post will describe what I've discovered so far.
Debugging apps in your Xcode build folder has not changed on Mojave. Examine the code signature of your built app:

$ codesign -d --entitlements - MyApp.app

You can see the com.apple.security.get-task-allow entitlement, which allows you to debug the app either in Xcode or with /usr/bin/lldb in Terminal.
The situation has changed for apps that lack the com.apple.security.get-task-allow entitlement. Apps won't have the entitlement if you didn't build them yourself, or if you exported them for distribution from Xcode. To test, I tried debugging my own app Underpass installed from the Mac App Store. We can confirm with codesign -d --entitlements - /Applications/Underpass.app that the com.apple.security.get-task-allow entitlement does not exist in the App Store version. Here's a sample of a debugging session in Terminal:

$ lldb /Applications/Underpass.app/Contents/MacOS/Underpass
(lldb) target create "/Applications/Underpass.app/Contents/MacOS/Underpass"
Current executable set to '/Applications/Underpass.app/Contents/MacOS/Underpass' (x86_64).
(lldb) breakpoint set --selector count
Breakpoint 1: 141 locations.
(lldb) run

On High Sierra, "it just works", as they say. The process launches and then stops at the breakpoint, most likely in CoreFoundation`-[__NSArrayM count]. On Mojave, however, the first time after login that you try to debug an app without the com.apple.security.get-task-allow entitlement, the system displays a modal dialog requesting an administrator password:

Developer Tool Access needs to take control of another process for debugging to continue.

This happens whether or not you have System Integrity Protection enabled! SIP status doesn't matter here. Unless you authenticate, you can't debug the app. (By the way, pressing the Cancel button just causes the system to ask you again, instead of canceling. I would consider this to be a bug. Eventually it gives up after 10 cancels.) If you successfully authenticate once, then it appears that you can continue to debug other apps without further system requests, as long as you don't logout. If you do logout and login again, the system will start asking again for permission the next time you try to debug. Which is very annoying.

Update

After writing this blog post, I discovered why you have to authenticate again after logout. Prior to Mojave, Xcode would request on first launch to "Enable Developer Mode on this Mac". On Mojave, Xcode no longer requests Developer Mode. However, Developer Mode can still be enabled manually with /usr/sbin/DevToolsSecurity -enable in Terminal. After you authenticate with DevToolsSecurity once, Developer Mode is permanently enabled on Mojave, and you won't have to authenticate again to debug.
Thus, the situation is not quite as bad as feared. It would be nice if Apple communicated and documented this information clearly instead of leaving developers in the dark and fumbling around for answers, like I'm doing here.

Hardened Runtime

Xcode 10 has shipped with another strange new feature, called the "hardened runtime". According to the Xcode Help:

The hardened runtime capability is available in Xcode 10.0 and later on macOS v10.3.6 and later. You can build an app with hardened runtime enabled on macOS v10.3.6 and later, but must test this capability on macOS v10.14 and later.

I believe that "v10.3.6" is a typo and is supposed to be "v10.13.6". On macOS 10.14, the "Hardened Runtime" section appears under your target's "Capabilities" in Xcode 10, but the section does not appear on macOS 10.13.5. When macOS 10.13.6 ships, I expect that "Hardened Runtime" will start appearing in Xcode 10. The reason is that the codesign command-line utility is part of the operating system rather than part of Xcode. On Mojave, the man page for codesign lists a new "runtime" option under "OPTION FLAGS":

On macOS versions >= 10.14.0, opts signed processes into a hardened runtime environment which includes runtime code signing enforcement, library validation, hard, kill, and debugging restrictions. These restrictions can be selectively relaxed via entitlements. Note: macOS versions older than 10.14.0 ignore the presence of this flag in the code signature.

This option flag does not exist in codesign on macOS 10.13.5, so you can't sign an app with the hardened runtime on that version.
What happens on Mojave if you try to debug an app compiled with the hardened runtime? If System Integrity Protection is disabled, then nothing changes; it's the same as I described in the first section of this blog post. So the hardened runtime is enforced by SIP. With SIP enabled, you can still debug your app if it's compiled with the com.apple.security.get-task-allow entitlement. If an app doesn't have that entitlement, however, then you can't debug it at all.

(lldb) run
error: process exited with status -1 (unable to attach)

The hardened runtime is also supposed to make the app ignore DYLD_ environment variables such as DYLD_PRINT_LIBRARIES. In my testing, though, they weren't ignored. Perhaps this will be "fixed" in a later Mojave beta.
Compiling an app with the hardened runtime is currently optional. However, it is required for "notarized" apps.

A notarized app is a macOS app that was uploaded to Apple for validation before it was distributed. When you export a notarized app from Xcode, it code signs the app with a Developer ID certificate and staples a ticket from Apple to the app. The ticket confirms that you previously uploaded the app to Apple.
On macOS 10.14 and later, the user can launch notarized apps when Gatekeeper is enabled. When the user first launches a notarized app, Gatekeeper looks for the app’s ticket online. If the user is offline, Gatekeeper looks for the ticket that was stapled to the app.

Apple has said that notarization is currently optional but will be required for all Developer ID signed apps at some unspecified point in the future. Thus, ultimately the hardened runtime will also be required for all Developer ID signed apps. It seems very likely that the hardened runtime will also become a requirement for apps in the Mac App Store.
In short, the future of debugging on Mojave is … dark.

If you want to be able to debug or attached to hardened app where the entitlement com.apple.security.get-task-allow is missing, you need to disable SIP.

https://www.macworld.co.uk/how-to/mac/how-turn-off-mac-os-x-system-integrity-protection-rootless-3638975/

Travel Tips

Southwest

To see what cities in the US has Southwest Airlines check its route map

https://www.southwest.com/flight/routemap_dyn.html . This is handy when you are on a road trip across the country and you want to know where you can take Southwest to fly home. Without looking at this map you cannot tell that Southwest has no presence in the state of Wyoming or South Dakota.

Only in these cities can you fly out using Southwest. Once you know where you want to flight out and your destination, you can change to the list view to select departure city and arrival city to book your flight.

Japan guide - bus stop information and bullet train pass

Bus Stop

This is how a bus stop would look like in Japan. Each bus stop has a number and a name. In this case, it is bus stop number 3 called Shijo Omiya.

All the bus numbers making the stop will be displayed in the bus stop information. Below is an example of the bus stop information displayed for bus stop number 3. It is called the Shijo Omiya bus stop. Bus number 18, 32,58,71,6,206 and 207 will stop at this station. The destination of each bus number is also listed. For example, bus 18 will head for Toji Temple, and  bus 6 will head to the Kyoto Station.

The schedule of each bus will also be displayed at the bus stop.
Below is an example of the time table for bus number 206. The hours are listed vertically and the minutes in the hour are listed horizontally. For bus 206, there are three different time schedules listed in three different columns: Weekdays, Saturdays, and Sundays/Holidays.
One Saturday, the first stop will be at 5:56 AM. At 6AM, there will be three stops at 6:27 AM, 6:38 AM and  6:50 AM.

Sometimes the hours displayed are listed in a different format. Below is an example of a JR bus time table. The information tells you when the bus will arrive at this station. Notice the hours are listed horizontally (not vertically like the one above) and the minutes within the hour are listed vertically. For example, the red row lists the hours from 6AM to 10PM (22). There is no stop at 6AM. The first stop in the morning will be at 7:17AM. The second stop will be at 8:08AM. At 9AM, there will be three stops at 9:02AM, 9:17AM and 9:47AM.

Japan Rail Pass

To travel across cities, you will probably need to buy a bullet train pass or the Shinkansen bullet train pass. You will have to specify how many days you want when you buy the pass. It is recommended that you buy the pass before you head to Japan. With this pass, you can reserve for the train ticket to the destination you want. Below is an example of how the pass would look like. It is also called the JR pass. This pass will also allow you to use the JR bus lines wherever they are available.

Once you reserve a seat using your Shinkasen/JR pass, you will get a train ticket for your reservation. To make the reservation, you will have to go to the JR office which can be found in any major train stations. Below is an example of a reserved ticket. This ticket says the train will go from Tokyo to Kyoto on September 22nd at 13.03 or 1PM and arrive at Kyoto at 15.45 or 3:45 PM. The train is Hikart 473. Once you are on the train platform, you should head to cart number 13 and your seat number is 15-E.

Japan Travel App

If you plan to use the bus and train a lot while in Japan, you should download this Japan travel app in IOS. With this app you can plug in your current and destination locations, and it will list all the routes you can take to get to your destination. Each route will give you information about what bus number to take at which bus station, what bus station to get off/hop on next, time the bus will depart or arrive and etc. Another big bonus is if you have a JR pass, it will also tell you what route to take to use only the JR pass to get to your destination without paying anything extra.

LLDB Debugger commands

https://gist.github.com/wanyakun/314690093ea195d749fca6869ebf200e#file-lldb-debugger-commands-txt Debugger commands: apropos -- List debugger commands related to a word or subject. breakpoint -- Commands for operating on breakpoints (see 'help b' for shorthand.) bugreport -- Commands for creating domain-specific bug reports. command -- Commands for managing custom LLDB commands. disassemble -- Disassemble specified instructions in the current target. Defaults to the current function for the current thread and stack frame. expression -- Evaluate an expression on the current thread. Displays any returned value with LLDB's default formatting. frame -- Commands for selecting and examing the current thread's stack frames. gdb-remote -- Connect to a process via remote GDB server. If no host is specifed, localhost is assumed. gui -- Switch into the curses based GUI mode. help -- Show a list of all debugger commands, or give details about a specific command. kdp-remote -- Connect to a process via remote KDP server. If no UDP port is specified, port 41139 is assumed. language -- Commands specific to a source language. log -- Commands controlling LLDB internal logging. memory -- Commands for operating on memory in the current target process. platform -- Commands to manage and create platforms. plugin -- Commands for managing LLDB plugins. process -- Commands for interacting with processes on the current platform. quit -- Quit the LLDB debugger. register -- Commands to access registers for the current thread and stack frame. script -- Invoke the script interpreter with provided code and display any results. Start the interactive interpreter if no code is supplied. settings -- Commands for managing LLDB settings. source -- Commands for examining source code described by debug information for the current target process. target -- Commands for operating on debugger targets. thread -- Commands for operating on one or more threads in the current process. type -- Commands for operating on the type system. version -- Show the LLDB debugger version. watchpoint -- Commands for operating on watchpoints. Current command abbreviations (type 'help command alias' for more info): add-dsym -- ('target symbols add') Add a debug symbol file to one of the target's current modules by specifying a path to a debug symbols file, or using the options to specify a module to download symbols for. attach -- ('_regexp-attach') Attach to process by ID or name. b -- ('_regexp-break') Set a breakpoint using one of several shorthand formats. bt -- ('_regexp-bt') Show the current thread's call stack. Any numeric argument displays at most that many frames. The argument 'all' displays all threads. c -- ('process continue') Continue execution of all threads in the current process. call -- ('expression --') Evaluate an expression on the current thread. Displays any returned value with LLDB's default formatting. continue -- ('process continue') Continue execution of all threads in the current process. detach -- ('process detach') Detach from the current target process. di -- ('disassemble') Disassemble specified instructions in the current target. Defaults to the current function for the current thread and stack frame. dis -- ('disassemble') Disassemble specified instructions in the current target. Defaults to the current function for the current thread and stack frame. display -- ('_regexp-display') Evaluate an expression at every stop (see 'help target stop-hook'.) down -- ('_regexp-down') Select a newer stack frame. Defaults to moving one frame, a numeric argument can specify an arbitrary number. env -- ('_regexp-env') Shorthand for viewing and setting environment variables. exit -- ('quit') Quit the LLDB debugger. f -- ('frame select') Select the current stack frame by index from within the current thread (see 'thread backtrace'.) file -- ('target create') Create a target using the argument as the main executable. finish -- ('thread step-out') Finish executing the current stack frame and stop after returning. Defaults to current thread unless specified. image -- ('target modules') Commands for accessing information for one or more target modules. j -- ('_regexp-jump') Set the program counter to a new address. jump -- ('_regexp-jump') Set the program counter to a new address. kill -- ('process kill') Terminate the current target process. l -- ('_regexp-list') List relevant source code using one of several shorthand formats. list -- ('_regexp-list') List relevant source code using one of several shorthand formats. n -- ('thread step-over') Source level single step, stepping over calls. Defaults to current thread unless specified. next -- ('thread step-over') Source level single step, stepping over calls. Defaults to current thread unless specified. nexti -- ('thread step-inst-over') Instruction level single step, stepping over calls. Defaults to current thread unless specified. ni -- ('thread step-inst-over') Instruction level single step, stepping over calls. Defaults to current thread unless specified. p -- ('expression --') Evaluate an expression on the current thread. Displays any returned value with LLDB's default formatting. parray -- ('expression -Z %1 --') Evaluate an expression on the current thread. Displays any returned value with LLDB's default formatting. po -- Evaluate an expression on the current thread. Displays any returned value with formatting controlled by the type's author. poarray -- ('expression -O -Z %1 --') Evaluate an expression on the current thread. Displays any returned value with LLDB's default formatting. print -- ('expression --') Evaluate an expression on the current thread. Displays any returned value with LLDB's default formatting. q -- ('quit') Quit the LLDB debugger. r -- ('process launch -X true --') Launch the executable in the debugger. rbreak -- ('breakpoint set -r %1') Sets a breakpoint or set of breakpoints in the executable. repl -- ('expression -r -- ') Evaluate an expression on the current thread. Displays any returned value with LLDB's default formatting. run -- ('process launch -X true --') Launch the executable in the debugger. s -- ('thread step-in') Source level single step, stepping into calls. Defaults to current thread unless specified. si -- ('thread step-inst') Instruction level single step, stepping into calls. Defaults to current thread unless specified. sif -- Step through the current block, stopping if you step directly into a function whose name matches the TargetFunctionName. step -- ('thread step-in') Source level single step, stepping into calls. Defaults to current thread unless specified. stepi -- ('thread step-inst') Instruction level single step, stepping into calls. Defaults to current thread unless specified. t -- ('thread select') Change the currently selected thread. tbreak -- ('_regexp-tbreak') Set a one-shot breakpoint using one of several shorthand formats. undisplay -- ('_regexp-undisplay') Stop displaying expression at every stop (specified by stop-hook index.) up -- ('_regexp-up') Select an older stack frame. Defaults to moving one frame, a numeric argument can specify an arbitrary number. x -- ('memory read') Read from the memory of the current target process. For more information on any command, type 'help <command-name>' Examples: >lldb program.app //load the program at the command line Inside lldb >file program.app //load the program >b list //list all breakpoints >b main >b main.cpp:12 >b classname::method name >br delete 1. //delete the first breakpoint >br delete //delete all breakpoints >run >n >print [var name] >fr v //print all variables >apropos path //list all commands that have the word path in it or in its description Debugging with a debug image or dmg file open the dmg file and copy the app file to a folder A get the sha number related to the version of the app and create a branch from that sha number >git checkout sha-number branchApp >run the app >run Xcode and attach to the app >select debug->pause to pause the execution so you can access the lldb console >now you can set a breakpoint in the console. >br classname::method Remote Debugging on MAC    Start the debug server on the target Mac machine:  /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver dev_machine_ip:portnumber     /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver 10.0.46.83:16000     On the dev machine, use lldb to connect to the debugserver:  >lldb  (lldb) process connect connect://10.0.46.241:16000  (lldb) process attach --name 'Adobe Premiere Pro (Beta)' --waitfor  //this tells the debugserver to wait and attach to process name adobe premiere.    Run adobe premiere on the target machine GDB to LLDB command map

Windows PE and PDB file format

PE = Program executable
PDB = program database. This file contains information such as symbols information to help troubleshoot the PE file.

windbg (windows debugger) matches the PE file with the PDB file by using a signature that is unique. This signature information is generated by the linker.
The signature is made up of the timestamp  + the pdb age in the older version of pdb format.
In the newer version of the pdb (version 7), the signature is made of the guid  + the pdb age.
guid is much more unique than the timestamp. The pdb age is a integer that gets incremented every time the pdb gets changed.

Useful tools to help display information about the PE file format:
PE Studio   https://www.winitor.com/


PE View     http://wjradburn.com/software/

Here is a tutorial on how to check the debug type of a PE file using the PE view program.
In figure 1, a DLL file is opened using the PE view program. We want to know what is the debug type of the DLL file. For more information about debug type, please check the MSFT link below.
To see where is the debug type information is stored in the file, we first need to check the image optional header (2). Since the DLL file is compiled with debug information, we should see debug directory information in the image optional header (3). The file offset containing the debug directory information is at offset 000001D8 and it has a RVA value of 03756260. The debug directory size is 54.

 Figure 1.

Expand the .rdata section in Figure 2, we see that the image_debug_directory section is starting at RVA 03756260. This is the same RVA value as shown in Figure 1.

Figure 2.

If we change the view from RVA to view offset (1) in Figure3, we will see that each section will start at 0x0 (2) instead of at 03756260 as in Figure 1. In the offset view, the debug type value can be read at offset 0xC, and its value is set to 2, IMAGE_DEBUG_TYPE_CODEVIEW (3). The view offset can be handy if you don't want to remember or deal with the complicate offset values displayed in the file offset or RVA view. You can just move file cursor to the beginning of a section using the file offset value and read x number of bytes as the size of the debug directory indicated in Figure 1. Once you read the whole section into an array, you can start reading each field in the section using the offset value shown in the  view offset. For example, the value of the Pointer to Raw Data field can be read using offset 0x18.

Figure 3.

As illustrated in Figure 3, we can continue to move to the file cursor using the file offset value from the "Pointer to Raw Data" field. This will allow us to read the IMAGE_DEBUG_TYPE_CODEVIEW section which contains more information about the pdb file format. In figure 4, the file offset for IMAGE_DEBUG_TYPE_CODEVIEW is the same as the value for "Pointer to Raw Data" field in figure 3.

Figure 4.

Please check the MSFT PE format documentation to see information about the fields included in a section (1). In this case, the PE signature value for this DLL file is RSDS (2) indicating that the PDB 7.0 version file format.

Excellent links to more information:
http://www.debuginfo.com/articles/debuginfomatch.html  -- excellent article
http://www.debuginfo.com/articles/gendebuginfo.html
http://www.godevtool.com/Other/pdb.htm  -- understanding the format of PDB file
http://bytepointer.com/resources/pecoff_v4.1.htm
https://docs.microsoft.com/en-us/windows/desktop/debug/pe-format#optional-header-image-only  -- MSFT documentation of PE file format.

4G LTE USB Dongle

If you want to give your laptop/computer access to the internet via 4G LTE signal, you should consider this device:

Modem Huawei E3372-510 Unlocked 4G LTE USB Dongle

With this device you can access the internet anywhere where the cell phone signals are available. Unlike WIFI signals, 4G LTE signal can provide internet in many more places. This device is very handy if you cannot do a WiFi hotspot from your phone because your data plan does not allow you to do that.

There are a few things that you need to do to get this device to work properly with the AT&T network:

First, you need to know how to install the AT&T sim card to the device: 

https://vimeo.com/251230948

If you have a nano sim card, you may need to buy a nano adapter to help make the nano sim card sits securely inside the sim card slot. Some nano adapters are not so well designed that the nano sim card will fall out of the adapter every time you try to push the nano adapter, with the gold plated side facing down, into the sim card slot. The trick to resolving this issue is to turn everything upside down including the device so nano sim card won't fall out of the adapter when you push the nano adapter into sim card slot. 

Second, once you have access to the Huawei home page, you need to add a profile to be able to access the AT&T network properly (tip from an Amazon review):

- Connect your stick to your computer.
- Wait for your computer to get a local IP address 192.168.0.???
- Open a web browser and go to 192.168.0.1 the built in Huawei web portal for the device
- You should see signal bars but "Disconnected"
- Go to Settings -> Dial-Up -> Profile Management
- Create a new profile, name it whatever, use whatever username and password you want
- HERE IS THE KEY - APN, for AT&T just type in "broadband"
- Click Save/Apply

How does it feel to be able to work remotely from a white sand beach? :)