| Codec: Realtek ALC3246 | |
| Address: 0 | |
| AFG Function Id: 0x1 (unsol 1) | |
| Vendor Id: 0x10ec0256 | |
| Subsystem Id: 0x10280798 | |
| Revision Id: 0x100002 | |
| No Modem Function Group found | |
| Default PCM: | |
| rates [0x560]: 44100 48000 96000 192000 | |
| bits [0xe]: 16 20 24 |
| ipython==7.5.0 | |
| prompt-toolkit==2.0.9 | |
| numpy | |
| pandas | |
| dask | |
| "dask[distributed]" | |
| "dask[dataframe]" | |
| s3fs | |
| pyarrow | |
| sqlalchemy |
| #!/usr/bin/env python | |
| # vim: set fileencoding=utf8 : | |
| ``` | |
| $ pip install -U boto3 retrying | |
| $ export AWS_DEFAULT_PROFILE=test | |
| $ cat foo.sql | |
| select count(*) | |
| from bar | |
| $ python athena.py foo.sql | |
| $ ls -1 |
Automated analysis is the main advantage to working with a modern statically typed compiled language like C++. Code analysis tools can inform us when we have implemented an operator overload with a non-canonical form, when we should have made a method const, or when the scope of a variable can be reduced.
In short, these tools catch the most commonly agreed best practice mistakes we are making and help educate us to write better code. We will be fully utilizing these tools.
All reasonable warning levels should be enabled. Some warning levels, such as GCC's -Weffc++ warning mode can be too noisy and will not be recommended for normal compilation.
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
| module.exports = { | |
| config: { | |
| // default font size in pixels for all tabs | |
| fontSize: 16, | |
| // font family with optional fallbacks | |
| fontFamily: '"Iosevka Nerd Font Mono", Menlo', | |
| // terminal cursor background color and opacity (hex, rgb, hsl, hsv, hwb or cmyk) | |
| cursorColor: 'rgba(248,28,229,0.75)', |
| #!/bin/bash | |
| #do we wanna limit bandwidth? pass argument BW:limit (ie: BW:10) | |
| if [[ "$1" == "BW:"* ]]; then | |
| NEWBW=`echo $1|cut -d: -f2` | |
| if [ "$NEWBW" != "" ]; then | |
| BW="--limit-rate=${NEWBW}k" | |
| echo using bw limit ${NEWBW} | |
| fi | |
| shift |
Proof of concept:
- Terminal 1:
- SSH to remote host
- Start a Java process with JMX registry port 50004, RMI callback
port 50005, and RMI hostname pinned to localhost:
java -Dcom.sun.management.jmxremote.port=50004 -Dcom.sun.management.jmxremote.rmi.port=50005 -Djava.rmi.server.hostname=localhost -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -cp /some/jar/file main.class
- Terminal 2:
