Recently, I discovered a nice website, SoundCloud which promotes (aurally, visually and socially) music that you compose.
Or, you can use it to play a stream of compositions, by typing tags and search words.
I searched for tag, 'classical', and keyword, 'experimental', and the resulting hits sound pretty nice!
It's been out since 2007: recently 5 million registered users.
Copyright (c) 2011 Mark D. Blackwell.
Sunday, August 28, 2011
Wednesday, August 24, 2011
Cygwin, Git Bash and native Windows apps, howto
I use Debian and Windows XP — the latter sometimes on a netbook, but principally on a fast desktop computer (it has a nice monitor). On Debian, I develop software in the normal way. But, when I'm on Windows, I have to resort to a variety of techniques.
On a fast desktop computer, I use many native Windows apps (e.g. 7-Zip instead of Tar with compression; in the Windows way). I use Cygwin apps where a good native Windows version is lacking.
For example, previously I ran Cygwin's LilyPond till I noticed the niceness of the Windows version.
But mostly on Cygwin I enjoy the Bash command line interface and its filesystem.
My desktop's Git is through Cygwin, but the netbook has msysGit (with its own version of Bash). (Msysgit is also known as Git Bash.)
Within msysGit, so far, Bash's symbolic links aren't good — if you make one, it actually copies the whole folder!
I could try alternatives (suggested on MinGW's MSYS page) such as Interix (also known as Microsoft's SFU or SUA).
Paths
In order to maintain only one copy on the desktop of things like SSH keys (used by Git) I followed instructions to move my Cygwin user home directory to the same place as my Windows user home directory — which worked just fine! (Additionally, I set LANG to en_US.UTF-8, as suggested.)
Now, this command works just fine for me:
ruby app/hello.rb
I seem to recall that, for a while, it gave me an error, 'no such file'. Perhaps when I cleaned and upgraded my Cygwin installation (including my .bash* files) and then did a couple of reboots, the problem went away. (Don't you hate that?)
Cygwin can run both Cygwin apps, and native Windows apps. For speed and maintainability reasons, it's good to minimize the programs installed into Cygwin, doing so only if no native Windows version will succeed there (or can conveniently be run outside it). For example, my RubyGems installation is a native Windows one.
In Cygwin, the command, 'rake' (e.g.) might give you:
No such file or directory -- /cygdrive/c/progra/ruby/1.8.7-p352/bin/rake (LoadError)
even though it is found by, 'which rake':
/cygdrive/c/progra/ruby/1.8.7-p352/bin/rake
The solution (in Cygwin) is to type, 'rake.bat' (gem.bat, irb.bat, pik.bat, etc.).
If desired, you can alias rake, gem, irb and pik as with Robert Wahler's Stack Overflow answer, but just on the command line — it doesn't normally work in Bash scripts. (E.g., 'alias rake=rake.bat' — to reverse it: 'unalias rake'.)
If you are having problems with native Windows programs still not finding files in Cygwin, you might want to look at one aspect of Cygwin filesystems (some sources say) which requires special handling.
The documentation says passing filesystem paths (in Cygwin Bash) to native Windows apps (such as Ruby) is done (although sometimes I need to) in one of two ways:
One is to use native 'Win32' paths — two examples follow, for which I made a Ruby test program ('app/hello.rb' containing only, 'p __FILE__'). They require at least one, escaped backslash:
In (Cygwin's) current directory (using native Win32 paths):
ruby '.\hello.rb'
ruby .\\hello.rb
Or in 'app', relative to the current directory:
ruby 'app\hello.rb'
ruby app\\hello.rb
The other is to use cygpath:
In the current directory (add, '-a' for the full path):
ruby "`cygpath -m hello.rb`"
Or in the relative directory, 'app' (recently, with one long path, I had to do it this way):
ruby "`cygpath -m app/hello.rb`"
Permissions
Developing with both msysGit and Cygwin normally generates Unix permissions problems. Their Gits flip-flop the permission bits between '100777' (Cygwin) and '100644' (msysGit) on most files! Those with certain typically-executable extensions like .exe and .bat alternate between '100777' (Cygwin) and '100755' (msysGit).
To avoid most of this problem, you can mount your Cygwin user home directory in a way close to the msysGit method:
/cygdrive/c/Documents\040and\040Settings/[user name] /home/[user name] ntfs binary,noacl,bind 0 0
'noacl' tells Cygwin not to use the Access Control Lists found in Microsoft's NT tree. (BTW, as of Cygwin 1.7.9-1, 'posix=1' and 'nouser' are ignored here.)
The exception is that Cygwin will look for '#!' at the beginning of files to set the executable bit; msysGit, as mentioned above, will look at extensions like .exe and .bat.
In a development project, it might be useful to set write- and execute-permissions (at least the 'user' bits). If you want to manipulate permission bits further in your repository, you can tell msysGit (or even Cygwin Git) to ignore permission bit differences. Then you can set (see Jakub Narębski's answer) the (user?) execute bits:
git update-index --chmod=+x [file paths]
and reset them:
git update-index --chmod=-x [file paths]
before you do, 'git commit'.
(Tested with Ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-mingw32], Cygwin 1.7.9-1.)
BTW, to see what Cygwin version you are running:
cygcheck -c cygwin
References
file modes - Cygwin
NT Security - Cygwin
file modes - msysGit
discussion
Copyright (c) 2011, 2015 Mark D. Blackwell.
On a fast desktop computer, I use many native Windows apps (e.g. 7-Zip instead of Tar with compression; in the Windows way). I use Cygwin apps where a good native Windows version is lacking.
For example, previously I ran Cygwin's LilyPond till I noticed the niceness of the Windows version.
But mostly on Cygwin I enjoy the Bash command line interface and its filesystem.
My desktop's Git is through Cygwin, but the netbook has msysGit (with its own version of Bash). (Msysgit is also known as Git Bash.)
Within msysGit, so far, Bash's symbolic links aren't good — if you make one, it actually copies the whole folder!
I could try alternatives (suggested on MinGW's MSYS page) such as Interix (also known as Microsoft's SFU or SUA).
Paths
In order to maintain only one copy on the desktop of things like SSH keys (used by Git) I followed instructions to move my Cygwin user home directory to the same place as my Windows user home directory — which worked just fine! (Additionally, I set LANG to en_US.UTF-8, as suggested.)
Now, this command works just fine for me:
ruby app/hello.rb
I seem to recall that, for a while, it gave me an error, 'no such file'. Perhaps when I cleaned and upgraded my Cygwin installation (including my .bash* files) and then did a couple of reboots, the problem went away. (Don't you hate that?)
Cygwin can run both Cygwin apps, and native Windows apps. For speed and maintainability reasons, it's good to minimize the programs installed into Cygwin, doing so only if no native Windows version will succeed there (or can conveniently be run outside it). For example, my RubyGems installation is a native Windows one.
In Cygwin, the command, 'rake' (e.g.) might give you:
No such file or directory -- /cygdrive/c/progra/ruby/1.8.7-p352/bin/rake (LoadError)
even though it is found by, 'which rake':
/cygdrive/c/progra/ruby/1.8.7-p352/bin/rake
The solution (in Cygwin) is to type, 'rake.bat' (gem.bat, irb.bat, pik.bat, etc.).
If desired, you can alias rake, gem, irb and pik as with Robert Wahler's Stack Overflow answer, but just on the command line — it doesn't normally work in Bash scripts. (E.g., 'alias rake=rake.bat' — to reverse it: 'unalias rake'.)
If you are having problems with native Windows programs still not finding files in Cygwin, you might want to look at one aspect of Cygwin filesystems (some sources say) which requires special handling.
The documentation says passing filesystem paths (in Cygwin Bash) to native Windows apps (such as Ruby) is done (although sometimes I need to) in one of two ways:
One is to use native 'Win32' paths — two examples follow, for which I made a Ruby test program ('app/hello.rb' containing only, 'p __FILE__'). They require at least one, escaped backslash:
In (Cygwin's) current directory (using native Win32 paths):
ruby '.\hello.rb'
ruby .\\hello.rb
Or in 'app', relative to the current directory:
ruby 'app\hello.rb'
ruby app\\hello.rb
The other is to use cygpath:
In the current directory (add, '-a' for the full path):
ruby "`cygpath -m hello.rb`"
Or in the relative directory, 'app' (recently, with one long path, I had to do it this way):
ruby "`cygpath -m app/hello.rb`"
Permissions
Developing with both msysGit and Cygwin normally generates Unix permissions problems. Their Gits flip-flop the permission bits between '100777' (Cygwin) and '100644' (msysGit) on most files! Those with certain typically-executable extensions like .exe and .bat alternate between '100777' (Cygwin) and '100755' (msysGit).
To avoid most of this problem, you can mount your Cygwin user home directory in a way close to the msysGit method:
/cygdrive/c/Documents\040and\040Settings/[user name] /home/[user name] ntfs binary,noacl,bind 0 0
'noacl' tells Cygwin not to use the Access Control Lists found in Microsoft's NT tree. (BTW, as of Cygwin 1.7.9-1, 'posix=1' and 'nouser' are ignored here.)
The exception is that Cygwin will look for '#!' at the beginning of files to set the executable bit; msysGit, as mentioned above, will look at extensions like .exe and .bat.
In a development project, it might be useful to set write- and execute-permissions (at least the 'user' bits). If you want to manipulate permission bits further in your repository, you can tell msysGit (or even Cygwin Git) to ignore permission bit differences. Then you can set (see Jakub Narębski's answer) the (user?) execute bits:
git update-index --chmod=+x [file paths]
and reset them:
git update-index --chmod=-x [file paths]
before you do, 'git commit'.
(Tested with Ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-mingw32], Cygwin 1.7.9-1.)
BTW, to see what Cygwin version you are running:
cygcheck -c cygwin
References
file modes - Cygwin
NT Security - Cygwin
file modes - msysGit
discussion
Copyright (c) 2011, 2015 Mark D. Blackwell.
Saturday, August 13, 2011
BASH (GNU shell for Unix) cheat sheet
While using the command-line shell, BASH (for Unixen, part of GNU (GNU's Not Unix), developed by FSF (Free Software Foundation), quite popular and superior), for a long time I employed just a few of its manipulation features for command lines -- just these, in fact:
!$ - last command's last argument
(C-r) - reverse search, through command history
Recently, I have wanted to combine multiple arguments from multiple commands. To help me remember how, I used the technique of making a cheat sheet. Interestingly, BASH is similar to the text editor, Emacs (as well as Nano). Here is a sample:
Key abbreviations:
(C-) - Ctrl
(M-) - Alt
(newline) - Enter
(rubout) - Backspace
Move the cursor:
(C-a) - beginning-of-line
(C-e) - end-of-line
(M-f) - forward-word
(M-b) - backward-word
Change text:
(M-t) - transpose-words
Kill and yank:
(C-k) - kill-line
(C-x rubout) - backward-kill-line
(M-d) - kill-word
(C-y) - yank
Completing:
(tab) - complete
(M-/ M-/) - complete-filename
(M-g) - glob-complete-word
(M-?) - possible-completions
(C-x /) - possible-filename-completions
Miscellaneous:
(C-_) - undo
Event designators:
(!-2) - command previous to last
(!-2:1-2) - second previous commands's first and second arguments
(!-2:0 !:3* !-2:2) - second previous command word plus its second argument, the last command's third and following arguments intervening
There's more on GitHub.
Copyright (c) 2011 Mark D. Blackwell.
!$ - last command's last argument
(C-r) - reverse search, through command history
Recently, I have wanted to combine multiple arguments from multiple commands. To help me remember how, I used the technique of making a cheat sheet. Interestingly, BASH is similar to the text editor, Emacs (as well as Nano). Here is a sample:
Key abbreviations:
(C-) - Ctrl
(M-) - Alt
(newline) - Enter
(rubout) - Backspace
Move the cursor:
(C-a) - beginning-of-line
(C-e) - end-of-line
(M-f) - forward-word
(M-b) - backward-word
Change text:
(M-t) - transpose-words
Kill and yank:
(C-k) - kill-line
(C-x rubout) - backward-kill-line
(M-d) - kill-word
(C-y) - yank
Completing:
(tab) - complete
(M-/ M-/) - complete-filename
(M-g) - glob-complete-word
(M-?) - possible-completions
(C-x /) - possible-filename-completions
Miscellaneous:
(C-_) - undo
Event designators:
(!-2) - command previous to last
(!-2:1-2) - second previous commands's first and second arguments
(!-2:0 !:3* !-2:2) - second previous command word plus its second argument, the last command's third and following arguments intervening
There's more on GitHub.
Copyright (c) 2011 Mark D. Blackwell.
Labels:
BASH,
cheat sheet,
command line,
computer,
linux,
nano,
shell,
unix
Monday, August 8, 2011
CSS selector objects and methods for testing in Ruby
Let's say, for a given web page, you are writing some tests. And, supposing, you want to test whether the page contains a single DIV, of CSS class, 'only'.
And, you want to know whether the DIV (or the page) contains a single FORM, of CSS class, 'good-form'.
And further, you want to know whether the FORM (or the page) contains (among other things) a single INPUT, of CSS class, 'my-input'.
And further, whether that INPUT has CSS attribute, 'type=text'.
So, a CSS selector, useful for finding that on a web page, would be:
div.only > form.good-form > input.my-input [type=text]
Right?
Maybe (in your test) specifying descendents instead of children would have a better flexibility, allowing later intervening DIV's (for instance). With this difference, the new CSS selector would be:
div.only form.good-form input.my-input [type=text]
How might one like to specify these selectors, speculatively and ideally? Even better than the CSS selector strings in Ruby above might be... what?
(A.) HTML elements
Well, it might be nice if code for DIV's could work simply like this:
D.class 'only'
(Unfortunately, this would clobber Object#class, probably interfering with essential Ruby functionality elsewhere in our application.) We could compromise and give it a longer method name:
D.css_class 'only'
(B.) HTML Attributes
A web page might also, in addition to an INPUT element carrying all of the desired attributes, supply some other INPUT with fewer of them, or indeed another kind of INPUT entirely.
So, obviously, it is good to test for:
o The desired number of INPUT's (in total), and
o The presence of each INPUT, carrying all the attributes desired.
In light of this, wouldn't it be nice if one easy method invocation could assert the unique presence of exactly one INPUT, plus its unique presence carrying a specific set of attributes?
Another thing possibly useful might be checking the attributes one at a time; I don't know.
The same would probably apply also to any other kind of HTML element having attributes.
A seemingly good way to invoke the method would be:
attribute 'type', 'text', 'value', 'your name here'
And, for unpaired attributes:
attribute 'hidden'
So: how could these semantics really work? Here's an example, carrying the idea further:
(C.) An implementation
# Fuller Example of Web Page Testing, Using CSS Selector Objects and Methods:
module CssSelectorConstants; D,F,I = %w[ div form input ].map{|e| CssString e} end
class SomeTestClass
extend CssSelectorConstants
def test_web_page
d_o = D. css_class 'only'
fg = d_o.descend(F).css_class 'good-form'
im = fg. descend(I).css_class 'my-input'
a_t = im.attribute 'type', 'text'
atv = im.attribute 'type', 'text', 'value', 'your name here'
av = im.attribute 'value', 'your name here'
# There should be exactly one DIV, 'div.only':
assert_select d_o, 1 do
# And within that, exactly one FORM, 'form.good-form':
assert_select fg, 1 do
# I.e., exactly one:
# div.only form.good-form
# And within that, exactly one INPUT, 'input.my-input':
assert_select im, 1
# I.e., exactly one:
# div.only form.good-form input.my-input
# And exactly one INPUT, 'input.my-input[type=text]':
assert_select a_t, 1
# I.e., exactly one:
# div.only form.good-form input.my-input
# [type=text]
# And exactly one INPUT, 'input.my-input[value=your name here]':
assert_select av, 1
# I.e., exactly one:
# div.only form.good-form input.my-input
# [value=your name here]
# And exactly one INPUT, 'input.my-input[type=text,value=your name here]':
assert_select atv, 1
# I.e., exactly one:
# div.only form.good-form input.my-input
# [type=text,value=your name here]
end #form
end #div
end #def
end #class
See also:
CSS selector objects & methods (for Rails; GitHub)
Copyright (c) 2011 Mark D. Blackwell.
And, you want to know whether the DIV (or the page) contains a single FORM, of CSS class, 'good-form'.
And further, you want to know whether the FORM (or the page) contains (among other things) a single INPUT, of CSS class, 'my-input'.
And further, whether that INPUT has CSS attribute, 'type=text'.
So, a CSS selector, useful for finding that on a web page, would be:
div.only > form.good-form > input.my-input [type=text]
Right?
Maybe (in your test) specifying descendents instead of children would have a better flexibility, allowing later intervening DIV's (for instance). With this difference, the new CSS selector would be:
div.only form.good-form input.my-input [type=text]
How might one like to specify these selectors, speculatively and ideally? Even better than the CSS selector strings in Ruby above might be... what?
(A.) HTML elements
Well, it might be nice if code for DIV's could work simply like this:
D.class 'only'
(Unfortunately, this would clobber Object#class, probably interfering with essential Ruby functionality elsewhere in our application.) We could compromise and give it a longer method name:
D.css_class 'only'
(B.) HTML Attributes
A web page might also, in addition to an INPUT element carrying all of the desired attributes, supply some other INPUT with fewer of them, or indeed another kind of INPUT entirely.
So, obviously, it is good to test for:
o The desired number of INPUT's (in total), and
o The presence of each INPUT, carrying all the attributes desired.
In light of this, wouldn't it be nice if one easy method invocation could assert the unique presence of exactly one INPUT, plus its unique presence carrying a specific set of attributes?
Another thing possibly useful might be checking the attributes one at a time; I don't know.
The same would probably apply also to any other kind of HTML element having attributes.
A seemingly good way to invoke the method would be:
attribute 'type', 'text', 'value', 'your name here'
And, for unpaired attributes:
attribute 'hidden'
So: how could these semantics really work? Here's an example, carrying the idea further:
(C.) An implementation
# Fuller Example of Web Page Testing, Using CSS Selector Objects and Methods:
module CssSelectorConstants; D,F,I = %w[ div form input ].map{|e| CssString e} end
class SomeTestClass
extend CssSelectorConstants
def test_web_page
d_o = D. css_class 'only'
fg = d_o.descend(F).css_class 'good-form'
im = fg. descend(I).css_class 'my-input'
a_t = im.attribute 'type', 'text'
atv = im.attribute 'type', 'text', 'value', 'your name here'
av = im.attribute 'value', 'your name here'
# There should be exactly one DIV, 'div.only':
assert_select d_o, 1 do
# And within that, exactly one FORM, 'form.good-form':
assert_select fg, 1 do
# I.e., exactly one:
# div.only form.good-form
# And within that, exactly one INPUT, 'input.my-input':
assert_select im, 1
# I.e., exactly one:
# div.only form.good-form input.my-input
# And exactly one INPUT, 'input.my-input[type=text]':
assert_select a_t, 1
# I.e., exactly one:
# div.only form.good-form input.my-input
# [type=text]
# And exactly one INPUT, 'input.my-input[value=your name here]':
assert_select av, 1
# I.e., exactly one:
# div.only form.good-form input.my-input
# [value=your name here]
# And exactly one INPUT, 'input.my-input[type=text,value=your name here]':
assert_select atv, 1
# I.e., exactly one:
# div.only form.good-form input.my-input
# [type=text,value=your name here]
end #form
end #div
end #def
end #class
See also:
CSS selector objects & methods (for Rails; GitHub)
Copyright (c) 2011 Mark D. Blackwell.
Subscribe to:
Posts (Atom)