jaux.net

Every programmer should always keep those numbers in mind!

If your Samsung ML-1640 gets the red light stuck on with no reasons, and you've tried everything but can't make it go away, the problem might be:

the cause was simply that the top opening door had deformed with heat. The result of this was that a switch on the power supply board which disconnects the high voltage the heater when the door open, was never closing so the printer simply didn't work at all.

A little pressure on the top of the printer in the right place would make the red light go out and allow printing.

You definitely want to give it a try. My printer is back on duty by simply pushing the top door down with some pressure, that is it!

Prerequisites

Before start, you need make sure you have a working Perforce client installation, that means p4v and p4 are installed on your computer, and you can create client workspace, sync depot and submit changes back to the depot. Then, you need make sure both git and Python are installed in Cygwin.

Ready? Let's do it!

(All shell commands below, i.e. lines start with $, should be run inside Cygwin terminal)

1. Create a Perforce client workspace

If you have a working Perforce client, you should have a workspace already; otherwise, create one in p4v. Let's say the workspace you have is named as MyWorkspace.

2. Install git-p4

Get git-p4.py from git source, then run:

$ chmod +x git-p4.py
$ cp git-p4.py /usr/local/bin/git-p4

3. Create a p4 wrapper script

Create /usr/local/bin/p4 file with the following content: (credit to git wiki)

#!/bin/bash
export PWD=$(cygpath --windows --absolute .)
exec "/cygdrive/c/Program Files/Perforce/p4" "$@"

Then run:

$ chmod +x /usr/local/bin/p4

4. Create P4CONFIG

Create $HOME/.p4config file with the following content:

P4CLIENT=MyWorkspace
P4PORT=Your_Perforce_Server:1666
P4USER=Your_Perforce_Username
P4PASSWD=Your_Perforce_Password

The P4CLIENT is the name of the workspace you have created in step 1.

5. Prepare environment variables

Add the following line to $HOME/.bash_profile or $HOME/.bashrc:

export P4CONFIG="$HOME/.p4config"

6. Prepare git

$ git config --global alias.p4 /usr/local/bin/git-p4
$ git config --global core.autocrlf true

7. That's it! Restart Cygwin terminal and test git-p4

$ cd Your_Cygwin_Workspace
$ git p4 clone //depot/Your_Project Your_Project
$ cd Your_Project
$ git log
$ Editing...
$ git commit
$ git p4 commit

Links

• Perforce knowledge base for git-p4
• git wiki for git-p4

The new Gmail iPhone app is pretty sick, isn't it? Not so much! I won't replace Sparrow by it for two reasons:

1. Lack of swipe actions on individual email item
2. Using those tiny checkboxes on touchscreen? You must be kidding!

Yay, it's Basic, but it's amazing!

FREE file manager for iOS device!

If your Archive Utility refuses to extract any zip files (i.e. forever rolling beach ball) with no reasons after you upgraded OS X, you might be bitten by the AESendMessage bug!

Run the following command in Terminal.app and try Archive Utility again:

$ sudo pkill -KILL appleeventsd

There are some crazy stuff going on in the Repo script from Android project! Check it out:

1
2
3
4
5
6
7

magic='--calling-python-from-/bin/sh--'
"""exec" python -E "$0" "$@" """#$magic"
if __name__ == '__main__':
  import sys
  if sys.argv[-1] == '#%s' % magic:
    del sys.argv[-1]
del magic

It's so easy to figure out what it does (executes Python from there), but it's SO hard to figure out how it does it and why it does it in this way (at least for me, who was the first time seeing a script can be run by both Bash and Python).

Luckily, I'm not alone, this question had already been asked and answered.

The answer to How is:

"""foo""" (text inside of triple quotes) is often treated as a comment in Python. So the entire line up until the # is treated as a comment by Python and is ignored when Python reads the script file. Since # until LF is also a comment in Python, the remainder of the line is also ignored by Python, so the entire line is ignored by Python.

"" in Bourne shell is an empty string. So the first "" in """ at the start of the line expands to an empty string, which is then concatenated with the next double quoted string, "exec". Since "" plus "exec" is still "exec", Bourne reads this as though it had just said exec right there.

At the end of the line again the first "" in """ is read as an empty string, which is then concatenated with "#$magic". The shell expands $magic to the value defined on the prior line, effectively adding this to the argument vector given to Python when it execs Python. So in the end this line looks to the Bourne shell as though it were:

exec python -E "$0" "$@" "#--calling-python-from-/bin/sh--"

And the answer to Why is:

We need to pass the -E flag, but env on some platforms wasn't taking it. So I cooked up this work around. It mostly had to do with our internal desktops at Google; they have a lot of PYTHON environment flags that we didn't want to inherit into the repo process (because they are there for normal Google engineers, not Android Google engineers), and at least at the time env on either Mac OS or Linux (I can't remember which) was rejecting a shbang line of "#!/usr/bin/env python -E".

What can I say? This is a holy cool magic, indeed!

Nice found.

I always like this kind of "then and now" comparison.